Based on the theory of DHT, many researchers develop platforms, that implement different kinds of DHT and provide interfaces and services to applications. DHT translation from theory to platform is not a simple work. In this procedure many problems and requirements will be exposed, such as load balance, multiple replicas, consistency, latency and so on. Some platforms only complete the basic functions including implementing specific DHT and providing interfaces to the upper applications, such as Open Chord, Chimera, FreePastry and Khashmir. Besides the fundamental implementation, some also supply specific services, such as CoDeeN and CoralCDN for caching, hazelcast for data distribution. Some supply additional guarantee, such as GNUnet for privacy and security. Some focus on providing a platform for connecting all kinds of devices, such as JXTA. In the following, we introduce the key design properties and characteristics of several DHT implementations in both academic/open source platforms and commercial platforms respectively.

3.1 Academic and Open-Source Platforms

In this section, we introduce 11 platforms that implement various DHT techniques, including Bamboo, CoDeeN, CoralCDN, OpenDHT, JXTA, GNUnet, Open Chord, hazelcast, i3, Overlay Weaver, Cassandra. They are all open-source platform, that are free and allow other people to contribute to the system, which facilitates the platform to grow and improve, but on the other hand, limits the maintenance and stability of the system.

3.1.1 Bamboo

Bamboo [11] is a Pastry based DHT platform written in Java. The first release was written in December 2003. The latest version was published on March 3, 2006. Although Bamboo is built on the base of Pastry, it has several improvements especially in peers’ joining and leaving problem, which is called “churn.”

Bamboo performs well under high levels of churn [20] by three technologies. The first one is “static resilience to failures.” This technology allows node to route messages even before recovery. The second one is “timely, accurate failure detection.” In a P2P system where churn happens normally, it is quite often to send messages to a node that has left the system. So the timely failure detection is very important. Bamboo detects the failure by setting a proper timeout. If the timeout is too short, many massages would be re-routed and the target node is mistaken as a failed node. On the contrary, if the timeout is too long, the requesting node would waste time waiting the response from a left node. For choosing an accurate timeout, the nodes in Bamboo probe the latency actively. Furthermore, Bamboo uses recursive routing to solve the problem that how to actively probe any node in the network. The third one is “congestion-aware recovery.” In this technology, Bamboo simplifies the Pastry’s joining algorithm, which allows a node to join the network more quickly. In the leaf maintenance, Bamboo adds a “pull” operation which is a reply to the “push” message of nodes, while Pastry only has a “push” operation, that a node sends its entire leaf set to some neighbor nodes which is randomly chosen in the set. This “feedback” method greatly increases the consistency of the information that nodes maintain, especially in high churn situation. Bamboo provides two algorithms called “global tuning” and “local tuning” respectively, which optimize the route table all the time. Therefore, you may find that the nodes in Bamboo keep changing their neighbors, even no node joins or leaves the network.

Since Bamboo is constructed by Berkeley, it incorporates into other Berkeley projects easily, such as OceanStore and PIER [49]. Meanwhile, Bamboo is running as an OpenDHT project [50], which allows anyone to put and get key-value pairs into it only using XML RPC or Sun RPC. This make it much easier to run the DHT individually.

3.1.2 CoDeeN

CoDeeN [14] is an academic content distribution network (CDN) for PlanetLab [51] by the Network Systems Group at Princeton University. It consists of high-performance proxy servers which are deployed on PlanetLab nodes. Users are provided a fast and robust web content delivery service. CoDeeN has been built since 2003. At present it is still under development and tries its best to provide continual service.

CoDeeN reduces the response time of Internet by caching the web pages and resources of the remote sites on the proxy servers. These servers locate all over the world, so users can get the resources from the nearest proxy server instead of the original sites. If someone wants to use CoDeeN, she should pick the nearest proxy server from the CoDeeN proxy server list. Meanwhile, this cache technology also reduces the burden of the web site so that can support more users.

CoDeeN also does some work in privacy and security. All accesses via CoDeeN are logged and the logs are monitored for the abuse. CoDeeN uses semi-restricted proxies with several protections against the abuse. For instance, users cannot access the sites containing licensed contents. CoDeeN protects the resources with IP-address restrictions. A number of known virus and attack signatures are tested so that CoDeeN could ban clients attempting to use the attacks.

