# 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
In order to obtain further decentralization of the service, such as not to introduce a _single point of failure_ in the load balancer, while also not overloading it, we can also use, besides the DNS A records, DNS NAPTR and SRV records, as can be seen in Figure 1. With these entries, it is possible to specify more IPs of machines on which instances of the load balancer is running, being also able to establish preferences and priorities for contacting these nodes, and also relative load percentages for requests addressed to each of the load balancing nodes. To summarize the idea, we have a pre-fixed group of nodes, called load balancers, among which at least one is always active, nodes that are registered under the same DNS name and offer the load balancing function by acting as a team of equals. This implementation for a service with high availability improvements defines weights in DNS records, for each of these load balancers, to specify maximum admissible loads and usage priorities, all of which being computed based on the processing capacity of the machine, the network quality and, last but not least, on the probability that the node is functional at a given moment. Note that the load balancing nodes do not offer the effective service functionality, but they redirect the clients to active nodes that effectively offer the service, and which are members of a Chord ring, which are also logically connected via the clients' data saved in the highly available database [7] involved in the solution presented here. From an architectural point of view, the load balancer contains the following components, which can be viewed in Figure 2: (1) a component representing a link with the DNS configuration; (2) a component to map the clients' requests, and thus the clients, to the nodes belonging to the Chord network; (3) a component that is able to \"speak\" to the Chord network, being able to ask the designated service node to serve the client, by _routing_ the client's request to that service node. This is the way in which the client-server connection is finally being established in this session. Note that, even if during a certain session the client should be handled by the same DHT peer running the service, at a new session initiation request from the same client, it could be transparently handled by another service node, the persistence of the client's data being assured by the decentralized highly available database involved in this solution. In case of a failure from a service node, the situation is treated as a timeout situation and the load balancer will help in initiating a new session of the client with an active peer providing the service. Figure 1: Single entry point for the DNS configuration. The dispatcher performs the following steps, described by Algorithm 2, when trying to map a new client request onto a DHT peer running the service. Note that in the algorithm HA stand for \"high availability\". ```
1:for\(iteration=1,2,\ldots\infty\)do
2: Wait for a new client having a request to be processed by the HA service;
3:\(client\Rightarrow uniqueChordID(NewClient)\);
4: Send a message to the DHT Chord ring with destination \(ChordID(NewClient)\);
5:endfor
```

**Algorithm 2** DispatcherLoadBalancing. Each Chord peer by default waits in an infinite loop for new communication messages via the DHT layer. As soon as it receives a message towards a destination, based on its routing table whose entries are called fingers, each Chord node sends the received message to its next hop, until the messages reaches its destination, i.e., either the destination specifies exactly the peer's Chord ID, or the range of Chord IDs, called keys, that do not denominate any other Chord peer, but are the Chord IDs that the current peer is in charge of, as already described in Section 2.2.