# A Tale of Many Networks: Splitting and Merging of Chord-like Overlays in Partitioned Networks
## 5 Evaluation Results
### Discussion on Real-World Deployment  
As future work, we aim to integrate an adapted version of Ring Reunion in our peer-to-peer-based online social network LibreSocial [4], which we previously tested with up to 2000 instances in [41] and that uses Pastry as overlay. Using LibreSocial as a basis will allow us to observe the actual effects of network partitioning and merging in a real-world deployment. In our publication on Ca-Re-Chord [10], we also analyzed Re-Chord [9], and saw that, through simulation, we can identify elements of theoretical models that have been overlooked in their relevance. The same applies for real-world implementations in comparison to simulations, as we experienced when running FreePastry (in LibreSocial) compared to Pastry [3]. Real-world implementations must deal with all real networking effects being in place, while simulations and theoretical models capture only a fraction of the influencing factors. From our work with real-world P2P applications, we know that the heterogeneity of the participating devices is a challenging issue and fault tolerance is critical. Faulty devices might fail to follow the Ring Reunion protocol, and thus the merging might stop. Typical countermeasures are to perform the process in parallel to avoid the impact of individual faulty devices or to validate the proper functionality of nodes in the overlay and mark them as faulty. A similar approach is used in Kademlia through parallel and iterative routing compared to the singular and recursive routing of early overlay networks. We investigated capacity-related roles in overlay networks in [42] and have a basis to apply this to the Ring Reunion approach in a context in which real-world investigation shows demand. Faulty behavior is also strongly connected with malicious behavior, i.e., modified versions of P2P software that aim to disrupt the network; while at first glance the Ring-Unification approach does not seem to be able to cause harm--since, when applied in a connected ring, the ring remains as it is--a further in-depth investigation is recommended. A further element to consider in a real-world deployment are nodes assumed to be able to connect to \"random\" other nodes using their active or passive list; while a P2P network is typically run by private end devices in regular households, these devices are hard to reach if they are behind a router using network address translation (NAT). In this case, it is essential that port forwarding is enabled in the router, allowing specific nodes to be reached using their IP address and port. The used port should be well known, and firewall as well as NAT settings should be configured appropriately. In [43], we already explored how an overlay can cope with a subset of nodes not being fully compatible with the protocol and only partially supporting the desired networking features; meanwhile, in \"Minicamp: Middleware for Incomplete Participation in Structured Peer-to-Peer Monitoring Protocols\" [43], we assume that a core structured overlay is in place and that we have an additional monitoring over-overlay that is only partially supported. In our case, we have an additional Ring Reunion approach that might be only partially supported. Another issue in deploying Ring Reunion in a P2P network is the source of the public contact list while the network is partitioned. The core idea ultimately is to have a list of candidate node contacts to periodically scan and test whether they are available or not, regardless of whether the node information in the list is individually observed or downloaded/obtained from somewhere. In case the Internet in a country is operational, offering and obtaining such lists, e.g., through websites, local exchange, or even scribbles on paper, is easy. In case the Internet connection between countries is shut down, and national/local Internet connectivity is given, local networks could emerge, and our Ring Reunion approach helps in supporting reconnection once the connectivity is reestablished.