CoDeeN is an implementation of DHT, which focuses on the web caching. Although it is an academic platform, it provides a large amount of information for the related research, which improves the performance of commercial CDN.

3.1.3 CoralCDN

CoralCDN [7] is a peer-to-peer content distribution network, which is comprised of world-wide network of web proxies and nameservers. The first version of CoralCDN online was deployed in March 2004, which also runs on the PlanetLab [51]. Unlike CoDeeN that users configure the proxy server manually, CoralCDN works in another way. If Users want to access http://www.xxx.com/, they only add a suffix in the way of http://www.xxx.com.nyud.net:8090. CoralCDN chooses the optimal proxy server automatically.

Figure 3.1 shows the process of the CoralCDN. At first, a client sends a request for http://www.xxx.com.nyud.net to its local resolver. Upon reviving the request, the resolver transmits it to a Coral DNS server. The DNS server probes the round-trip time to the client. According to the result, the DNS server finds out the nearest http proxy server to the client and returns it to the client. Then the client sends HTTP request http://www.xxx.com.nyud.net:8090 to this specified proxy. If the proxy caches the proper object, it will return the web pages to the client. Otherwise, the proxy will look up the object on other proxy in Coral. Only if there is no proper resource in Coral, the original website will be accessed.

Fig. 3.1
figure 1

The process of CoralCDN

Full size image

CoralCDN is built on a key-value indexing infrastructure Coral, which is based on distributed sloppy hash table (DSHT) that differs from traditional DHT in several aspects [52]. In DSHT, the PUT operation which puts the key-value pairs in the network does not only consider the distance but also avoids hot spots. Thus the resources would be stored far from the positions of their IDs. In the routing procedure, the router determines the next target which is not the node closest to the destination, but the one whose distance to the destination is closest to half of the local router’s distance.

Coral builds a XOR-tree structure like Kademlia and introduces locality information. Coral uses several levels of DSHT to build a hierarchical routing structure, which is divided by the delay. The higher the level is, the smaller the delay is and the fewer the nodes are in this level. If a request comes, a node in Coral will search proper resources on the highest level because of the smallest delay. If the resources are not found, then the lower level is used. Delay implies the geographical distance of two nodes. So the nodes at higher level probably locate in a smaller geographical coverage.

CoralCDN introduces several properties to extend the classical DHT, especially for avoiding hot spots and increasing speed. In the past years CoralCDN worked well. M. J. Freedman [53] had observed it for a long time, which helps researchers to learn CoralCDN. Compared with CoDeeN, CoralCDN is an open-source implementation, which allows more operability to improve and contribute to it.

3.1.4 OpenDHT

OpenDHT [50, 54] is a platform which provides free and public DHT services. It was established in 2005. Unlike usual DHT model, users of OpenDHT do not need to run as a DHT node. The OpenDHT infrastructure runs the OpenDHT code and provides interfaces to users to connect to it. User nodes issue RPC (Remote Procedure Call) to upper applications. OpenDHT nodes act as gateways accepting the RPC from clients.

OpenDHT places a high premium on simplicity. There are three interfaces to simplify the operations and usages for users. In the three interfaces, routing model is the most general one. It provides general access to each of the nodes on the routing path for the input key. It allows users to invoke arbitrary code at the nodes on the routing path. Lookup model is another interface which is somewhat less general. Compare with routing model, lookup model only provides general access to the destination node for the input key. Correspondingly, code invocation is only allowed on the endpoint. These two interfaces allow application-specific code, which is the true power of the two interfaces. Based on the basic interfaces, developers can generate applications and services with abundant functionality. The third is storage model, which is far less flexible. It provides the put(key, value) and get(key) operations to support storage. This interface does not allow invoking application-specific code, which limits the applications it supports, but it also makes the interface simplicity to use and support.

OpenDHT agrees that public facilities provides limited storage. So the data in OpenDHT has limited lifetime. Moveover, OpenDHT protects the storage from some attacks. It presents two ways, which are immutable puts and signed puts, to fight against malicious attacks to data. Among other things, OpenDHT provides REMOVE function which is handled like regular insertion of keys.

3.1.5 JXTA

