An optimized strategy for update path selection in unstructured P2P networks

Computer Networks 56 (2012) 3744–3755

Contents lists available at SciVerse ScienceDirect

Computer Networks journal homepage: www.elsevier.com/locate/comnet

An optimized strategy for update path selection in unstructured P2P networks Xianfu Meng ⇑, Yanli Wang, Yalin Ding School of Computer Science and Technology, Dalian University of Technology, No. 2, Linggong Road, Dalian 116024, China

a r t i c l e

i n f o

Article history: Received 7 April 2011 Received in revised form 11 June 2012 Accepted 22 August 2012 Available online 29 August 2012 Keywords: Unstructured P2P network Replica consistency Update message Update path Redundant update message

a b s t r a c t With the growth of P2P file sharing systems, people are no longer satisfied with the sharing of the read-only and static files, and thus the systems with mutually writable and dynamic files have emerged, resulting in the replica inconsistency problem. To maintain the replica consistency, too many update messages need to be redundantly propagated due to the lack of the sharing of globally updated path information in the existing strategies. To address this problem, we propose an optimized strategy for update path selection, which makes the nodes share the update path information by using clone, variation and crossover operations for the update paths. We also present a repeated update strategy to cope with the churn problem so as to maintain replica consistency as far as possible even if some nodes temporarily leave the network. The simulation results show that our strategy can significantly reduce the number of the redundant update messages without lowering the message coverage, thus improving the availability of the unstructured P2P networks. Ó 2012 Elsevier B.V. All rights reserved.

1. Introduction A P2P (peer-to-peer) network, without central control peers, provides an excellent platform with good scalability and fault tolerance for many distributed applications, such as data storage services. The data storage services with high availability have been an important research focus in P2P networks, and file replication is considered the effective strategy for improving the file availability by distributing the file replicas in different nodes in the P2P data storage services [1,2]. In the earlier studies, researchers mainly focused their efforts on improving the performance of providing read-only file services regardless of the replica consistency [3]. With the growth of the reading and writing applications in P2P networks, the replica consistency maintenance has been an important research focus. Comparing with the traditional database systems or the centralized file sharing systems, the replica consistency ⇑ Corresponding author. Tel./fax: +86 411 84706008. E-mail address: [email protected] (X. Meng). 1389-1286/$ - see front matter Ó 2012 Elsevier B.V. All rights reserved. http://dx.doi.org/10.1016/j.comnet.2012.08.011

maintenance in P2P networks is more difficult due to their features such as distributed and churn. To maintain the replica consistency (it is also called the update consistency), the existing strategies usually employ some kinds of data structures to maintain the distribution information of replicas [3–7], leading to the large amount of maintenance cost. Also, if one or more nodes are isolated from the data structure, the replicas held by these relevant nodes cannot be updated any longer. Although some strategies assign k successor nodes for a replica node to avoid it isolating from the data structure [3], too much maintenance cost is needed. In this paper, we focus on the replica consistency maintenance problem in unstructured P2P networks, and propose an optimized strategy for update path selection to reduce the propagations of the redundant update messages. Our main work is the following: (1) In order to enable a node to have a good grasp of the updated path information so as to reduce the number of the duplicated update messages, we have

X. Meng et al. / Computer Networks 56 (2012) 3744–3755

the child nodes share the updated path information of their parent nodes by employing the clone and variation operations for update paths. (2) The joint node is employed to aggregate the update messages from different parent nodes by utilizing crossover operations in a delayed period, thus having the child nodes learn more about the updated paths so as to transfer the update messages purposefully. (3) A repeated update strategy is proposed to handle the churn problem in order to improve the coverage of the update message propagations when the nodes temporarily leave the P2P network. 2. Related work The file replication and replica management are considered the effective strategy for guaranteeing the files’ availability and improving the users’ retrieval efficiency in P2P networks [3], and therefore how to maintain the replica consistency has been an important research focus in P2P networks. Since the topology of a structured P2P network (e.g. the Chord-based network) is constructed according to a certain rule and the index node clearly knows the distribution of the replicas of a file, the replica consistency in a structured P2P network can easily be maintained. An unstructured P2P network, however, has no fixed topology and there is no centralized peer to monitor or control the distribution of a file and its replicas, thus we cannot employ the approaches used in structured P2P networks to propagate an update message. For this reason, the current researches mainly focused their efforts on the replica consistency in unstructured P2P networks [3]. The strategies for propagating update messages in unstructured P2P networks can be classified into two kinds according to whether the replica distribution information is required. 2.1. Update strategies based on replica distribution A replica distribution based update strategy is that the distribution of all replicas of a file is managed with a certain data structure so as to propagate update messages purposefully, thus significantly reducing the number of the redundant update messages. ZhiJun et al. [3] proposed a replica-chain based replica consistency maintenance approach, where each node transfers an update message to its k neighbors along the replica chain, effectively reducing the number of the redundant update messages. However, since each node must maintain a replica-chain for each shared file, too much maintenance cost is needed. Zhou et al. [4] also employed a data structure, a replica index table, to manage the distribution information of the replicas of a file, expecting to reduce the number of the redundant update messages. It also suffers from the same shortcomings as that of paper [3]. A multi-replica clustering approach [5] was presented based on limited-coding, where replicas are first partitioned into different hierarchies and clusters according to the process of creating new replicas from existent single replica, and then replicas are coded and managed based

3745

