Group Members: Shane Mallia & Alex McAusland Project Supervisor: John Crawford. Dropped multiple code branches for different platforms Dropped use of UDP as a IPC mechanism Refactoring involved removal of old memory management strategy Our DHT architecture is based upon a modular design consisting of several layers. The idea was to separate the implementation of each layer, dividing them by using clearly defined interfaces of functionality. This was driven by a requirement of cross platform compatibility. Some code is necessarily platform specific, and we wished to isolate it to simplify a port at a later date. The networking layer has been restricted as the only layer that has platform dependent code, as all other layers only make use of the standard C++ library. A demonstration Windows networking layer will be released with the API. An application uses the API much like a conventional Hash Table for familiarity and ease of integration, with some additional functionality for initialisation, given the distributed nature of the DHT. IPC between processes on a single machine Single Hash Table process Multiple user processes Removed the limitations of story 1 Accomplished by altering our IPC mechanism to use TCP IPC between processes on different machines Multiple Clients and a single storage Hash Table Distributed storage across two machines Hash Table key space partitioned between participants Shared storage burden With the growth in demand for services much load is placed on centralised infrastructure. It is the goal of this project to provide a platform for developers to create distributed services to share this load. A Distributed Hash Table provides the storage and retrieval of data based on some sequence of key data. However, it is distributed in that responsibility for this storage and retrieval is shared amongst a series of one or more participating machines or ‘nodes’. We chose Extreme Programming (XP) as a methodology. An agile approach seemed appropriate for such a small group tackling a not well known problem with requirements subject to change. Core principles in the management of our project have been small frequent releases (‘stories’) incorporating new functionality and feedback, rigorous unit testing and practises such as mandatory code reviews and peer programming. Process 1 DHT Logic Process 2 (test rig) DHT Logic in a central host mode IPC Layer (using UDP) Process 1 DHT Logic Process 2 (test rig) DHT Logic in a central host mode IPC Layer (using TCP) Process 3 (test rig) DHT Logic in a central host mode Networking Layer (using TCP) Process 1 DHT Logic Networking Layer (using TCP) Process 2 DHT Logic Process 1 DHT Logic in a distributed mode Process 2 (test rig) DHT Logic in a distributed mode Networking Layer (using TCP) Process 1 DHT Logic Networking Layer (using TCP) Process 2 DHT Logic Networking Layer (using TCP) Process 3 DHT Logic Networking Layer (using TCP) Process 4 DHT Logic Distributed storage amongst an arbitrary number of machines Logarithmic lookup times Redundancy in data storage