JXTA [55] is an open-source P2P platform started by Sun Microsystems in 2001. It consists of several protocols that enable each connected device on a network to exchange messages independently of the underlying network topology. The goal of JXTA is providing services and infrastructure for P2P applications which are independent from operating system and language.

JXTA has three distinct layers [56]. The lowest layer is platform, which contains the core and fundamental functionality, such as peer pipes, peer monitoring, peer groups, etc. The upper one is service, which provides several access to the JXTA protocols such as searching, file sharing, indexing and so on. Application is the top layer, which accesses the JXTA network and utilities based on services. XML documents are widely used to describe services and information available on the JXTA network because of their popularity and ability to be read easily by many languages.

There are six protocols which construct the core functionality and standard services [57], including:

  • Peer resolver protocol (PRP) which is a basic communication protocol providing query/reponse services.

  • Endpoint routing protocol (ERP) which provides a set of query messages that helps peer route messages to the destination.

  • Peer discovery protocol (PDP) which helps peers to announce advertisements and to discover other peers, groups and other information.

  • Rendezvous protocol (RVP) provides mechanisms that enable propagation of messages within a peer group.

  • Peer information protocol (PIP) which is used to query status information form peers.

  • Pipe binding protocol (PBP) which builds a pipe or interface between peers for communicating and routing.

These protocols provide basic functions in P2P network computing. They hide many details in the lower level. Thus it is much easier to develop applications on JXTA. Nowadays many applications and services are developed on JXTA.

The routing tragedy of JXTA is a loosely-consistent DHT walker which combines DHT index and a limited range walker [58]. In this way JXTA can work well both in the high-churn-rate situation and the steady network environment.

3.1.6 GNUnet

GNUnet [15, 59] is a framework for secure P2P networking. Anonymous distributed file sharing based on reputation is the first service implemented on the networking layer. GNUnet is written in C language and currently runs on WindowsTM, Linux, Mac OSTM, BSD and SolarisTM. GNUnet uses Kademlia style routing [60], which is popular in the implementations of DHT.

The goals of GNUnet are deniability for all participants, distribution of contents and loads, and efficiency in terms of space and bandwidth [61]. It provides authentication and protective security against particular attacks in the network layer. Meanwhile, a file sharing service providing full anonymity is implemented in the application layer. Every peer in GNUnet inserts content anonymously and claims ignorance. Content migration is used to prevent the publisher being located. Hence, the adversary cannot confirm the content publisher unless performing full traffic. The traffic is protected by encryption and encoding, which achieve the aim that none of the intermediaries knows the content while the receiver can decrypt it.

In GNUnet, the file is split into several GBlocks. Each block is only 1k. So it is convenient to migrate file even the file is large. The file may be maintained by multiple nodes. It avoids the traffic-burst in migration since the load is distributed to plenty of nodes. The blocks are encrypted, so the content is hidden from the intermediaries in transmission, even the maintainers if they do not have keys.

GNUnet is able to avoid content from malicious hosts. GNUnet uses a double hash method for content and query. The first hash value is used as the encryption key. The second hash value (the hash value of the first one) is used to locate the data. Since the data transmitted in the network is encrypted, the privacy is preserved from malicious nodes. Moreover, using hash value as the key solves another challenge. If two parties insert the same file in the network independently, they will use the same key (hash values of files are the same). The two versions can replace each other even they are encrypted.

GNUnet applies indirection mechanism for anonymity. Indirection hides the source, since it claims that it just indirects the packets. However, this scheme costs too much if all the nodes in the transmission path. In GNUnet, indirect queries are decided by the receivers freely or randomly whether or not to indirect the reply, which decreases the cost without reducing the security. Furthermore, GNUnet reduces the influence of malicious nodes as possible as it can. When a new node joins GNUnet, it is treated as untrusted one that the established nodes reply the new node’s query only if they have excess bandwidth. The reputation tragedy is used so that the malicious nodes have little influence. In this way, GNUnet reduces the harm of malicious nodes greatly.

The significant distinction between GNUnet and other file sharing system like Gnutella and Napster is that GNUnet gives stronger security guarantees that it is more resistant to attacks. In 2011, GNUnet was again reachable via IPv6. Now it fully supports IPv6.

3.1.7 Open Chord

Open Chord [62] is an implementation of the Chord DHT. It provides an interface for P2P applications for quickly storing and retrieving data from Chord. Open Chord is written by Java and is distributed under GNU General Public License (GPL), which allows Open Chord to be used and extended for free.

Open Chord is divided into three layers [63]. The lowest layer is communication layer that employs communication protocol. The protocol is based on a network communication protocol such as Java Sockets. On the communication layer, the communication abstraction layer is implemented. This layer hides the details of the communication and provides interfaces for synchronous communication between peers. On top of the communication abstraction layer, a Chord logic network resides. This layer provides two interfaces to applications for storing, retrieving and removing data in the Chord DHT synchronously and asynchronously. This layer implements the properties of Chord DHT described in [6].

Open Chord provides interfaces and APIs so that applications can be easily implemented when they want to employ Chord DHT. Now the latest version is Open Chord version 1.0.5, but the manual is still for Open Chord version 1.0.4. This manual shows some limitations of version 1.0.4, such as prohibition of remote class loading, changing the communication protocol easily, trust in all the participant of the DHT and so on. Nevertheless, Open Chord still is a good implementation of Chord.

3.1.8 Hazelcast

Hazelcast [8] is a clustering and highly scalable data distribution platform for Java, from which developers can easily design and develop highly scalable and reliable applications for their businesses.

In Hazelcast the data is almost evenly distributed across all nodes, which means each node carries (\(\frac{1} {n}\) “total data”) + “backups,” where n is the number of nodes in the cluster. If a node fails, the data it holds will be dynamically redistributed to the remaining live nodes by the backup replicas stored on other members. When a new node joins, it will be responsible for almost (\(\frac{1} {n}\) “total data”) + “backups” to reduce the load on others. In Hazelcast’s data structure all nodes have equal rights and responsibilities. The distribution of data and organization of the nodes are based on DHT. So there is no single cluster master that may cause single point failure.

Hazelcast provides many distributed technologies to support the distributed data management [64]. It implements the Distributed Queue, Distributed Set, Distributed List and Distributed Map based on java.util.{Queue, Set, List, Map}. A distribution mechanism Distributed Topic is provided for publishing messages that are delivered to multiple subscribers. Furthermore, Distributed Lock is deployed and Distributed Events is used to satisfy the distributed environment. Moreover, Hazelcast has other functionality and features which make Hazelcast manage the distributed data better.

Although Hazelcast is developed by a company, it is a real open source platform, where the source code can be downloaded at http://code.google.com/p/hazelcast/. ZooKeeper [65] is another system which provides similar function with Hazelcast, but instead of Hazelcast’s DHT, ZooKeeper is based on master/slaver model.

3.1.9 i3

i3 [66, 67] is an overlay-based Internet Indirection Infrastructure that offers a rendezvous-based communication abstraction to provide services like multicast, anycast and mobility. Every device connecting to i3 infrastructure is associated with an identifier, which could be used to obtain delivery of the packets. i3 stores the triggers. When one host wants to send packet to another, the packet will be assigned an identifier too. i3 would transmit the packet to the proper destination based on the trigger of the identifier. For example host R inserts a trigger (id, R) into i3, then all the packets with identifier id would be received by R.

Multicast, anycast and mobility are three fundamental communication services that i3 provides. Suppose there is a mobile host with a trigger (id, R) in i3. When the host moves from one location to another, it will be assigned a new address R′. The trigger in i3 is changed from (id, R) to (id, R′). So the sender need not to be aware of the current address or location of the mobile host, instead he only knows the identifier of the destination. If some packets will be send to a group of hosts, all the members of the group register triggers with the same identifier. What’s more, i3 provides another scheme to support anycast. In this case, the identifiers of receivers share a common prefix p. When the packet with the identifier p|a, where p is the prefix and a is the suffix, is sent to the group, the corresponding receiver would be chosen by the longest matching prefix rule. Furthermore, i3 supports the mechanism of identifier stack, which allows applications to insert some transcoders in the routing path of packets. This service supported by i3 greatly facilitates many applications such as watermarking in the video stream, video format conversion.