on the user-defined limited-coding rule consisting of replica hierarchy and replica sequence, which can also dispose the alteration of clusters caused by dynamic adjustments on replicas (replica addition or replica removal) effectively. This approach, however, suffers from the similar shortcomings to that of paper [3] because a replica cluster must be constructed and managed for each file, though it could reduce the number of redundant update messages. Note that it is very difficult to effectively and accurately manage all the replicas of a file in a distributed and dynamic unstructured P2P network. Once a node holding a replica is isolated from its replica-chain, the replica in that node can be hardly updated afterwards. Therefore, the replica distribution based update strategy is not the best one for unstructured P2P networks, especially for those with high churn rate. 2.2. Update strategies not based on replica distribution As described before, the replica distribution based update strategies for unstructured P2P networks suffer from a significant shortcoming, the higher maintenance cost. For this reason, researchers proposed some other update strategies which did not based on the replica distribution. Since it is no need to manage and grasp the location information of the replicas of a file, this kind of update strategy can better adapt to the unstructured P2P networks. Gnutella [6] and Sacha et al. [7] adopted the floodingbased replica consistency maintenance algorithm which transfers an update message to all the nodes in the network by using breadth first search approach. This approach, however, is easy to make a node receive multiple duplicated update messages for an unstructured P2P network, thus resulting in the propagations of a large number of redundant update messages. The rumor-spreading based update consistency maintenance algorithms [8,9] transferred an update message to a part of the neighbor nodes according to the rumorspreading law. Although these algorithms could reduce the number of the duplicated update messages in comparison with those in [6,7], they cannot ensure an update message to reach the nodes holding the required replica. Hsu et al.[10] employed rumor-like approach to propagate messages, which transfers an update message to some selected neighbor nodes according to their degrees. Four strategies for optimizing network navigation in unstructured and decentralized P2P overlay networks were presented: the max neighbor broadcast (MNB), the max–min traversal (M2T), the multi-max–min traversal (M3T) and the hybrid max–min traversal (HMT). These four approaches suffer from the problem of lower message coverage, though they could to some degree reduce the propagations of the redundant update messages. IRM [11] is a poll-based consistency maintenance strategy, in which each replica node polls its file owner or another node to validate whether its replica is the up-to-date file, and updates its replica accordingly. In order to determine the frequency that a replica node probes its file owner to guarantee timely file update, IRM associates a time-to-refresh (TTR) value with each replica, which denotes the next time a node should poll the owner

3746

X. Meng et al. / Computer Networks 56 (2012) 3744–3755

to keep its replica updated. The TTR value is varied dynamically based on the results of each polling. If the replica is not stale, then sets TTR = TTRold + a to prolong the polling interval; else sets TTR = TTRold/b to shorten the polling interval. However, how to determine the frequency so as to ensure the timely file update and also save the polling and update cost is the key and difficult issue to be solved. As described before, the existing update consistency maintenance algorithms suffer from either of the shortcomings: the higher maintenance cost caused by maintaining the replica distribution information or the more redundant update message propagations due to the update message flooding. Those shortcomings negatively impact on the network availability. Generally speaking, the replica update consistency maintenance involves the update path selection and the conflict detection, in which how to select the update paths is crucial to reduce the propagations of the duplicated update messages [10]. Therefore, we focus our efforts on the update path selection, expecting to reduce the number of the paths to which the update message should be transferred without lowering the message coverage.

V5 V2

V9 V11 V1 V12

V4

V3

V8

3.1. Problem descriptions In unstructured P2P networks, the replica consistency maintenance refers to the update actions on all the replicas of a file when one of which has been updated so as to ensure all the replicas to be consistent. In order to guarantee the update consistency, an update message should be propagated from the initiating node to all the nodes holding the replica. In an unstructured P2P network, since each node only knows the information (e.g. the IP address) of its neighbor nodes, it is difficult for any node to have a good grasp of the updated path information which is essential for the current node to determine who should be forwarded the update message to. On the other hand, only after a node received an update message could it confirm whether the duplicated ones have already been received, leading to the redundant propagations of the update message. In addition, as churn is a basic and inherent problem in P2P networks [12], a node could join the network again after it left the network for a short period. In this case, if an update takes place in a node leaving period, then the replica inconsistency problem will occur when the node holding the replica to be updated rejoins the network. Therefore, we should take the redundant update messages and the churn problem into account in maintaining update consistency. In order to maintain replica consistency in an unstructured P2P network, the node initiating the update should send the updated content to its neighbor nodes, and the neighbor nodes should also continue this process until all the nodes in the network have received the updated content. Theoretically, we could take an unstructured P2P network to be a directed graph G = (V, E) as the message propagations among the nodes are directed, where V is

V7

V10 Fig. 1. The connected graph.

V1

V8

V2 V3 V4

3. Problem descriptions and related definitions

V6

V5

V9

V10

V6 V11

V12

V7 Fig. 2. A spanning tree of Fig. 1.

the vertex set and E is the edge set. As shown in Fig. 1, a vertex represents a node in the network and an edge is the connection between two nodes [13]. We employ directed graph to discuss the optimized strategy for update path selection in the following descriptions. Fig. 1 is a directed graph G = (V, E), where V is the vertex set, i.e. V = {v0, v1, . . . , v11, v12}, and E represents the directed edge set, i.e. E = {hvi, vjijvi, vj 2 V}. Fig. 2 shows a example of the shortest path through which an update message can be propagated from node V1 to other nodes with minimum update cost (in this paper, we assume all the edges in the graph have the same weight). 3.2. Related definitions For easy understanding, we first demonstrate several concepts used in the following sections. Definition 1 (Spanning graph). In this paper, we call the graph formed by the paths through which the update messages in an update process are propagated the spanning graph (SG). We use SG = (VSG, ESG) to represent the spanning graph. To propagate an update message to each node in the network, SG should be a connected graph, i.e. VSG = V and ESG # E. For a given unstructured P2P network, the differ-

X. Meng et al. / Computer Networks 56 (2012) 3744–3755

