Distributed file sharing system using peer-to-peer technology

This system is referred to as the SERVANT and it is composed of a collection of nodes. Each node is part server and part client (conceptually). The SERVANT distributed system is composed of an unknown number of nodes. A node only knows the IP addresses and port numbers of a small subset of all the nodes. We were required to built a interface where user can interact with the client side of a node via a commandline interface in order to perform various tasks within the SERVANT system. For example, a user can:

- store a file into the SERVANT (not necessarily just on the server side of this particular SERVANT node, i.e., the file gets replicated probabilistically)
- perform various types of searches
- retrieve files based on the result of a search
- delete a file from the SERVANT and destroy all (or most) copies of it

What we did?

We supported the above mentioned operations in a peer-to-peer system by implementing the following messages:

- join: The join message should be flooded to the whole network (up to a specified TTL). In response to a join message, a node computes its distance (4-byte value) to the requesting node and includes this distance in a join response message.

- hello: The hello message is used to introduce a node (its hostname and its port number) to its immediate neighbor so that the neighbor can talk back to this node.

- keepalive: The keepalive message is used by a node to inform its neighbor that it is still alive.

- notify: The notify message is used by a node to inform its neighbor that it is about to close the connection.

- check: The check message is used by a node to see if it is still connected to the core of the SERVANT network.

- store: The store message should be probabilistically flooded to the whole network (up to a specified TTL). It takes a file and stores it in the server side of the node to which the user is connected.

- search: The search can be based on keywords, the precise spelling of a file name, or the precise SHA1 hash of a file.

- get: The get message is to be flooded to the whole network (up to a specified TTL) to retrieve a file associated with a specific FileID. The response to a get message contains the file matching with the requested UOID and all its metadata.

- status: The status message is to be flooded to the whole network (up to a specified TTL). An argument is passed to this message specifying what type of status needs to be reported.

- delete: It is used to delete copies of a specified file from both permanent storage and the cache. A digital signature of the file specification is sent along the message to authenticate the originating node of the message.