i3 is an open source implementation of Chord. An instantiation of i3 has been running on the Planetlab. i3 can be used in many useful applications, such as connecting to home machines, secure intranet access, middle-box applications. i3 works like a cloud, in which the id-address pairs are stored. The hosts do not need to take care of the accurate address of the destination. They only assign the identifier of target to the packets which will be sent, regardless of multicast or unicast, mobile host or fixed one. i3 hides the details of the implementation to the applications, which gives us an easy way to use it.

3.1.10 Overlay Weaver

Overlay Weaver [68, 69] is an overlay construction toolkit which provides a common API for higher-level services such as DHT and multicast. Overlay Weaver is an open source implementation. It currently implements many structured routing algorithms including Chord [6], Kademlia [33], Koorde [24], Pastry [43] and Tapestry [44], and also supports unstructured algorithms.

Fig. 3.2
figure 2

Decomposition of runtime in Overlay Weaver

Full size image

Overlay Weaver is designed in a modular manner, i.e., it can be divided into several components. Figure 3.2 illustrates the components of Overlay Weaver. The lowest layer is routing layer, which is corresponding to key-based routing. This layer has been decomposed into three parts: Messaging Service, Routing Algorithm and Routing Driver. Messaging Service deals with communication between hosts. Routing Algorithm implements many kinds of routing algorithms. Routing Driver conducts the common routing process and provides uniform interface to the upper layer. Based on the routing layer, the higher-level services layer is deployed. In addition to DHT, it provides the Mcast, which performs a multicast on an overlay. This level supports abstract interface to applications layer, which makes it easy to develop applications on Overlay Weaver. Furthermore, Overlay Weaver also provides Distributed Environment Emulator which can emulate tens of thousands of nodes on a single computer virtually. It brings results of algorithm researches to applications directly, which gives developers and researchers much more facilitation.

3.1.11 Cassandra

Cassandra [9], originally designed by FacebookTM, is a distributed structured storage system deployed on a large amount of commodity servers. It provides a NoSQL database to precess plenty of data and has been employed by many famous companies like FacebookTM, TwitterTM, DiggTM, CiscoTM, etc. Cassandra is an open source implementation since 2008. Now it is developed as an Apache [70] top level project.

Cassandra combines the data model of GoogleTM’s BigTable [71] and distributed architecture of AmazonTM’s DynamoTM [12]. It is designed to run on large-scale distributed systems handling very high write throughput and achieving scalability and availability. Rather than exception it treats failures as the normal situation. It provides database interface composed of three APIs: insert(table; key; rowMutation),get(table; key; columnName), delete(table; key; columnName). It is so easy to use, but on the contrary the internal implementation of Cassandra is not an easy job. Cassandra is hoped to process the ability to scale incrementally, so consistent hashing using order preserving hashing is used. Meanwhile, a token method is used for scaling the cluster. High availability and durability are achieved by replication. Cassandra provides several replication policies to meet various situation and requirements. For failure detection, a modified version of the \(\Phi \) Accrual Failure Detection [72] is used, which introduces a dynamically adjusted parameter \(\Phi \) which reflects network and load conditions.

Cassandra can be treated as a NoSQL database with four prominent characteristics [73]. Firstly, Cassandra is decentralized, where no master exists which would introduce single point of failure. Secondly, read and write throughput increase linearly with addition of new nodes. The performance improvement can be realized without downtime and interruption to applications. Thirdly, multiple replicas of data in Cassandra exist at any time for fault-tolerant. Node failure can be solved without downtime. Lastly, Cassandra supports a tunable level of consistency, which allows users to choose a tradeoff between write and read in different application scenarios. Cassandra is an outstanding distributed database that achieves high update throughput with low latency, even it still is perfected by Apache committers and is contributed by many corporations [74].

3.2 Commercial Platforms

In this section, we present four commercial DHT platforms, including WebSphere eXtreme ScaleTM, DynamoTM, SandStoneTM, and Service Routing Layer.

3.2.1 WebSphere eXtreme Scale

WebSphere eXtreme ScaleTM [10] is a proprietary DHT implementation by IBMTM used for object caching. It performs as a powerful distributed cache system to speed the access to data.

