CSE 40771 - Distributed Systems - Spring 2026
In the last assignment we nearly realized full P2P communication. The missing link was the potential for a fully-connected group of peers. Instead, your implementation imposed some protocol which prevented existing peers from requesting data from newer peers.
The first objective for this final assignment is to enable communication between any two peers. When an existing peer receives a request from a new peer, it should be possible for a request to be made in the other directions.
Once the peers are now fully connected you will have a basic P2P file replication system, with a lot of room for improvement in the download policy and fault tolerance.
Existing peers currently receive a get_description message from new peers. After responding, the existing peer should also send a get_description back. When two peers now have the potential to make concurrent requests between eachother, they will likely invite the potential for deadlock which will have to be solved.
Instead of downloading all of the data from a single peer, try to balance the sharing effort across all of the peers in the system. Consider the amount of available peers and the amount of individual files in the table. Only request a few files from a given peer. Then connect to another before continuing.
Your peers should be working to keep the system alive in case any peer leaves and makes it’s data unavailable. If each peer attempts to collect the data by the same ordering of keys in the hash table, they will all be replicating the same data, leaving other files vulnerable to loss. At a minimum the peers should randomly request files from the hash table in order to balance the replication.
Evaluate your system in the presence of multiple peers as follows:
Peer on one of the student machines. This will register it with the name service.python Peer.py project_name peer_name
Add a time delay to slow down the peer between downloads. Insert enough files into the peer’s hash table so that it will take an observable time for another peer to complete downloading the data.
On a different student machine start two more instances of Peer simultaneously with their own data directories:
python Peer.py project_name peer_name_1 & \
python Peer.py project_name peer_name_2
Capture the output of all of the peers by appending to a file. When a peer gets a file, or it serves one to another peer it should print a message describing the event.
The output should show a mix of peers performing lookups and serving files to other peers. Have enough information in the output to piece together which peers are talking to eachother. Capture and highlight at least one instance of the two newest peers communicating with eachother.
Perform the same test as before but in several stages. Start 1 peer, then 2, then 4. For a total of 7 peers all in the system at one time.
Create a graph/diagram of the system and what occurred when it was running. Illustrate the connections between peers and the direction of the connection.
Discuss the graph in your report. Did you achieve a fully connected system? Did some peers never communicate? How did your file selection policy influence this?
Please review the general instructions for submitting assignments.
Turn in all of your source code, along with a lab report titled REPORT that describes the following in detail: