## 3 Design and Implementation
### Massive Deployment with the P2P Protocol  
In order to overcome the shortage issue of temporary storage, an FSBT-based mechanism was proposed to replace the image file from the file system transferring (IFFST)-based mechanism. The receiver of the FSBT mechanism can receive the blocks of the file system from other peers, and then directly write the received blocks to a raw disk or a partition. The sender can read the blocks of the file system from a raw disk or a partition directly, and then send these blocks to other peers. The P2P mechanism was implemented in a program called Ezio [38]. Further details on Ezio are provided in Section 3.3.  
As reviewed in Section 2.2, many protocols are available for the P2P-based solution. The BT protocol was chosen due to the broad availability of the open source BT client programs, which include aria2c [76], BitTornado [34], Enhanced CTorrent [77], LFTP [78], qBittorrent [36], rTorrent [79], and Transmission [80]. In addition, the actively developed open source project, Libtorrent [81], provides a lot of libraries related to BT protocol. The performance of file distribution developed by the Libtorrent library has proven to be effective by another researcher [76].  
In massive deployment, users prefer to store multiple system images in the repository, which can be achieved by the authors' previous work [3]. Therefore, various OSs and applications can be available for deployments in different scenarios. However, a mechanism that can be used to send the blocks of the file system from the previously saved image should be developed. By converting the previously saved image data to the blocks of the file system, the BT client program (e.g., Enhanced CTorrent, Transmission, or Ezio) can distribute the FSBT data to all of the clients in the BT-based solution. The procedures related to the P2P-based massive deployment, which is compatible to the authors' previous work [3], can be achieved by using the FSBT mechanism illustrated in Figure 4. In the first step, the image of the OS and applications is kept in the image repository in the local hard drive of the image server. The image is then converted to FSBT files. The metainfo file of the image is created. Once the metainfo and FSBT files are ready, the tracker will be initiated. Finally, the BT clients can be initiated to deploy the system.  
As for the machines to be deployed, for example, if some specific peer--namely, peer \(x\)--deploys the OS and applications to the first partition in the hard drive (sda1), the metainfo file for sda1 (i.e., sda1.torrent) will first be received from the image server. Then, based on the information provided in the metainfo file, peer \(x\) can receive and send the FSBT data to other peers by using the BT-based  
Figure 3: The proposed system architecture for P2P massive system deployment.  
solution. Since the image server has the complete FSBT data for sda1, which means the image server is a seeder, only the FSBT data must be forwarded to other peers. There is no need for the peer on the image server to receive the FSBT data from other peers. After other peers receive the FSBT data from either the image server or the rest of peers, the FSBT data can be written to their local hard drives. Those peers with the FSBT data can start sending these data to the rest of the peers by reading those data from their local hard drives. This BT solution enables all of the peers to be servers and clients. Hence, the massive deployment efficiency can be greatly enhanced.