## 5 Evaluation
### P2P Network Simulation Method  
In order to verify the usability of the communication scheme for unreachable nodes in decentralized networks proposed in this paper, we will simulate reachable and unreachable nodes, and the process of their sending and receiving packets, using methods that are as close to the real environment as possible. Although there are some P2P simulation methods available, most of them are based on a single program that simulates the algorithms running in an overlay network and cannot distinguish between nodes based on their network properties, and cannot simulate the real packet transmission process and the interruptions such as network delays that are generated in between. It also does not simulate the IP address and other infrastructure used for network transmission in a real environment, and therefore cannot simulate the process of establishing connections to unreachable nodes behind NAT or firewall. For this reason, we have used a real network environment, real IP addresses and other infrastructure and packet sending and receiving processes to test the availability and performance of the unreachable node communication scheme in the network. Specifically, we used n ECS under the same proprietary network as the experimental virtual machines in the simulation, and they were on the same subnet and could communicate with each other through private addresses. The specifications of each ECS are 64 vCPU, Core 3.5 GHz, 128 GB RAM, 40 GB SSD, 32 Gbps of intranet bandwidth, 12 million PPS of intranet packets sent and received, and Ubuntu 18.04 operating system. The scheme is organised as shown in Figure 15. n ECS \((ecs1,ecs2,\ldots,ecsn)\) are connected to the virtual switch vSwitch via virtual ports \(vEht0,vEht1,\ldots,vEhtn\), which contains a DHCP server that provides the ECS that access the network with IP address for the network segment 172.19.80.0/20. In each ECS we simulate simultaneous running nodes by means of independent threads, each bound to a socket, which also communicate with each other via the 172.19.80.0/20 network segment, but the packets are forwarded directly by the local switch instead of passing through the vSwitch. To simulate the unreachable node \(u_{i}\) more realistically, the socket of the unreachable node will not accept external active connections, but only return packets from connections it has initiated. In addition, there \begin{table}
\begin{tabular}{c c c c c c} \hline \hline
**Group** & **Number** & **Time** & **Average Time of per Time** & **8 bit ‘0’** & **16 bit ‘0’** \\ \hline
1 & 1000 & 605 s & 0.605 s & 47 & 1 \\
2 & 1000 & 653 s & 0.653 s & 53 & 3 \\
3 & 1000 & 589 s & 0.589 s & 43 & 0 \\
4 & 1000 & 621 s & 0.621 s & 55 & 2 \\
5 & 1000 & 660 s & 0.660 s & 62 & 5 \\ \hline \hline \end{tabular}
\end{table} 
Table 1: Node addresses generate five sets of experimental results. \begin{table}
\begin{tabular}{c c} \hline \hline
**Item** & **Numerical Value (HEX)** \\ \hline Maximum & 0 xfffb1931c879140b7561882a8953 cb7 abef14f3 \\ Minimum & 0x502a121 ffee286d8 eda6c1a04f11 bdf07e5d3 \\ Average & 0x801e79 cb28 bc725f94b84c200 bb522 dc4 ef9e60 \\ Variance & 0x1.54f215601 abd8E+80 \\ \hline \hline \end{tabular}
\end{table} 
Table 2: Statistical information for 1000 addresses. is a console, ECS control center, which maintains a connection to the master process in \(ecs1,ecs2,\ldots,ecsn\) via vSwitch, thus establishing a connection to each node for functional control of the node and data collection. It has been verified that in this configuration where the number of ECS running nodes does not exceed 1000, CPU time slice rotation does not significantly affect the algorithms run by the nodes, while the latency in transmitting packets is basically indistinguishable between each node in the same ECS and those in different ECS, and they can be considered to be on equal status.