# 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
Note that, in many cases, the ID towards which a message is routed is not the ID of any peer in the network, and each peer is aware that it is responsible for the Chord IDs also called _data keys_ between its predecessor and itself:

\[ChordID_{predecessor(p)}<ChordID_{key(p)}\leq ChordID_{p}.\]

If analyzing the maximum number of steps needed by the DHT routing algorithm for Chord



more than \([log_{2}(No_{p}eers)]\), with high probability, where \([X]\) represents the integer part of the real number \(X\). ### The Novel Improved Model of Splitting the Work Around the Nodes

The improved model for highly available request processing is to split the work around the nodes providing the service. The solution is based on a front-end load balancer, which interacts with a set of nodes, each of which being also a DHT peer, and each of which being also a simple node providing the actual service of processing clients requests. In order to avoid a _single point of failure_, the load balancer chooses the server node to currently handle and process a client's request, by computing a hash of the client's name, and by then forwarding the client request to the service layer running of the DHT Chord peer, that is responsible for the computed hash key of that client, as is detailed in [9]. Then the client-server conversation between _that_ client and the chosen server happens in a classical manner. As explained in Section 2.1, this is an important load balancing step, which also allows the system to be transparently scalable, since if peers become overloaded, new peers running the service can be added to the DHT. The Chord DHT is actually used as a _transport communication layer_ in the solution for improving the service's availability when processing the clients' requests. In order to address fault tolerance, besides the DHT, the load balancer is also of help. If the communication line between a client and the server, that the client already communicates with, falls, the load balancer re-catches the client's attempt to reconnect to the service. Consequently, it redirects the client to another, functional peer, providing the service of processing clients' requests, thus finally fulfilling this client's processing request. The load balancer will actually control the access to the Chord network using DNS node configurations, as will be described in what follows. #### 2.3.1 The Load Balancing Component

The purpose of the load balancer is to offer its clients a single entry point to the system, by defining a robust interface, which is also easy to use by the clients. It has a double role, since the load balancer is also responsible to hide the nodes that form the Chord ring, nodes which collaborate to offer together the desired service. The idea of a load balancer in front of a Chord network is not new, because the _bootstrapping_ mechanism described in [9], for new nodes to join the DHT, is based on links with the DNS layer of the node. This way, if a node wishes to join the Chord network, if the node knows only the name of the service, it will perform an _A record_ DNS interrogation [40], to find out the IP of a machine that contains a Chord peer for sure. The choice for the current implementation was to introduce in the DNS entry of the node that offers the highly available service, an A type record, which will solve the load balancer's IP (or set of IPs), namely the entry point to the distributed service. This approach does not restrain the decentralization and availability hypothesis, since the improved solution presented here strongly resides on the one used for Chord bootstrapping, and Chord is considered to be one of the most decentralized and available distributed networks.