# Towards a Highly Available Model for Processing Service Requests Based on Distributed Hash Tables
## 2 Materials and Methods
### System Scalability Based on the Intrinsic Properties of the Chord DHT
Given that the peers are placed on the Chord logical ring in the increasing numerical order of their Chord IDs, the range of the keys that a Chord peer is in charge of starts from its predecessor's ID on the ring plus 1, i.e., \(ID_{Predecessor(IDper_{ct})}+1\), and ends with the current peer's Chord ID, itself, i.e., \(IDper_{ct}\). **The link with the DNS configuration** for the load balancer renders the \"single system image\" (SSI) for the distributed service. It defines a standard and easy to use interface, in order to be able to access the service, without overloading the system entry point. Figure 2: Individual architecture of a load balancing node. The component that maps clients onto service nodes has the unique role of computing the Chord key of each client, by using the hash function used within the Chord DHT. Further, this component is the one responsible to construct, from the client's original message to the service, the message that will be sent to the service node, in the \"language\" understood by Chord, i.e., to route the message to its destination via the DHT transport layer. The Chord component of the load balancer knows that, based on the message the _component that maps the clients onto service nodes_ provides, it should send a request using Chord mechanisms, towards the peer that will have to serve that client. The identification of the service node responsible for the client is made using Chord keys, by computing a hash of the client's name. #### 2.3.2 The Peer-To-Peer Chord Network

As already presented in Section 1.1, a Chord network is a totally decentralized DHT-like network. In any Distributed Hash Table (DHT), the nodes' tasks are split based on the nodes' and task's unique identifiers, generated by the hash function, and _this_ implicitly provides a _load balancing_ among the nodes' responsibilities, i.e., the number of data keys the node needs to handle [9], as already explained in Section 2.1. In fact, it is exactly this _special feature_ of the Chord DHT to implicitly balance the load by itself, that this novel solution aims to use, together with the previously mentioned load balancer, in order to obtain a uniform distribution of the load among the nodes providing the service and to finally make the request processing service highly available. From an architectural point of view, a node from the Chord network has two parts: (1) an self-extending enhanced Chord component, for better persistence and integrity of the data that it holds; (2) an instance of the distributed service, since this novel solution implies that each member of the Chord ring also runs an identical, unaltered instance of the request processing service. In other words, in the current novel approach for high availability, the exact application that provides the request processing service is instantiated on every node of the Chord ring and, by using the Chord hash function, the clients are mapped onto different peers in a balanced manner. The _good dispersion properties_ of the DHT's hash function will enable an equitable partition of the distributed network service's clients among the Chord peers that offer the service, so that none of the peers will be stressed with too much load. In the current improved approach, in case the load of peers becomes too high, the system should launch a new peer in the overloaded area of the Chord ring, as described in our team's previous work [41; 42]. The partitioning of the clients is performed considering the following logical mapping: knowing that each peer \(p\) is responsible for a set of keys, for which it should also store the corresponding data, the _responsibility of a peer for a key_ is redefined and extended, as being the responsibility of that peer to handle the _service client_ that is associated to that key. This way, once a client has been handled by a peer, as it is described in Figure 3, we impose the rule that the client will be always handled by that peer, throughout the session.