ent update strategies might form different spanning graphs. In addition, if a spanning graph has fewer edges, then it means the corresponding update strategy generates fewer redundant update messages.

Definition 2 (Parent node and Child node). In a spanning graph SG, if there exists hvi, vji2ESG(vi, vj 2 VSG), then vi is the parent node of vj, and vj is the child node of vi. In this paper, the child node is also called the neighbor node. Definition 3 (Brother node). In a spanning graph SG, if there exists hvi, vji, hvi, vki 2 ESG(vi, vj, vk 2 VSG), then vj is the brother node of vk and vice versa. Definition 4 (Joint node). For an arbitrary node vj, if the number of its parent nodes is greater than 1, then vj is called the joint node. According to the definitions, in the propagations of an update message, a node sending the update message is the parent node and a node receiving the update message is the child node; a node who could receive duplicated update messages is the joint node. Definition 5 (Merged path and Unmerged path). For an arbitrary joint node vi in a spanning graph SG, if the path information in multiple update messages received by vi is merged, i.e. the path information in the update message transferred by vi is the one merged from the received multiple update messages, then the path in the update message is called the merged path, else it is called the unmerged path.

Definition 6 (Confirmed path and Unconfirmed path). In a spanning graph SG, the confirmed path refers to the path on which the nodes are confirmed to have received the update message; unconfirmed path is the path to which the update message was sent, but it is unclear whether the update message has been received by the nodes on the path. From Definition 1 we see the difference between spanning graph and spanning tree (it is a concept in data structure) is that a node in the spanning graph may have more than one parent nodes. From the properties of a graph, if a spanning graph formed by the update paths is a spanning tree, then the corresponding update strategy would generate minimum redundant update messages. In other words, if we can propagate an update message along a spanning tree, the number of redundant update messages can be reduced significantly. However, it is very difficult to construct a spanning tree in a decentralized and unstructured P2P network. In this paper, we try to optimize the update paths to make a spanning graph tend to be a spanning tree so as to reduce the number of the duplicated update messages.

3747

among which the duplicated ones may exist. Though a node would not transfer the duplicated update messages to its neighbor nodes again as the first one has already been transferred and recorded, the redundant update messages really occurred. That a node could receive duplicated update messages means it must have multiple parent nodes. Since the duplicated update messages, coming from different parent nodes and paths, might bring different update path information, if a node could accumulate these duplicated update messages within a short period and put some operations on them (e.g. the update message aggregation and conflict detection), then the number of the redundant update messages may be reduced in the later propagations. Therefore, we adopt a delayed propagation mechanism (it is also called a delayed period). A delayed period begins at the time a node received the first update message, and a node will not transfer the received update messages to its neighbor nodes until a delayed period elapsed. The details of the update message aggregation and conflict detection are described in the later sections. 4. Optimized strategy for update path selection As described earlier, it is difficult for any node to obtain the global and reliable information related to the nodes who have received the update message in an unstructured P2P network. As a result, there exist a large number of nodes who could receive the duplicated update messages regardless of using flooding-based or rumor-spreading based update message propagation approaches [6,7], resulting in the propagations of a large number of redundant update messages. Therefore, we could hardly obtain such update path information as that shown in Fig. 2. Aiming at this problem, in this section we propose an optimized strategy for update path selection without considering conflict detection, in which the path information (including the updated path information and the path information to be updated) to some extent can be shared by using the operations of clone and variation for parent node IDs and child node IDs; the number of the redundant update messages can be further reduced by employing the crossover operations (i.e. merging the update messages) for multiple update messages received within a delayed period; a repeated update strategy is also applied to tackle the replica inconsistency problem caused by churn as described before. As mentioned before, the lack of the sharing of updated path information is the main cause of producing redundant update messages. Therefore, in order to reduce the number of the redundant update messages, the first thing we should do is to find a way by which the updated path information to some degree can be shared among the nodes. We address this problem by defining a novel structure of the update message. 4.1. Structure of the update message

3.3. The delayed period and the update message aggregation In an unstructured P2P network, a node might receive multiple update messages within a short time interval,

In order to share the update path information, we define a new structure of the update message as shown in Fig. 3.

3748

X. Meng et al. / Computer Networks 56 (2012) 3744–3755

Update Info

File ID

Update Content

Segment ID

Peer ID

Update Path

Update Path

MPath

Timestamp

UMPath

Fig. 3. Structure of an update message.

CPath As shown in Fig. 3, Update Info is the unique identifier of an update message, which includes File ID representing the file to be updated, Segment ID standing for the segment to be updated in the file, Peer ID representing the peer initiating the update message and Timestamp representing the time at which the update message is initiated; Update Content represents the update content; Update Path stands for the update path information, which will be extended or merged with the propagations of the update message. Update Path is employed to share the update path information among the nodes, including the updated path information and the path information to be updated. Update Path can be extended by using the following steps:

UCPath

CPath

UCPath

Fig. 4. Structure of the Update Path.

[null | null | V1 | V2 V3 V8 ]

V1 [null | null | V1 V2 | V4 V5, V3 V8 ]

[null | null | V1 V8 |

V2

V4

V5

[V1 V2 V4 V5 V6 |

V6

V8

V3

V9

V12

V9 V10, V2 V3 ]

V10

V11

V7,V3 V8 | null | null]

