## 3 Description of the Chosen DHT Algorithm  
There are in the literature a large amount of DHT routing infrastructures based on P2P systems, and a possible taxonomy is presented in [54] Examples of DHT protocols include Chord [61], CAN [62], Pastry [63], and Tapestry [64], among others. They differ mainly in how peers maintain their routing tables to guarantee an efficient content location [65].  
Among all of possible DHT routing protocols listed before, the Chord protocol has been chosen as lookup algorithm in this work. The reason is that Chord is the most popular structured routing protocol [54; 66] and it has several features that distinguish it from the other DHT lookup algorithms. These characteristics are [67]: (i) Chord is a completely distributed system, meaning that all nodes have the same role in the system; (ii) Chord properly scales for a large number of nodes; (iii) Chord nodes can always be found, even if they are continuously entering and leaving the network.  
Although the DHT-Chord protocol has been chosen to build up the proposed lookup algorithm, it is worth noting that the proposed concepts are independent of the chosen DHT protocol and they can be easily extended to other protocols. The Chord DHT-overlay organizes peers on a virtual ring topology ranged from 0 to \(2^{m}~{}-~{}1\) (Figure 4a), where \(m\) is the number of bits in the identifiers. In this protocol each node is responsible for a collection of keys between its predecessor and itself for resource lookup (key-space). In this way, the resource ID is stored in the first peer, whose ID \(\geq\) Resource ID (see Figure 4b). Each node in the ring upholds a routing DHT table, called the finger table, which is used by the lookup algorithm (Figure 4c).  
Figure 4: Chord protocol operation.  
The lookup algorithm is started by one node in the ring in order to find a particular key in the space-keys or by an external request and follows two steps [54; 66; 68]:  
1. Firstly it checks if the node that started the search is in charge of that key. If this is true the search is over and the algorithm ends.
2. Otherwise the node will employ its finger table to localize the closest successor of the target node's key and request the search of the key to the target node.  
Let us consider an example. When peer #6 is searching the resource whose ID is 16, i.e., the target node will be peer #3, which is the node that stores ID = 16 (see Figure 4). The peer #6 verifies if is in charge of that key. As it is not responsible for this resource, it will check its finger table records. The finger table of peer #6 stablish that the nearest peer to the destination is peer #15 (see the finger table of N6 in Figure 4c), and it sends the request to this successor. As the peer #15 is also not responsible for this resource, it would also check its own finger table, searching the closest peer of the target's node. The finger table of peer #15 establishes in this case that the closest node to meet the request is peer#3 (see finger table of N15 in Figure 4c), thus it forwards the message to this successor. Peer #3 has the resource and it is the destination, so the process ends.  
In a P2P system, each peer can join and leave the system at any arbitrary time. Chord adapts efficiently as nodes join and leave the system, and can answer queries even if the system is continuously changing [24]. This means that the finger table is dynamically built through a stabilization mechanism.