# 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 the maximum of 2 s, which has been measured, is needed only for peers that find themselves far from each other on the Chord ring, but for neighbor nodes, which are also backups for each other in Chord, the time is far lower. The delay for any peer to find out that the peer for which it was the backup has left the network is most often around the value of _the sum_ between the configured _stabilization time_ within the Chord network and _the time_ needed _to route_ a message one hop away via the DHT, which is between 1-2 ms, as can be seen from \[Finger_{k}\approx ID_{p}+2^{k},\]4 Moreover, note that the Chord stabilization time interval, which is a time interval when periodically each peer pings the peers in its finger table, is a value that can be configured in

\[Finger_{k}\approx ID_{p}+2^{k},\]5 The extra time needed by the DHT to re-stabilize after a peer join or a peer leave. each peer, according to the system's best balance and needs. Since this solution is, to its authors' knowledge, the first to use the DHT for reliable request processing and not just for reliable data storage, it is the first to benefit of the DHT derived features of _topology update awareness_, in a time interval that can be configured to be sufficiently low, if this is vital to the request processing service. #### 3.2.2 The Improvement in Load Balancing

The current solution balances the load of the entire set of peers transparently and fast, based on the powerful properties of the _distributed hash_, which have been described into detail in Section 2.1. Any hash table classically gives a fast and constant means to access various data, while a good _distributed_ hash table, such as Chord, succeeds to fulfill this purpose by _evenly_ distributing the keys among more peers belonging to the DHT. The _even_ distribution of the keys on peers, which actually directly translates into peer _load balancing_, is a direct consequence of: (1) the features of a good hash, such as SHA-1 [38] and (2) the smart idea behind the DHT such as Chord, to have a unified space for the peer IDs and the data keys. Moreover, since it relies on both of them to function well, load balancing finds itself at the confluence of fault tolerance and scalability, both having been evaluated experimentally in this section. ### Evaluation Conclusions

In conclusion, seen as a whole, the extra time that the decentralization solution for a highly available service running in our datacenter introduces, in comparison to the single node server, is not very high. The extra time experienced by the client when it receives the reply to its first message to the request processing service, is actually the time needed to route a message in the Chord ring of about 128 peers. This translates in the fact that there is a certain cost for the benefits of load balancing and decentralization, fault tolerance and scalability that Chord brings with it, but this time cost is perceived only for the first message of the session initiated by the client, and also in cases of re-connection. For the rest of the session, there is no extra delay introduced by the new layers of the decentralized distributed service. The enhanced Chord ring is actually the main component for decentralizing the distributed service, via its intrinsic unique mechanisms [9], also previously evaluated in [42]. The authors wish to point out the fact that, from the current implementation and experiments for improving high availability, _the DHT is essential_ in the observed increase in availability for the distributed service. In itself, any DHT is a scalable system, balanced and fault tolerant, also allowing many improvements and extensions, some of which also being new contributions described in this paper and evaluated in this section. During the measurements that have been performed in this work, the aim was to minimize the time impact of the components and the algorithms that maintain a highly available infrastructure for the request processing service, throughout the entire evaluation process.