# A Tale of Many Networks: Splitting and Merging of Chord-like Overlays in Partitioned Networks
## 5 Evaluation Results
### Evaluation Results for Setups C.1-5: Testing Various Approaches to Start Merging Instances  
The scenario of Setups C.1-5 is as follows: 1024 nodes join one Chord ring. After the join phase and some additional time in which the Chord ring should have stabilized, a group of 310 nodes (C.1-2) or 400 nodes (C.3-5) is isolated from the network and therefore separated from the global Chord ring. With respect to Setup C.1 and C.2, we investigate the effect of different approaches, namely the passive and the public list, to identify the separated nodes again. In Setups C.3-5, we reduced overheads in terms of message complexity by introducing a probabilistic model to start merging procedures. In Figure 11(a)-c, the usage of a passive list is shown. Nodes which are detected by a node to be suddenly unavailable are added to its passive list, which is iterated periodically to find possible contact nodes to merge. The large number of constructs observed for Chord-Zip indicated that the Chord-Zip algorithm is not suitable for being combined with the passive list, as it is too slow to react on multiple, simultaneous opportunities to start different merger instances. Surprisingly, both Ring-Unification Algorithms have not been able to handle the network isolation event within the simulation time as can be seen in Figure 11(a). Only the Ring Reunion Algorithm has been able to adjust all successor pointers directly after the partitioning event finished at minute 240 (Figure 11(b)). Figure 11(c) shows that the quantity of message consumption of the Ring Reunion Algorithm does not exceed the amount of messages which are sent by Chord itself. On the contrary, the other merging algorithms produce high numbers of messages, since multiple merger instances are started to merge the high number of constructs which are formed after the network partitioning. As an alternative to the passive list, we tested a list of 160 randomly chosen and publicly known nodes which are obtained by each node from a bootstrap server during the join phase. This list is iterated periodically in Setup C.2, in order to obtain possible contact nodes. Looking at the usage of the public list, as Figure 11(e) indicates, only the Ring Reunion Algorithm manages to adjust all successor pointers within the simulated time. Again, the Gossip-based Ring-Unification Algorithm forms a large number of constructs after all network partitions have become reachable again--see Figure 11(d). It might be possible that  
Figure 11: B.1 Direct comparison of Gossip-based Ring-Unification Algorithm and Ring Reunion Algorithm applied in two large networks. Merging algorithm is manually started at only one node. Figure 10: A.1 Merging of three networks. the Gossip-based Ring-Unification Algorithm is capable of merging the separated overlays again, but that would take a long time. Figure 12d,\(f\) show that the message consumption of both algorithms is highly related to the number of constructs in the underlying network. At first glance, it might seem questionable why the public list, which actively repeats to contact the same overlay nodes again and again, should be considered as alternative to the passive list (reactive approach). The answer is very simple: the problem with the passive list is that only nodes which have been known before a network failure occurs can be considered as target nodes to merge. The passive list is limited by each node's routing table, i.e., the finger table and successor list. The public list on the opposite contains randomly selected nodes which are not dependent on the routing table. This principle counteracts the effect of unintended group forming, stated in Section 1.1, by enriching the routing table of each node with a pool of further, well distributed contacts. A combination of both approaches is possible but not considered in our evaluation since we aim at a direct comparison of both approaches.