# An ICN-Based IPFS High-Availability Architecture
## 2 Related Work
### Availability of IPFS
#### 2.1.1 Data Availability  
Data availability is mainly expressed as data being available at the time of request, while the following reasons may exist for data unavailability in IPFS networks.  
* Data is not available due to nodes going offline.
* Data retrieval information is not updated in a timely manner, resulting in the inaccessibility of the latest data.  
IPFS uses the typical owner replication technology, which means that the nodes that have downloaded the data are able to store the data information in the local database. When a node publishes data with high popularity, a large number of requesting nodes in the network are able to realize the proliferation of hot data, and the higher the number of downloads increases, the more copies of data blocks in the net, and the higher the availability of data.  
However, for cold data such as family photos, fewer people request the data, so the number of copies within the network is limited, and may even only be stored on the node where the data are published. When the data node fails or goes offline, then these data may face the problem of not being able to be requested. The IPFS data cache usually has a survival time, and when the survival time is exceeded, the node needs to delete the expired data unless the data are pin-operated by the node.  
Therefore, IPFS networks should be persistent and permanent in order to overcome data availability problems. In traditional distributed networks, replication techniques are usually used in order to improve network availability and reliability [20], so IPFS proposes IPFS clustering to help service providers to achieve multiple copies of data management. However, [PERSON] et al. argue that in the case of mobile networks or other distributed networks affected by high churn rates, it is not enough to achieve data redundancy and availability by building a private network through IPFS clusters, and it may be more convenient to implement data replication through cloud servers or resource nodes in the network [21].  
Compared with the cloud server solution, the resource nodes in the network are closer to the user side, and therefore more suitable for working scenarios that provide low latency and light data transmission. However, traditional intermediate routing nodes of IP networks are only concerned with data forwarding performance and cannot support complex decisions, and new types of network devices are required to enable data replication with all the associated complex policies, such as ICN network nodes.  
In addition, since the data transmission in IPFS are encrypted by the hash algorithm, different data will generate different hash values. Although the correctness of data are guaranteed in IPFS networks, this mechanism also poses some challenges for data updates in IPFS. Whenever the service provider's published data are updated, a completely different content identifier (CID) is generated, which is not perceived by users. Some users continue to use the previous CIDs for data retrieval, and the information obtained will not be real-time, so IPFS uses the URL mechanism to publish updated data through Interplanetary Name System (IPNS) [22] and Domain Name System Link (DNSLink) technologies.  
IPFS maintains link information for all publishers via IPNS, which is in the format of /ipns/data provider's public key hash. The data provider stores variable, signed records under this link, and the user is then able to access the CID of the latest content published by the other party through this information. While DNSLink and IPNS work in a similar way, IPNS relies primarily on public keys, and while DNSLink uses the same readable links as DNS, DNSLink for IPFS is an incremental evolution based on the existing DNS network.