# 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
If long-term network partitions are considered, the behavior of the passive list is comparable to those of the public list: nodes in the routing table which are detected to be unreachable are held in the passive list, unchanged for a long time, but without the diversity of the public list. We limited the list of public nodes to 160 contacts since [PERSON]'s routing table has the same size in our simulation. In principle, this list could be periodically obtained from a bootstrap server. We decided to test the merger algorithms with a static list which does not change during the simulation, and is not updated and fresh, in order to simulate a worst-case scenario in which no bootstrap server is available once a node joins the network. A comparison of Figure 12c,f shows that the message overhead of the public list (active approach) is comparable to the overhead produced by the passive list (reactive approach). Next, in Setup C.3-5, we reduce the amount of messages by reducing the number of instances that are started by a specific merging algorithm. Therefore, we extended the algorithm with the ability to estimate the size of the current construct a node is in. Now, each node picks a random number out of \([0,1]\) and starts a merger instance only if the chosen random number is less than \(\alpha/size_{r}\), where \(\alpha\) constitutes the number of started mergers per overlay construct and \(size_{r}\) is the estimated number of nodes in the current construct. These setups and corresponding results in Figure 13 allow us to determine a good value for \(\alpha\), i.e., the number of merger instances per construct. As can be seen in Figure 13a, the Ring-Unification Algorithm performs poorer when fewer merger instances are started. With \(\alpha=1\) up to 250 constructs are formed, i.e., disconnected network parts; meanwhile, higher \(\alpha\) values quickly reduce the number of constructs. Correspondingly, the ratio of correct pointers also improves, as seen in Figure 13b. The results indicate no distinct difference between \(\alpha=5\) and \(\alpha=100\). In general, the Gossip-based Ring-Unification Algorithm is not very convincing, as a complete merge is not achieved. Considering Figure 14b, we see that our Ring Reunion Algorithm performs well if approximately 10 instances per construct are started; in contrast, \(\alpha=5\) only leads to 82% correct pointers and several constructs remain (as seen in Figure 14a), and with \(\alpha=10\), only a few constructs remain. When we enable \(2^{2}=4\) initiated mergers in parallel in Reunion2, the merging performs flawlessly with \(\alpha=5\) and higher \(\alpha\) values, as the number of constructs reaches 1 in Figure 15a and we attain the ratio of 100% correct pointers that is depicted in Figure 15b. Furthermore, we learn from this evaluation result that it is necessary to react quickly on partitioning events to perform well and to reduce costs. Figure 12: Comparison of passive list (C.1, left) and public list (C.2, right) for discovering overlays during partitioning events. Nodes initiate a merge when a contact node is reachable. Figure 13: C.3 parameter study: Gossip-based Ring-Unification Algorithm Reunion3 (\(2^{3}=8\) instances). Each overlay construct initiates \(\alpha\) mergers within a time period of 4 min.