# An Efficient Causal Group Communication Protocol for Free Scale Peer-to-Peer Networks
## 3 Results
### Simulations  
To analyze our protocol, we carry out different simulations. The scenario used in these simulations consists of one internal group and one external group connected by one super peer. All of the peers in the system are divided equally between these two groups. In the simulation, each peer generates a message every 70-90 milliseconds. The system is simulated with a different number of peers and with different delays in the communication channels. All of the simulation scenarios are listed in Table 1. The simulations are performed in the OMNeT++ discrete event simulator [31]. \begin{table}
\begin{tabular}{c c} \hline \hline
**Message Delays** & **Number of Peers** \\ \hline
0–50 milliseconds & 10–900 \\
50–250 milliseconds & 10–500 \\
50–550 milliseconds & 10–400 \\ \hline \hline \end{tabular}
\end{table} 
Table 1: Number of peers and delays. All of the delays are distributed normally with the mean being the middle of the interval and variance equal to one fourth of the interval (for example, message generation time is distributed like N(80, 5) milliseconds). If a random value is generated outside of the interval, the value of the nearest interval end is taken instead. The simulation program uses the Immediate Dependency Protocol [14] to compare and validate the protocol presented in this paper. When a message can be delivered to an application by our protocol, it is validated against an IDR to detect causal order violations not detected by our protocol. In addition, the overheads for IDR and Dependency Sequences (DS) [15] were calculated to be compared with an overhead generated by our protocol. As the IDR protocol is designed for plain networks, it is simulated in the following way. The super peer in the system is considered transparent for the IDR implementation, and each peer (internal and external) performs the full calculations of the IDR protocol as described in [14]. A super peer only retransmits the messages between groups. As for DS protocol simulations, only the external group is considered. Each external peer is simulated as a super peer with exactly one peer in its group. The results of simulations are analyzed in the following way. Two overheads are mainly analyzed: an overhead of communication (amount of control information required to be sent with a message) and storage overhead (amount of information required to be stored in each peer). As the Dependency Sequences [15] stores information only at super peers level, the storage overhead for this protocol is not analyzed. By considering channel delays from 0 to 50 milliseconds (see Figure 4), the simulation results show that an overhead in an internal group is lower than an overhead in an external group, and an overhead in an external group is lower than an overhead produced by the Immediate Dependency Relation and the Dependency Sequences protocols. For 900 peers, each internal peer requires storing on average 128 bytes of information, and the average overhead in an internal group is around 90 bytes. In the external group, each peer stores on average 2700 bytes and produces an overhead on average of 950 bytes. The IDR protocol requires storing on average 4900 bytes on each peer and to send 1650 bytes, while the DS protocol sends on average 3950 bytes. For these delays the results show that the overhead in an internal group is 18.3 times lower than the overhead of IDR and require storing 38 times less information. Overhead in an external group is about 1.7 times lower than the overhead of IDR and 4.1 times lower than the one of DS protocol, and require storing 1.7 times less information. As all of the overheads have a liner type growth we calculate the slope using the least squares method. For communication overheads, the slopes are: 0.098 for internal group, 1.018 for external  
Figure 4: Communication (**a**) and storage (**b**) overheads in bytes for a system with delays from 0 to 50 milliseconds. group, 1.760 for IDR and 4.356 for DS protocol.