of the update requests. The transitions between these phases occur as indicated by the arrows synchronously with the issuing of the requests to update the replicas of the data item. Thus, they are triggered by each new value written to the master copy of the data item.
The replication strategy is defined by theupdate pattern (UP), a triple, whose values describe the sequence of the different update requests. The first value in the triple defines the maximum number of repetitions in theADVERTISE phase. The second defines the number of repetitions in theUPDATE phase and the third, again the maximum number of repetitions in the VERIFY phase. If any of these numbers is zero, the corresponding phase is disabled. The following paragraphs describe how the update pattern influences the replication process.
The replication process always starts with theADVERTISE phase, even if it is dis-abled by the update pattern. In this phase the owner node announces that there is a new shared data item available in the network. It sends the advertisement update requests or verified advertisement update requests if the VERIFY phase is enabled.
In the ADVERTISE phase the advertising is repeated for the successive instances until the maximum allowed number of advertisement repetitions defined by the update pattern is reached or the verification result is a success. Then, if the UPDATE phase is enabled, a transition into theUPDATE phase occurs, otherwise intoVERIFY. Shall the VERIFY phase be disabled as well, the replication remains in theADVERTISE phase.
In theUPDATE phase the plain update requests are sent, i.e., the replica updating is performed only on nodes, which have already decided to replicate the data item and other sensor nodes just ignore these requests. In this phase the source node is not informed about the result of the replication. The sending of the plain update requests is repeated for the successive instances, until the number of repetitions defined by the update pattern is reached, what is followed by a transition to the VERIFY phase. Shall theVERIFY phase be disabled, the replication remains in theUPDATE phase.
In theVERIFY phase the owner of the master copy of the data item wants to inves-tigate how many replicas of the item are available in the network, without asking new nodes to hold a replica. To do so, the owner node sends the verified update requests.
In this phase, the owner repeats the verification for the successive instances of the data item, either until the maximum allowed number of repetitions, as defined by the update pattern, is reached, or the result of the replication goal verification is a success. If the verification fails, a transition to theADVERTISE phase occurs, otherwise, the mecha-nism proceeds with the UPDATE phase. If the target phase is disabled, the mechanism remains in theVERIFY phase.
The update pattern allows skipping the phases by setting the corresponding value in the array to zero. However, some of the combinations with zeros are disallowed and induce a change in the setting. For instance, if all the values are set to zero, then the ADVERTISE phase is enabled automatically. In such a setting only the advertisement update requests are sent and no acknowledgments are provided. Thus, it results in the eventual replication density reaching 100 per cent for the chosen replication range.
Figure 3.3: Update request forwarding tree–independent forwarding
mechanism introduced in Section 3.1can be optimized in order to reduce its costs. The dependent request forwarding assumes that not all of the nodes are holding the replicas of all the shared data items and tries to take advantage of that fact. In such a case the request forwarding tree can be limited to nodes that hold a replica of the data item the request is about, i.e., only nodes that hold a replica of the data item process and forward the request. Thus, the forwarding depends on the content of the local memory of the nodes. However, this cost reduction comes at the price of reduced penetration scope.
The mechanism will be explained taking as an example the replica update propagation in a system where the nodes decide if they want to store a replica of a data item, as described in Section3.2. The group of replica holders is further the target of the update requests that contain the new instances of the data item. In order to reduce the cost of the message forwarding, it may be reasonable to reduce the span of the forwarding tree to the replica holders only. In contrast to the standard approach described in Section 3.1, further referred to as independent forwarding, thedependent forwarding is realized by allowing only the replica holders to take an active part in processing of requests on the given data item and all other nodes ignore these request messages. Hence, the forwarding tree includes only branches that consist entirely of replica holders.
The clear disadvantage of the dependent forwarding approach is that it requires replica holders on every level of the forwarding tree, i.e., the forwarding is not possible if the desiredreplication densityparameter describing the replication goal, contains zeros. Sim-ilar, defining very small values for the replication density for closer distances from the
Figure 3.4: Update request forwarding tree–dependent forwarding
master copy owner, followed by higher densities at further distances, will cause trouble in achieving this replication goal or will deform the actual result. Figure 3.3 shows an example of independent update request forwarding for the forwarding tree presented in Figure 3.1, where the black shapes represent the replica holders. In contrast, Figure 3.4 presents an example of the dependent update forwarding. Again, the black shapes represent the replica holders. The dark grey shapes represent the nodes that are not reachable by the update requests, in the example tree, due to the lack of replica holders in their branches. Even if the most of them can still be reached by alternative paths represented by the dashed arrows, there are nodes that cannot be reached anymore, like node 10 in Figure3.4.
Additionally, if a forwarding replica holder disappears, the nodes further in the branch may lose the connectivity as well. Anyway, the dependent forwarding of update requests may reduce the number of sent and received messages, and thus, the total cost of the up-date request propagation. The choosing between independent and dependent forwarding of update requests allows optimization of the forwarding mechanism following the re-quirements of the application. The dependent request forwarding cannot be used for every kind of replica update requests, e.g., those with the advertise function, since they have to reach new replica holders.
The dependent request forwarding mechanism can be also used for quorum read operations. Since in such case, the nodes of interest are anyway those, who are holding a replica of the data item in question, the advantage is clear.