Step1. Merging As shown in Fig. 4, the item of Update Path is divided into two sub-items, MPath and UMPath, respectively representing the merged path and unmerged path. As defined before, the merged path represents the node set obtained from the merging operations on the paths in multiple update messages received by a joint node, and the unmerged path represents the set of nodes who are not merged yet. The information of the merged path and unmerged path is used to examine if a virtual joint node (see Section 4.3.1) should be set. The details will be extended in Section 4.3. Step 2. Confirming As shown in Fig. 4, MPath and UMPath are both composed of CPath (i.e. confirmed path) and UCPath (i.e. unconfirmed path). CPath refers to such set of nodes who are confirmed to have received the update message, while all the nodes in UCPath are not confirmed to have received the update message yet, but the update message has already been transferred to them. CPath is mainly employed to examine which nodes have already received the update message, whereas UCPath is used to determine to which nodes the update message should be transferred again so as to tackle the churn problem in unstructured P2P network. The merging and confirming of the path information will be described in detail in the following sections.

4.2. Extending and merging of the update paths As mentioned earlier, to share update path information, we can extend and merge the Update Path in each node with the propagations of the update message. Next, we

V7 Fig. 5. The extending and merging of the update paths.

take Fig. 1 as an example to show how to extend and merge Update Path in detail. We employ the following three basic operations for extending and merging Update Path information. Fig. 5 is a spanning graph of Fig. 1 obtained by using the three basic operations, where node V1 initiates the update. (1) Clone operation. The clone operation is used to clone the update path information of the parent node after a node received an update message. The clone operation ensures that a child node could share the update path information of its parent nodes. The path information cloned from a parent node is saved into the item of UMPath in the update message. As shown in Fig. 5, the node V2 clones the path information (i.e. [nulljnulljV1jV2V3V8], where the four parts separated by ‘‘j’’ are corresponding to the four items of the Update Path in an update message respectively) from its parent node V1 by using clone operation. Based on clone operations, it is possible for a child node to share and transfer the updated path information of its parent nodes. (2) Variation operation. The variation operation is employed for the node who just received an update message to change and extend the path information in the update message according to the following rules. In the propagations of an update message, the node who received the update message should perform a variation operation on the path information in the update message. A variation operation has two steps. First, the current node moves its own node ID from UCPath to CPath, confirming that the node has

X. Meng et al. / Computer Networks 56 (2012) 3744–3755

received the update message. As shown in Fig. 5, the node V2 eliminates its ID from UCPath and adds it to CPath. Second, the current node adds its child node IDs, who are not in the Update Path yet, to UCPath in the UMPath so as to extend the update path information. As shown in Fig. 5, the node V2 adds its child nodes, V4 and V5, to UCPath in the UMPath. The Update Path is [nulljnullj V1V2jV4V5, V3V8] after the variation operation has been performed on node V2, in which V4 and V5 are the node IDs added this time by using variation operation. (3) Crossover operation. The crossover operation is used by the joint node to merge the path information of the duplicated update messages coming from different parent nodes and save the merged path information into the item of MPath to produce a new update message. The clone operation and the variation operation can make the update path information in an update message shared and transferred in a single propagation path. With the clone and variation operations performing, however, the differences in update path information among different propagation paths will increase, leading to the update path information to be less shared and more redundant update messages to be propagated. To cope with this problem, we use joint nodes to merge Update Paths in the update messages coming from different parent nodes, expecting to share the update path information coming from different propagation paths. As shown in Fig. 5, after node V6 receives the update path information of [nulljnulljV1V2V4jV6, V3V5V8] and [nulljnulljV1V2V5jV6, V3V4V8] from V4 and V5 within a delayed period, it first performs the variation operations on the two paths to obtain the new path information of [nulljnulljV1V2V4V6jV7, V3V5V8] and [nulljnullj V1V2V5V6jV7, V3V4V8]; and then the crossover operation is performed on the two path information, namely the two paths’ CPath and UCPath in the UMPath are respectively merged and saved into the corresponding items in the MPath, thus the new path information, [V1V2V4V5V6j V7, V3V8jnulljnull], is obtained as the result of crossover operation. As shown before, the operations of clone and variation could reduce the redundant propagations of the update messages. In addition, since all the nodes are connected freely and randomly in an unstructured P2P network [6], any node may have multiple parent nodes. Therefore, there exist a large number of joint nodes who could merge the update path information coming from different parent nodes by using crossover operations which could further reduce the number of redundant update messages. This can be confirmed by the simulation results in Section 7. 4.3. Utilization of virtual joint node and repeated update path We have presented three basic operations for the update path information, the clone operation, the variation operation and the crossover operation, expecting to share the update path information globally as far as possible. Though the number of the redundant update messages to

3749

some degree could be reduced by using these three operations, not a few of the update messages are still propagated redundantly. We take Fig. 5 as an example to explain how these redundant update messages are produced even the three basic operations are performed for the update paths. As shown in Fig. 5, the nodes V9 and V10 could both receive the update path information of [nulljnulljV1V8jV9V10, V2V3] from their common parent node V8. After a variation operation is performed, node V9 would propagate [nulljnulljV1V8V9jV11V12, V2V3V10] to the nodes V11 and V12. Unfortunately, node V10 would also transfer [nulljnulljV1V8V10jV11V12, V2V3V9], the variation result of [nulljnulljV1V8jV9V10, V2V3] on node V10, to the nodes V11 and V12 since node V10 does not know whether V11 and V12 have already received the update message, resulting in the redundant propagations of the update messages (see the broken lines in Fig. 5). In addition, since churn is an inherent nature of the P2P network, if a node joins the network again after a short departure and an update message is transferred to that node just during its leaving period, the update inconsistency problem would occur when the node, with the replica to be updated, rejoins the network. This paper addresses these problems by setting the virtual joint nodes and using repeated update strategy for some paths.

