## 5 Experiment
### Testing of File Availability  
This experiment involved three nodes in the IPFS private network that are run on a similar WIFI network. One node is set as a boot node to monitor the client node's activity. Two nodes are set as client nodes. Table 4 shows the hardware and software specifications for testing the nodes. All nodes identify each other by using their peer IDs, which are unique identities for each node with which to communicate in the IPFS private network. Table 5 shows the peer ID of each node in this experiment. Next, the upload and download operations were tested on the IPFS private network. For the upload operation, IPFS creates an immutable object, depending on file size. If the file is larger than 256 kB, it is divided into several chunks that are identified by their CID. First, the data are stored on the local repository of Client Node 1. Then, Client Node 1 updates the DHT to distribute the data. In this experiment, Client Node 1 uploaded files with various sizes. Figure 9(a) shows that the file distribution with size 100 kB is stored only in one object, which is identified by one CID. Figure 9(b) shows that the file distribution with size 1 MB is stored in four objects. It has a root CID and CID for each part. \begin{table}
\begin{tabular}{c c} \hline \hline \multicolumn{2}{c}{**Boot Node**} \\ \hline Processor & Intel(R) CoreTM i5-7500T CPU @2.70 GHz \\ \hline RAM & 8 GB \\ \hline HDD & 250 GB ATA \\ \hline OS & Ubuntu 18.04 \\ \hline \multicolumn{2}{c}{**Client\_1 Node**} \\ \hline Processor & Intel(R) CoreTM i7-4702 MQ CPU @2.20 GHz \\ \hline RAM & 2 GB \\ \hline HDD & 10 GB ATA \\ \hline OS & Ubuntu 16.04 \\ \hline \multicolumn{2}{c}{**Client\_2 Node**} \\ \hline Processor & Intel(R) CoreTM i7-4702 MQ CPU @2.20 GHz \\ \hline RAM & 8 GB \\ \hline HDD & 500 GB ATA \\ \hline OS & Windows 7 Professional \\ \hline \hline \end{tabular}
\end{table} 
Table 4: Hardware and software specifications for testing the nodes. \begin{table}
\begin{tabular}{c c} \hline \hline
**Node Name** & **Peer ID** \\ \hline Boot Node & QmfSUyHddqjlpBjueNoQebsCeWoGLbnSaVBWir1 qSyYg9 Wm \\ \hline Client\_1 Node & QmUuzezNF3 zritD9 ZK9 iaR7 JCXm1 zTZDYDHqHqp8 aQBzsH \\ \hline Client\_2 Node & QmervD64 ABohpJuVEHetFoRebw4 rhBpfJd1 WP6 tzAc5 uRk \\ \hline \hline \end{tabular}
\end{table} 
Table 5: Hardware and software specifications for testing the nodes. To check file availability, we conducted an experiment where we tried to upload a file into Client_1 node and download it from Client_2 node while the node of Client_1 was down. The result shows that the Client_2 node can properly download the file even when the node contains the file (Client_1 node) is not available as other nodes in the network provide it, Table 6 presents the experiment details. To compare the proposed CEA system with the existing one, we attempted to download a file when it was not available on the existing system. As seen in Figure 11, the existing CEA system stores the file on the central server and uses location-based addressing; therefore, the file can be downloaded only if it is available on that server or location. These experimental results show that the functionality of the proposed CEA system offers improved file availability. A distributed file system can provide files, because, instead of storing files on a centralized server, it stores them on all nodes in the IPFS private network. When one node is turned off, other nodes can provide the files.