# An ICN-Based IPFS High-Availability Architecture
## 2 Related Work
### Availability of IPFS
#### 2.1.2 Link Availability  
The link availability for IPFS is mainly affected by the resolution and downloading mechanism. IPFS retrieves information through a content identifier (CID), and each CID is a unique identifier generated from the data content, which means that different content necessarily leads to different generated CIDs, and the CIDs have the same length as the node IDs. The data producer uploads the data to the network and the IPFS system breaks the data into blocks and uses the Merkle-DAG [23] structure to ensure the integrity of the data. These data blocks are still stored locally, but the index information of the data will be placed on multiple nodes that have the maximum Hamming distance from the CID. The requestor of the data gets the CID of the required data block through IPNS, uses the distributed hash table to find the index information of the storage peer of the data block, and then gets the data from the peer, in which IPFS supports various transmission protocols, such as TCP, UDP, QUIC, etc. The most used protocol is still TCP. Finding the index information of CID data blocks through DHT is called resolution. Getting data from a peer is called downloading. [PERSON] et al. pointed out that the current IPFS use of routing protocol (Kademlia [24]) causes bottlenecks in IPFS in terms of the lookup latency of information [15]. IPFS routing is done by maintaining a distributed hash table (DHT) with 256 K-bukets, which can store up to 20 peer points of information in each K-buket, to ensure the connection of nodes to the network, and based on the ping operation to confirm whether the node is online or not. However, the lookup operation of the Kademlia algorithm takes \(\lceil\log n\rceil+c\) time, so the time of resolution delay increases with the number of nodes [24]. At the same time, we must recognize that through DHTs as routing mechanisms, each access implies a series of routing steps to retrieve it. Although most DHTs define efficient routing algorithms, the traffic on the network increases by a factor proportional to the number of routing hops required to access the content and cannot guarantee a low latency for data retrieval [25]. In the traditional DHT routing mechanism, each request is considered as a separate task. Even when the same content is requested, it needs to go through the same route. These tasks can obviously be simplified with historical information, reducing the latency and bandwidth required for the request. Therefore, Protocol Lab designed Bitswap for IPFS [26]. Bitswap is a P2P network data block exchange protocol that focuses on the rational use of historical information from the DHT routing mechanism, allowing each node to maintain a unique list of peer points. Through the Bitswap protocol, IPFS nodes are able to filter out IPFS nodes that meet certain criteria from the history of communication and include them in their peer list. The judging criteria can be based on a combination of latency with the peer point, completion of historical requests, etc. Before data acquisition, a data acquisition request is made to the peer in the Bitswap mechanism, and if the acquisition fails, a DHT is used to obtain data from the network, but the peer can also keep an eye on the data for the requester. The Bitswap mechanism can effectively increase the success rate of data retrieval and reduce the time of data retrieval. However, the Bitswap mechanism requires the establishment of a session window between the requesting node and the peer node, which leads to a proliferation of duplicate packets in the network by increasing the interaction information between nodes in the network, and these packets consume a large amount of bandwidth resources. In terms of data delivery, users also acquire only one copy of the data and discard the same packets reached later. Currently IPFS is using deletion signaling to reduce duplicate packets transmitted between nodes.