4.3.1. Selection of the virtual joint node A joint node plays an important role in the propagations of an update message. It causes an update message to be propagated redundantly, and also it is such node on which multiple update messages could interact. On one hand, if there are many joint nodes in an update path, it indicates that the propagations of the redundant update messages are serious. On the other hand, since a joint node could receive the duplicated update messages from different update paths, we can use it to aggregate these duplicated update messages to improve the sharing of the update paths, and thus making the nodes, to which the update message will be transferred, learn more about the propagations of the update message so as to reduce the number of the redundant update messages. Therefore, in the case that there are fewer joint nodes in an update path, we may dynamically select a node to be a virtual joint node on which the update messages received within a delayed period could be aggregated, expecting to further reduce the propagations of the redundant update messages. As mentioned before, MPath and UMPath in the Update Path are used to save the merged path information and the unmerged path information respectively. If the length of the unmerged path is greater than that of the merged path (i.e. jUMPathj > jMPathj), then it means that the degree of sharing update path information is lower, and thus the redundant update messages have been or are going to be produced. To cope with this problem, we propose a concept of the virtual joint node by which a node is virtually taken to be a joint node who could aggregate the update messages coming from different paths, expecting to improve the sharing of the update path information so as to reduce the redundant propagations of the update mes-

3750

X. Meng et al. / Computer Networks 56 (2012) 3744–3755

sages. The procedure of selecting a virtual joint node is the following. selectVirtualJointPeer(peer, update). (1) if (update.UpdatePath.UMPath.length > update. UpdatePath.MPath.length) (2) readyPeer = selectJointPeer(peer.brothers); (3) return readyPeer;

In the selectVirtualJointPeer function, the parameter peer represents the current node and update is the update message. The current node uses the selectVirtualJointPeer function to randomly select a node among its brother nodes as a virtual joint node and save it into readyPeer. The update message will be transferred to the selected virtual joint node by the current node so as to be aggregated with the update messages directly received from the parent nodes of the selected virtual joint node. As shown in Fig. 5, suppose that node V10 is selected by node V9 as the virtual joint node, and V9 transfers the update message to V10 (see the dotted line in Fig. 5). After the clone and variation operations are performed as described above on the node V10, the path information in the update message changes to be [V1V8V9V10jV11V12, V2V3jnulljnull]. Thus, the node V10 will not transfer the update message to node V11 and V12 because their IDs have already been in the update path. Obviously, the number of the redundant update messages to some extent could be reduced by using the virtual joint nodes.

4.3.2. Selection of the repeated update path As mentioned earlier, when we focus on the update consistency maintenance problem in a P2P network, we must take the churn problem into account. A repeated update strategy should be taken for some paths to make such nodes who will rejoin the network after a short departure able to receive the update message. In this paper, we select a node in the UCPath according to its repeatedly updated number, the number to be increased by one each time when the update message is transferred to that node, and send the update message to it, expecting to effectively and accurately forward the update message so as to reduce the impact of churn on the update. The selection of the repeated update node is as follows. selectRepeatedUpdatePeer(peer, update) (1) for (every neighbor in peer.neighbors) (2) if (update.UpdatePath.UCPath.get(neighbor)) (3) candidateUCNeighbors.add(neighbor); (4) end if (5) end for (6) readyPeer = selectPeerWithLowerUpdatedNumber (candidateUCNeighbors); (7) return readyPeer;

In the selectRepeatedUpdatePeer function, the parameter peer represents the current node and update is the update message. The selectPeerWithLowerUpdatedNumber function

selects the nodes among the unconfirmed neighbor nodes according to their repeatedly updated number, i.e. the nodes with fewer repeatedly updated number are selected to which the update message will be transferred again. The repeatedly updated number is saved into Update Path with node ID and increased by one each time when the update message is sent to that node. 4.4. Strategy for update path selection without conflict detection We have described three basic operations for update paths (i.e. the clone, variation and crossover), and the utilization of virtual joint nodes and repeated update paths has also been stated in detail, based on which the complete optimized strategy for update path selection can be presented as follows. minUpdatePathChosen(peer, update) (1) update.UpdatePath.UCPath.delete(peer); (2) update.UpdatePath.CPath.add(peer); (3) for (every neighbor in peer.neighbors) (4) if (! Update.UpdatePath.get(neighbor)) (5) candidatePeers.add(neighbor); (6) end if (7) end for (8) crossoverPeers = selectVirtualJointPeer(peer, update); (9) UCNeighbors = selectRepeatedUpdatePeer(peer, update); (10) readyPeers.add(candidatePeers); (11) readyPeers.add(crossoverPeers); (12) readyPeers.add(UCNeighbors); (13) return readyPeers; In the minUpdatePathChosen function, the parameter peer represents the current node and update is the update message. The steps from (1) to (2) are used to perform the first step of the variation operation, by which the peer (i.e. the current node) is eliminated from UCPath and added to CPath; the steps from (3) to (7) are employed to perform the second step of the variation operation, by which the child nodes who are not in the Update Path are added to the UCPath; the selection of virtual joint nodes and the selection of repeated update paths are from (8) to (9); the steps from (10) to (13) are used to add the nodes selected by the above steps to the set variable of readyPeers and return it as the finally selected paths to be updated. 5. Conflict detection for the update messages As mentioned earlier, a node will not transfer the received update messages to its child nodes until a delayed period elapsed. During the delayed period, a node needs to complete the conflict detection and message aggregation for all the received update messages so as to reduce the number of the update messages and make the update path information better shared by the nodes who would determine to which nodes the update message should be propagated. There are two rules we should follow in conflict detection for the update messages. Firstly, we should do nothing if the two update messages are for the different files; sec-

X. Meng et al. / Computer Networks 56 (2012) 3744–3755

ondly, we should merge the update messages if the two different update messages are for the same file. Suppose update(t, p)f,i is the update content for segment i in replica f initiated by node p at time t. For arbitrary f1 and f2, we use the following rules to complete the conflict detection and merging operation for the two update messages, updateðt1 ; p1 ÞÞf1 ;i and updateðt 2 ; p2 ÞÞf2 ;j . (1) There is no conflict if the two update messages are for the different files. The rule can be given as follows:

