1. 1 Open DHT: A Public DHT Service for Developers of Distributed Applications University of California, Irvine Presented By : Ala Khalifeh akhalife@uci.edu Estimated Time:25 Minutes (Note: Presented)

2. 2 Open DHT: A Public DHT: Service for Developers of Distributed Applications Who did the survey (Done by : Ala’ Khalifeh- akhalife@uci.edu) Overview  Website/URLs/references http://www.intel.com/research/print/overview_opendht.pdf The Open DB website: http://www.opendht.org OpenDHT: A Public DHT Service and Its Uses Sean Rhea, Brighten Godfrey, Brad Karp, John Kubiatowicz, Sylvia Ratnasamy, Scott Shenker, Ion Stoica, and Harlan Yu UC Berkeley and Intel Research, SIGCOMM’05, August 21–26, 2005.  Application/Issues A framework proposed by Intel to enable researchers to develop a new distributed applications.

3. 3 Generic system description Assumption  A DHT is a variation on a hash table—a classic data structure used to efficiently store and retrieve data.  In a hash table, data is stored as key-value pairs (a key is a label or description of data, such as “John’s age,” and a value is the data associated with the key—say, “33.”).

4. 4 Assumption (cont’d) A distributed hash table (DHT) spreads this data structure across thousands or even millions of computers connected to the Internet. When a user queries the system for a given key-value pair, the system retrieves the data from one of the computers where it’s stored and returns the data to the user. The advantage is that an application built atop a DHT seamlessly inherits :  scaling, robustness and self-organizing properties of its underlying DHT.

5. 5 System Architecture and Deployment (Open DHT: A Public, Shared DHT infrastructure)  Given this promising research output, in 2004 Intel launched the Open DHT project.  The project focuses on easing the deployment of distributed applications that use DHTs  Open DHT researchers proposed building a publicly accessible shared DHT service.

6. 6 Before Open DHT After Infrastructures Problem To deploy a DHT, a developer must gain access to a large set of distributed machines to host the DHT. This is a difficult prospect for those who don’t have access to infrastructures PlanetLab PlanetLab, a testbed for deploying planetary-scale services that is open only to computer scientists in academia and industry. Open DHT runs on PlanetLab’s hosts, and thus extends PlanetLab’s reach beyond the research community to a broader community of developers.

7. 7 Open DHT Deployment Model Deployment Rather than require that each developer deploy a DHT for every application. The Open DHT project proposes an alternate deployment model. Under this model, a single DHT (namely, Open DHT) is shared across multiple applications, thus amortizing the cost of deployment.

8. 8  Deployment (Open DHT Deployment Model) (Continued) Requirements  Simple, Flexible, Secure The Open DHT service offers a simple put and get interface. Any Internet-connected computer can store or put key-value pairs in Open DHT, and any Internet- connected computer can retrieve or get the value stored under a particular key In contrast to the typical “build your own” DHT model, clients of Open DHT do not need to run a DHT node in order to use the service. Instead, they can issue put and get Operations to any Open DHT node, which processes the operations on their behalf.

9. 9  Deployment (Open DHT Deployment Model) (Continued) By using Open DHT as a highly available naming and storage service, developers can ignore the complexities of deploying and maintaining a DHT and focus instead on the development of the application itself.

10. 10 System Architecture (cont’d)

11. 11 System Architecture (cont’d) Each PlanetLab node is a Linux host that runs the open-source Bamboo DHT implementation. Each node in the Open DHT deployment holds a portion of the DHT's total key-value store on its local disk. It answers put and get requests for that portion of the DHT's total key-value store, and routes requests for the remaining key-value entries to other DHT member nodes.

12. 12 System Architecture (cont’d) Each node also serves as a gateway into the DHT for clients. An Open DHT client communicates with the DHT through the gateway of its choice using Sun RPC or XML RPC over TCP. Because of this, the service is easy to access from virtually every programming language and from behind almost all NATs.

13. 13 Sample Applications FOOD (FreeDB Over Open DHT) A sample application that could improve the performance and availability of freedb.org, The Freedb project is an audio CD song title indexing system used to label the tracks on MP3 files, the client queries the database. As a result, the system displays the artist information, CD-title, tracklist and some additional infos. Today, FreeDB is a free service run by a small number of volunteers. The service indexes titles for over a million CDs and serves over four million read requests per week across ten widely dispersed “mirrors.” Mirroring is labor-intensive and limited in flexibility

14. 14 Sample Applications Implementing FreeDB Over Open DHT was a trivial undertaking – FreeDOD is implemented in just 84 lines of Perl. Moreover, measurements show that FreeDOD outperforms the existing FreeDB service in terms of data availability and latency. In addition to FOOD, Open DHT researchers have implemented simple prototypes of an instant messaging application (in 123 lines of C++), a DHT-based file-system (531 lines of Java). And a multicast service (781 lines of Java) which allows a user to efficiently transmit content to large numbers of receivers,

15. 15 Sample Applications

16. 16 Categorization-1 Yes Download Yes Centralized Hybrid YesDistributedMeshDecentralized SearchStorageTopologyInitialization Functional Criteria The degree of decentralization

17. 17 Performance Evaluation Simulation  Efficiency – results Measurement Setup a May 1, 2004 snapshots were stored of the FreeDB database containing a total of 1.3 million discids in OpenDHT. To compare the availability of data and the latency of queries in FreeDB and FOOD, both systems were queried for a random CD every 5 seconds. The FreeDB measurements span October 2–13, 2004, and The FOOD measurements span October 5–13.

18. 18 Performance Evaluation  Availability and Latency During the measurement interval, FOOD offered availability superior to that of FreeDB. Only one request out of 27,255 requests to FOOD failed, where each request was tried exactly once, with a one-hour timeout. This fraction represents a 99.99% success rate, as compared with a 99.9% success rate for the most reliable FreeDB mirror, and 98.8% for the least reliable one

19. 19 Performance Evaluation  Availability and Latency(cont’d) Comparing the full legacy version of FreeDB against FOOD, we observe that over 70% of queries complete with lower latency on FOOD than on FreeDB, and that for the next longest 8% of queries, FOOD and FreeDB offer comparable response time.  For the next 20% of queries, FOOD has less than a factor of two longer latency than FreeDB. Only for the slowest 2% of queries does FOOD offer significantly greater latency than FreeDB.

20. 20  Security Authentication While OpenDHT does not currently support client authenticity, essentially no requests for such authentication from users. However we believe this apparent lack of concern for security is most likely due to these applications being themselves in the relatively early stages of deployment.