For improving the performance of computer, engineers add several levels of cache between memory and CPU. The cache can increase the speed of access data. This technology can be used in network similarly. WXSTM puts two levels of cache between data source and users that greatly speeds the access. However, the key difference between computer and network in caching is that the caching mechanism in computer is centralized while it is distributed in network. WXSTM organizes the cache in DHT way. In WXSTM the most fundamental component is the grid. Data is stored as key-value pairs in the maps. Several maps are contained in the grid. The map sets can be partitioned into parts which are maintained by multiple containers. In this way the cached data are organized between plenty of machines.

Fig. 3.3
figure 3

Structure of ObjectGrid of WXSTM

Full size image

Figure 3.3 illustrates the outline of high performance access using WXSTM, where the client is searching proper data. In this procedure, ObjectGrid API firstly searches the data in the Near cache. If nothing is found in the Near cache, it will locate the shard in the grid who contains the querying data. Here shard is the instance of data (or a portion of data split by WXSTM). If the result is still not found, the data would be loaded from the Back-end datasource. In this scenario the client, Near cache, shard and datasource resembles CPU, L1 Cache, L2 Cache and main memory in computer respectively.

WXSTM provides distributed object caching essential for elastic scalability. Every map set has four or three partitions and each partition has one or two replicas [75]. The Characteristics of WXSTM are high performance and elastic scalability, but the performances are greatly influenced by the cache hit rate. So WXSTM should be deployed with adequate consideration so that the power of WXSTM would be leveraged sufficiently.

3.2.2 Dynamo

AmazonTM is one of the largest e-commerce operations maintaining a large number of servers and data centers all over the world. It runs a world-wide e-commerce platform to millions customers, which has strict requirements to the storage system in terms of performance, reliability, efficiency and scalability. DynamoTM [12], a component of the platform of one of the largest e-commerce corporations which maintains a large number of servers and data centers all over the world, is a key-value completely distributed storage system that provides an “always-on” storage experience, satisfying the customer’s strict requirements to the storage system in terms of performance, reliability, efficiency and scalability to AmazonTM’s core applications and services. It provides a DHT-typical simple primary-key only interface to meet many services on AmazonTM’s platform.

DynamoTM deploys many technologies to solve the problems in large-scale distributed storage systems and achieve high usability and performance. Firstly, DynamoTM uses a variant of consistent hash that each node is assigned to multiple points in the ring, which could balance the load by the number of virtual nodes that one physical node is responsible. Meanwhile, one piece of data is maintained by multiple nodes in the form of replicas, which could achieve high availability and durability. Thirdly, vector clocks are used to provide eventual consistency, and consistency of read operation is guaranteed by quorum scheme which requires R + W > N, where N, R, W are the number of replicas, the minimum number of nodes that must participate in a successful read or write operation respectively. Fourthly, hinted handoff and replica synchronization in which inconsistencies are detected by Merkle trees are used to handle churn and failures of nodes. In this manner, DynamoTM is running to support thousands of millions of users and many demanding services.

During these years, some criticisms about DynamoTM exist, especially DynamoTM is regarded as “a flawed architecture” [76]. However, DynamoTM is still running well and provides several core services. Argument and debate are not always bad things. On the contrary, intense discussion makes people know concept better, which helps us to perfect applications and services.

3.2.3 SandStone

SandStoneTM [13] is a DHT based key-value storage system developed by HuaweiTM. The name “SandStone” means that “the enormous sand-like tiny PCs’ capability is united as an invincible cornerstone of distributed infrastructure.” SandStoneTM is a highly decentralized, loosely coupled architecture with carrier grade performance. It performs good scalability, strong consistency, high reliability which can meet or exceed “five nine” high availability standards.

Fig. 3.4
figure 4

The architecture of SandStoneTM

Full size image

SandStoneTM architecture is depicted in Fig. 3.4. It consists of four components. The top layer is the data storage module, which takes charge of storage. It is composed of many functions and submodules to manage the data including data consistency verification, data storage and data restoring. The middle layer is the key based routing module, including ID allocation, DHT routing protocol and peer failure detection. The bottom layer is the communication module, which completes the intercommunication between peers and hides the connection details from the upper layers. The configurations and statistics module manages and configures the other three layers.