3751

ðf1 ¼ f2 Þ ^ ði ¼ jÞ ^ ðt1 ¼ t 2 Þ ^ ðp1 ¼ p2 Þ ! updateðt1 ; p1 ÞÞf1 ;i In case (4) (i.e. the received update message is the duplicated one), the Update Content is not changed but the Update Path should be merged with crossover operation as described earlier. According to the above descriptions, the complete algorithm for conflict detection is the following: conflictControl(updateList).

(1) (2) (3) (4) (5)

s = updateList; for(each update1 in updateList) s = s.delete(update1); for(each update2 in s) if (update1.UpdateInfo.fileID==update2.UpdateInfo.fileID && update1.UpdateInfo.SegmentID==update2.UpdateInfo. SegmentID && update1.UpdateInfo.TimeStamp!=update2.UpdateInfo. TimeStamp) (6) if (update1.UpdateInfo.TimeStamp>update2.UpdateInfo.TimeStamp) (7) updateList.delete(update2); (8) s.delete(update2); (9) else (10) updateList.delete(update1); (11) end if (12) end if (13) if (update1.UpdateInfo equals(update2.UpdateInfo)&& update1.UpdateContent.equals(update2.UpdateContent)&& ! (update1.UpdatePath.equals(update2.UpdatePath)) (14) update1.UpdatePath.MPath.add(update1.UpdatePath.UMPath); (15) update2.UpdatePath.MPath.add(update2.UpdatePath.UMPath); (16) update1.UpdatePath.MPath.add(update2.UpdatePath. MPath); (17) updateList.delete(update2); (18) s.delete(update2); (19) end if (20) end for (21) end for (22) return updateList;

ðf1 – f 2 Þ ! updateðt1 ; p1 ÞÞf1 ;i [ updateðt2 ; p2 ÞÞf2 ;j (2) There is no conflict if the two update messages are for the different segments in the same file. The rule is the following:

ðf1 ¼ f2 Þ ^ ði – jÞ ! updateðt1 ; p1 ÞÞf1 ;i [ updateðt2 ; p2 ÞÞf2 ;j (3) There is a conflict if the two update messages are for the same segment in the same file but with different update time. It can be described as follows:

ðf1 ¼ f2 Þ ^ ði ¼ jÞ ^ ðt1 – t 2 Þ 8 > < updateðt2 ; p2 ÞÞf2 ;j t 1 < t2 ! updateðt1 ; p1 ÞÞf1 ;i t 1 > t2 > : (4) There is no conflict if the two update messages are the same one. It can be described as follows:

In the conflictControl function, the parameter updateList is the list of the received update messages within a delayed period; the steps from (5) to (12) are used to merge the Update Content in each update message according to the rules; the steps from (13) to (19) are employed to merge the Update Path according to the rules. The return value of the conflictControl function is the list of the update messages aggregated from the original ones by using conflict detection algorithm. 6. Complete algorithm for update path selection with conflict detection We have described the optimized strategy for update path selection and conflict detection for the update messages. The following is the complete algorithm, named updatePathOptimization, for update path selection. The updatePathOptimization function should be executed on each node in the delayed period.

3752

X. Meng et al. / Computer Networks 56 (2012) 3744–3755

updatePathOptimization(peer). (1) if(beginTime==0) (2) beginTime = currentTime; (3) end if (4) while(currentTime-beginTime < delayTime) (5) receivedUpdates.add(peer.ReceivedUpdate()); (6) end while (7) beginTime = 0; (8) candidateUpdates = conflictControl (receivedUpdates); (9) for (each candidateUpdate in candidateUpdates) (10) readyPeers = minUpdatePathChosen (peer,candidateUpdate); (11) sendUpdate(peer, readyPeers,candidateUpdate); (12) end for

In the updatePathOptimization function, the parameter peer represents the current node; the steps from (1) to (3) are used to set the begin time of a delayed period; (4)–(6) are employed to receive the update messages within a delayed period and save them into receivedUpdates. The conflict detection is performed by (8) so as to merge the update paths and the update contents according to the relevant rules; the steps from (9) to (12) are used to optimize the selection of the update path for each update message which has already been aggregated by using the conflict detection strategy, and then send the update message to the selected paths. To maintain replica consistency, too many redundant update messages need to be propagated due to the lack of the sharing of the global update path information in the existing strategies [6]. This paper addresses the problem by adding the update path information to the update messages and using three basic operations for the update messages. Though adding the update path information to an update message would not significantly increase the communication overhead, the Bloom filter [14] algorithm can be used, if necessary, to manage the items of an update message so as to reduce the communication overhead. Since there is no need for a node to consult the relevant information from others when it selects the path to forward the update messages, the computational complexity of our strategy is lower. Considering the adoption of the delayed period mechanism, a node will not transfer the received messages to its neighbor nodes until a delayed period elapsed. A delayed period, in the worst case, would end when the node has received the same messages from all its parent nodes. Therefore, the maximum computational complexity of our algorithm is O(d), where d is the average number of parent nodes each node has. 7. Simulations and performance analysis 7.1. Simulation settings The simulations examine the effectiveness of our work in terms of the number of propagated update messages and the coverage ratio in comparison with flooding, M3T

[10] and IRM [11] approaches. M3T is a method that each node chooses 2N neighbors of two kinds, N neighbors with maximal degree and N neighbors with minimal degree, as the paths to which the update message is transferred. IRM is a poll-based consistency maintenance strategy, in which each replica node polls its file owner or another node to validate whether its replica is up-to-date as introduced in Section 2, and we set its a and b to 0.5 and 1.5 respectively according to the settings in paper [11] in our simulations. We use the cycle-driven mode of peersim [15], a open source P2P systems simulator, to conduct the simulations under the networks with and without churn so as to better reflect the real P2P networks. In our simulations, the number of nodes in the network ranges from 1000 to 5000 and TTL is set to 5, and we set the degree of nodes according to power-law distribution [6]. Each node in the network could at most provide 50 shared files and there is no duplicated one in a node. There are 500 different files in the network and each file at most consists of three updatable segments. The number of replicas of a file is 50 and it does not change during the simulations. The replicas of each file are randomly distributed in the network at the beginning of the simulations. Each simulation initiates 500 update messages, which are randomly initiated by the nodes who hold the file to be updated. The value of N, a parameter used in work [10] described above, is set to 1/3 of the average degree of the network, which is the best value for improving the performance of message transmission according to the simulation results in paper [10]. Each simulation consists of 200 cycles and a different number of update messages are initiated in each cycle. TTL of each update message is decreased by one after a cycle completed, and an update message will be propagated until its TTL reaches zero. We set the length of a delayed period (which is used by our strategy) to one cycle. Each simulation runs 10 times, and the average value is reported as the simulation result. 7.2. Simulations without churn This simulation is conducted under the network without churn, i.e. the node failure rate is 0. The number of nodes is adjusted from 1000 to 5000 before each simulation begins. Naturally, the average degree will increase with the increase of the number of nodes (in this simulation, the average degree changes from 6 to 9 according to the number of nodes). The simulation results are shown in Figs. 6 and 7. As shown in Fig. 6, the numbers of update messages of the four strategies all increase with the increase of the number of nodes. Since there is no measure adopted to reduce the propagations of the redundant update messages, the number of redundant update messages of flooding strategy increases significantly. Our strategy, however, increases slowly because we put some operations for the update paths attached to the update messages with their propagations, which could substantially reduce the number of redundant update messages. The M3T approach needs fewer update messages in comparison with our strategy since it only forwards the update message to N neighbors with maximal degree and N neighbors with minimal degree (as stated before,

3753

X. Meng et al. / Computer Networks 56 (2012) 3744–3755

Flooding

Flooding

M3T

This paper

IRM

M3T

Messages

This paper IRM

Failure rate of peers

Number of peers

Fig. 8. Evolutions of messages with the changes of failure rate.

Fig. 6. Evolutions of messages with the changes of the number of peers.

1.2

Coverage ratio

Coverage ratio

1.0 0.8 0.6 0.4 0.2

Flooding

M3T

This paper

IRM

0.0 1000

2000

3000

4000

5000

Number of peers Fig. 7. Evolutions of coverage ratios with the changes of the number of peers.

N is set to 1/3 of the average degree of the network). From Fig. 6 we also see when the value of N changes, the number of update messages of M3T changes greatly (e.g. when the number of nodes reaches 3000, the average degree reaches 7.5 and the value of N changes from 2 to 3, and at this time the number of its update messages increases significantly). Since IRM adopted the poll-based replica consistency maintenance strategy as introduced in Section 2, it has the fewest update messages in comparison with other strategies. Fig. 7 shows the evolutions of the coverage ratio, the ratio of the number of nodes who received the update message and the number of all the nodes within the TTL hops. The coverage ratio of the M3T approach is lowest among the other approaches except IRM and decreases rapidly with the increase of the number of nodes (i.e. with the increase of the average degree) when the value of N is not changed. Thus, it is difficult to apply the M3T approach to the update consistency maintenance due to its lower coverage ratio. Since each node has its own polling cycles to maintain replica consistency in the IRM strategy, it is difficult for all the nodes holding the same replica to have the same version of the replica in a short time interval, thus leading to the lowest coverage ratio of the IRM strategy. Our approach has almost the same coverage ratio as that of the flooding strategy but with fewer update messages, thus guaranteeing the update consistency and network scalability.

Failure rate of peers Fig. 9. Evolutions of coverage ratios with the changes of failure rate.

7.3. Simulations with churn This simulation mainly examines the impacts of different node failure rates on the number of update messages and coverage ratio. There are 5000 nodes in the network. We adjust the failure rate at the beginning of each simulation and change the failure rate from 0 to the maximum value of 0.5. The ratio of permanent failure and temporary failure is 50%, and if a node leaves network more than five cycles, it is taken to be the permanent failure. Otherwise, the failure is considered temporary. A node temporarily failed will take its original neighbor nodes as the new ones when it rejoins the network. Fig. 8 shows the evolutions of the number of update messages with the increase of failure rate of nodes. We see that M3T has few changes of the number of update messages with the increase of the failure rate since so long as the degree of nodes is not fewer than 2 N, the number of update messages will not be reduced significantly. Unlike flooding approach, our strategy also do not reduce the propagations of update messages greatly because we adopt repeated update strategy to cope with the update inconsistency problem caused by node failure, i.e. an update message will be repeatedly sent to a failed node according to the rules described in Section 4.3.2 if it is not confirmed to have received the update message. As shown in Fig. 9, with the increase of failure rate, the coverage ratio of the flooding approach reduces greatly while our strategy changes slightly (its coverage ratio is above 95%). Although the increase of failure rate

3754

X. Meng et al. / Computer Networks 56 (2012) 3744–3755

Fig. 10. The probability that redundant updates are merged.

also has no great impact on the coverage ratio of the M3T approach, its coverage ratio is always lower than 60%. As for IRM approach, though it has even fewer update massages than that of M3T approach, its coverage ratio is also the lowest in comparison with others since IRM employed the pollbased update consistency maintenance strategy which could not ensure all the nodes holding the same replica to have the same version in a short time interval. From Figs. 8 and 9, we see our approach has higher coverage ratio with fewer redundant propagations of the update messages even under the network with higher failure rate. 7.4. Probability that redundant updates are merged The crossover operation proposed in this paper is used by the joint node to merge the path information of the duplicated update messages coming from different parent nodes. This simulation examines the probability that the redundant update messages are merged in a delayed period. The simulation settings are the same as described in Section 7.2. Assume Ctotal is the total number of nodes who received the update message and Cjoint is the number of joint nodes who received duplicated update messages in a delayed period within the TTL hops. We use the ratio of Cjoint and Ctotal to represent the probability that the duplicated update messages are merged. As shown in Fig. 10, the probability that the duplicated update messages are merged increases with the increase of the number of nodes in the network since the number of joint nodes will increase greatly with the growth of the number of nodes as described in Section 7.2. Although the highest value of the probability that the redundant update messages are merged is only about 10% in our simulations, it does show the effectiveness of using the crossover operations to merge the redundant update messages. 8. Conclusions In this paper, we discussed how to reduce the redundant propagations of the update messages without significantly lowering the coverage ratio in replica consistency maintenance by using the replica distribution-independent approach. Our approach addressed this problem by globally sharing the update path information. We first demon-

strated several concepts and the delayed period, and also defined the structure of an update message. Then, we defined the clone operation and variation operation to extend the update path in an update message. Also, we defined the crossover operation to aggregate the update paths of messages coming from different parent nodes in a delayed period. By using these operations, we could to some extent reduce the propagations of the redundant update messages. To further reduce the number of update messages and increase the coverage ratio, we make use of the concepts of virtual joint node to further aggregate the update messages and the repeated update path to cope with the churn problem. Also, we employ the conflict detection for update messages to reduce the network traffic. The simulation results showed that our strategy is effective and efficient in terms of the number of the propagated update messages and the coverage ratio. Obviously, our strategy can not only be used in the update consistency maintenance, but also be used in other similar aspects such as message transmissions. In our future work, we’ll further focus our efforts on optimizing the selection of message transmission paths so as to smoothly and efficiently forward messages. References [1] C. Blake, R. Rodrigues, High availability, scalable storage, dynamic peer networks: pick two, in: Proceedings of the 9th Workshop on Hot Topics in Operating Systems, Lihue, Hawaii, USA, 2003. . [2] G.F. Feng, J.C. Zhang, Q. Gu, S.L. Lu, D.X. Chen, An overlay topology based proactive replication in unstructured P2P systems, Journal of Software 18 (9) (2007) 2226–2234. [3] W. Zhijun, S.K. Das, M. Kumar, et al., Update propagation through replica chain in decentralized and unstructured P2P systems, in: Proceedings of the 4th Int’l Conf. on Peer-to-Peer Computing, Washington, 2004, pp. 64–71. [4] J. Zhou, Y.J. Wang, S.K. Li, An optimistic data consistency maintenance method based on key-attributes, Journal of Software 19 (8) (2008) 2114–2126. [5] J. Zhou, Y.J. Wang, S.K. Li, A multi-replica clustering management method based on limited-coding, Journal of Software 18 (6) (2007) 1456–1467. [6] L.L.C. Gnutelliums, Gnutella Protocol Specification Version 0.4. 2006. . [7] J. Sacha, J.A. Dowling, Gradient topology for master-slave replication in peer-to-peer environments, in: Proceedings of the 3rd International Workshop on Databases, Information Systems and Peer-to-Peer Computing (DBISP2P’05), 2005, pp. 52–64. [8] W. Dou, H.M. Wang, Y. Jia, P. Zou, A rumor-spreading analog on unstructured P2P broadcast mechanism, Journal of Computer Research and Development 41 (9) (2004) 1460–1465. [9] A. Datta, M. Hauswirth, K. Aberer, Updates in highly unreliable, replicated peer-to-peer systems, in: Proceedings of the 23rd International Conference on Distributed Computing Systems, Washington, 2003, pp. 76–85. [10] Hsu Ching-Hsien, Hsu Chi-Guey, Chen Shih-Chang, Chen Tai-Lung, Message transmission techniques for low traffic P2P services, International Journal of Communication Systems 22 (2009) 1105– 1122. [11] K. Shalini, Y. Surekha, Effective file replication and consistency maintenance mechanism in P2P systems, Global Journal of Computer Science and Technology 11 (16) (2011) 12–17. [12] J. Tian, Y.F. Dai, Study on durable peer-to-peer storage techniques, Journal of Software 18 (6) (2007) 1379–1399. [13] Hao CHEN, Jian-hua SUN, Hai JIN, Analysis of the shortest path length in peer-to-peer networks, Journal of Chinese Computer Systems 27 (3) (2006) 407–411. [14] B. Bloom, Space/time trade-offs in hash coding with allowable errors, Communications of the ACM 13 (7) (1970) 411–426. [15] peersim[OL]. .

X. Meng et al. / Computer Networks 56 (2012) 3744–3755 Xianfu Meng received his B.E. degree in Information Engineering from Dalian University of Technology, China in 1983. From 1998 to 1999 he worked as a network design engineer in Japan. He received his M.E. degree in Electronic Information and Electrical Engineering from Dalian University of Technology in 1986. His research interests include P2P computing and distributed systems.

Yanli Wang is a graduated student and received the M.E. degree in Electronic Information and Electrical Engineering from Dalian University of Technology, China in 2011. Her research interests focus on operation and management in distributed systems, with a specialization on replica consistency maintenance.

3755 Yalin Ding is a graduate student at the Faculty of Electronic Information and Electrical Engineering Dalian University of Technology, China. She received the B.E. degree in Computer Science and Technology for Binzhou University, China in 2009. Her research interests focus on network and distributed systems.