CSS 432
Final Project: P2P File Sharing
Professor: Brent Lagesse
Due date: See the syllabus

1. Purpose

This is a project to implement a P2P file sharing client.

2. P2P

The project is to design an unstructured, decentralized P2P client similar to the original Gnutella. You must implement the protocols described in this section. The P2P client will follow two protocols. The first protocol is the bootstrap protocol where the client will connect to initially determine where a small subset of peers is located and register itself with the bootstrap node. The second protocol defines the communications between individual peers.
When the program first starts, the peer connects to a bootstrap node and registers with the bootstrap node. Then the peer can request a list of peers from the bootstrap node. Finally, the peer must unregister with the bootstrap node before shutting down. Occasionally the peer will need to send a keepalive message to the bootstrap node so that it does not get evicted from the list of potential peers.

Bootstrap Protocol

Register Msg Format -> 0:ListeningPort
Request Peer List Msg Format -> 1:MaxNumberOfPeersRequested
Response Peer List Msg Format -> IPAddress1,PortNumber1\nIPAddress2,PortNumber2\n (etc.)
Unregister Msg Format -> 2:ListeningPort
Keepalive Msg Format -> 3:ListeningPort


After the peer has a list of peers to work with, it can now request peers to list their files, request a specific file, or search for a file. Likewise, the peer must also listen so that can respond to the aforementioned requests.

Peer Protocol

Download Msg Format -> 4:Filename
Download Response Msg Format -> FILE
List Files Msg Format -> 5:
List Files Response Msg Format ->Filename1\nFilename2\n (etc.)
Search Msg Format -> 6:ID:File String:RequestingIP:RequestingPort:TTL
Search Response Msg Format -> 7:ID:RespondingIP:RespondingPort:Filename

Other than directly responding to message, part of the protocol is that if a file is requested of it, a peer should forward that message to all its neighbors (other than the one it received the search from). If a peer has seen a search message before, it should drop the message and not forward it. Likewise, if the TTL has expired, drop the request. Otherwise decrement the TTL by 1 and forward it. If a peer has a file that matches the search, the peer should contact the original sender saying where to download the file from.
The ID in the search is a unique identifier for each request so that the requester can keep track of which requests have been answered.

4. Statement of Work

Write the code for a peer to contact the bootstrap server, register, and request a listing of peers. If the peer has not talked to the bootstrap server with 10 minutes, it should send a keepalive message to the bootstrap server. When the peer leaves the system, it should send an unregister message to the bootstrap server. Write the code for a peer that receives and sends messages. Your peer should automatically listen to any messages sent to it and respond to them appropriately. Your peer should have a user interface (command line is fine) that allows a user to search for files, list files from a peer, and download files from a peer.

Your peer should also produce a log of activities that occur. The peer should log every request it either makes or receives along with a timestamp. You will use this information for your discussion.

Run at least 10 instantiations of your peer (for simplicity you can spawn a large number of peers programmatically by using a script or fork() then spawn a single peer that you run all of your commands through. Just makes sure that these peers report having different files available). Each peer should have at least 3 unique files. Make 5 searches, 5 file listing requests, and download 5 files.

5. What to Turn in

Criteria Percentage
Documentation of your peer implementation in one page. Make sure to include information and justification of your design decisions. 3pts(15%)
Source code: that adheres good function modularization, coding style, and an appropriate amount of comments. 7pts(35%)
Execution output such as a snapshot of your display/windows. Type import -window root X.jpeg; lpr -Puw1-320-p1 X.jpeg on a uw1-320 Linux machine. Or, submit contents of standard output that has been redirected to a file. 2pts(10%)
Performance Evaluation: Provide the following information: (1) How many hops did an average search take to find the file, (2) How much time did an average search take, (3) What was the difference in time and hops between the fastest and the slowest search you performed 4pts(20%)
Discussions: should be given regarding possible optimizations that would make searches return results more quickly. You should discuss the weaknesses in this protocol. You should also discuss why our P2P architecture is or is not scalable to millions of nodes. 4pts(20%)
Total 20pts(100%)