SandStoneTM applies many technologies to increase the performance of the system. SandStoneTM uses an ID allocation method called “Strip Segmentation” to let peers carry region indication. To makes good use of region information, SandStoneTM is composed of a global DHT and several logical region DHTs, which are used not only to decrease the backbone network overhead, but also to reduce the latency. Furthermore, besides the finger table in Chord, SandStoneTM makes a further step to add an extra One-hop Routing Table, which could reduce the latency further to meet the latency sensitive applications. To achieve high availability and durability, SandStoneTM replicates data on multiple peers. Unlike DynamoTM storing replicas successively, SandStoneTM stores them more dispersedly. In order to keep these replicas consistent, SandStoneTM also modifies the “quorum” technique to provide optimized eventual consistency.

3.2.4 An Overlay Platform: Service Routing Layer

In the past the network service providers usually offer IP packet delivery service and other IP-based services. With the growing requirement to multiple multi-level services, a service routing layer is proposed. It is an overlay platform [77]. Figure 3.5 shows the service routing layer lying on the IP layer. Some edge-based application and innovation can continue as before. Moreover, enhanced functionality and services can be offered by the overlay service routing layer. The overlay is programmable so that new functionality can be produced by combining a small set of basic defined functions. The service routing layer facilitates the deployment of new services and applications provided either service providers or the third parties, which is the goal of its implementation.

Fig. 3.5
figure 5

The service routing layer’s position in network

Full size image

This platform by CiscoTM pays more attention to the combination of overlay layer with physical network. It is designed as a provider-hosted overlay in order to provide both overlay based applications and the ones IP layer directly supported. The routing layer provides a “topological proximity” function to employ some network layer topology information to the overlay layer. Furthermore, the platform takes the advantage that service provider has more ability to control the properties of network into account, so it also makes use of Diffserv to improve the QoS. The platform implements the relatively complex schemes in the above, and provides a set of simple functions to the applications, which are distributed hash table, proximity, caching, streaming support and events. Based on these functions, block functions can be extended and composed, which could implement a rich set of applications and features.

In this service provider-hosted platform employs services in DHT way, which gives services good scalability. A service descriptor mechanism is used to release services. The descriptors which delegate services are stored and located in the DHT. Services can be replicated on many places. With this scheme a service shows great scalability, and the allocated resources of it can be changed dynamically according to the popularity of the service.

3.3 Conclusion

Recently, many platforms of DHT have been implemented. All of these implementations provide interfaces to other applications or can be combined with other projects. In this chapter, we introduce some of the DHT platforms. Each of them has its unique features and characteristics. These platforms can be classified into two sets. One focuses on supplying some service itself and can be integrated with other applications and projects to supply richer services. Such as Bamboo, CoDeeN and CoralCDN that support caching service, GNUnet for anonymous distributed file sharing, hazelcast for data distribution, DynamoTM for object caching, Cassandra, DynamoTM and SandStoneTM for data storing. They improve the DHT for their features like Bamboo for high churn, GNUnet enhancing the security in communication. These platforms focus on some areas of DHT applications, but can be infrastructures integrated with other projects to extend services. The other set emphasizes on providing interfaces to other applications, such as OpenDHT, JXTA, Open Chord, i3, Overlay Weaver, Service Routing Layer. They do not care about supplying particular application. The goal of them are providing basic functionalities to upper applications. The platforms in former set have more independence that they can provide services without additional components. The platforms in latter set are more general that they focus on the basic functions for applications and services developed on them. The characteristics of each platforms are summarized at Table 3.1.

Table 3.1 Comparison of DHT platforms
Full size table

In the past several years, plenty of platforms of DHT are implemented. Besides the implementation above, there are still many platforms, such as SharkyPy [78] which is an implementation of Kademlia DHT, Chimera [79] which is a light-weight DHT implementation providing similar functionality as Tapestry and Pastry, MaidSafe [80] which is an open source full Kademlia implementation with NAT traversal, FreePastry [81] which is an open source implementation of Pastry, JDHT [82] which is a simple Java based Distributed Hash Table, Khashmir [83] which is a Distributed Hash Table based on Kademila and written in Python, Mace [84] which is a C++ language extension and source-to-source compiler for building distributed systems, Dijjer [85] which is free P2P software that dramatically reduces the bandwidth needed to host large files. AkamaiTM [86, 87] which is a famous Since so many implementations and plenty of researches based on them are exists, it gives a great push to the applications of DHT.