A Peer to Peer FileSharing System

##Peer-to-Peer with Centralized Index (P2P-CI) System for Downloading RFCs Internet protocol standards are defined in documents called
“Requests for Comments” (RFCs). RFCs are available for download from the IETF web site (http://www.ietf.org/). 
Rather than using this centralized server for downloading RFCs, you will build a P2P-CI system in which peers who wish to 
download an RFC that they do not have in their hard drive, may download it from another active peer who does. 
All communication among peers or between a peer and the server will take place over TCP. 
Specifically, the P2P-CI system will operate as follows; additional details on each component of the system will be provided shortly. 
• There is a centralized server, running on a well-known host and listening on a well-known port, which keeps information about the 
active peers and maintains an index of the RFCs available at each active peer. • When a peer decides to join the P2P-CI system, 
it opens a connection to the server to register itself and provide information about the RFCs that it makes available to other peers.
This connection remains open as long as the peer remains active; the peer closes the connection when it leaves the system
(becomes inactive). • Since the server may have connections open to multiple peers simultaneously, it spawns a new process to handle 
the communication to each new peer. • When a peer wishes to download a specific RFC, it provides the RFC number to the server over 
the open connection, and in response the server provides the peer with a list of other peers who have the RFC; if no such active peer
exists, an appropriate message is transmitted to the requesting peer. Additionally, each peer may at any point query the server to obtain
the whole index of RFCs available at all other active peers. • Each peer runs a upload server process that listens on a port specific to
the peer ; in other words, this port is not known in advance to any of the peers. When a peer A needs to download an RFC from a peer B,
it opens a connection to the upload port of peer B, provides the RFC number to B, and B responds by sending the (text) file containing 
the RFC to A over the same connection; once the file transmission is completed, the connection is closed.

##The Server 
The server waits for connections from the peers on the well-known port 7734. The server maintains two data structures: a list with 
information about the currently active peers and the index of RFCs available at each peer. For simplicity, you will implement both
these structures as linked lists; while such an implementation is obviously not scalable to very large number of peers and/or RFCs,
it will do for this project. Each item of the linked list of peers contains two elements:
the hostname of the peer (of type string), and the port number (of type integer) to which the upload server of this peer is listening. 

The Application Layer Protocol: P2P 
The protocol used to download files among peers is a simplified version of the HTTP protocol we discussed in class. Suppose that peer A 
wishes to download RFC 1234 from peer B running at host somehost.csc.ncsu.edu. Then, A sends to B a request message formatted as follows, 
where denotes “space,” denotes “carriage return,” and denotes “line feed.” method RFC number version header field name value header field
name value There is only one method defined,GET,and only two header fields,Host (the host name of the peer from which the RFC is requested) and 
OS (theoperatingsystemoftherequestinghost).For instance,a typical request message would look like this: 
GET RFC 1234 P2P-CI/1.0 Host: somehost.csc.ncsu.edu OS: Mac OS 10.4.1

The response message is formatted as follows: version status code phrase header field name value header field name value ... data 
Four status codes and corresponding phrases are defined: 
• 200OK • 400 Bad Request • 404 Not Found • 505 P2P-CI Version Not Supported 
Five header fields are defined : Date (the date the response was sent),OS (operating system of responding host), 
Last-Modified (the date/time the file was last modified),Content-Length (the length of the file in bytes), and 
Content-Type (always text/plain for this project).
A typical response message looks like this: 
P2P-CI/1.0 200 OK
Date: Wed, 12 Feb 2009 15:12:05 GMT
OS: Mac OS 10.2.1
Last-Modified: Thu, 21 Jan 2001 9:23:46 GMT
Content-Length: 12345 
Content-Type: text/text (data data data ...)

Application Layer Protocol: P2S 
The protocol used between a peer and the server is also a request-response protocol, where requests are initiated by peers. 
The format of a request message is as follows: method RFC number version header field name value header field name value 
There are three methods: 
• ADD, to add a locally available RFC to the server’s index, 
• LOOKUP, to find peers that have the specified RFC, and 
• LIST, to request the whole index of RFCs from the server. 
Also, three header fields are defined: 
• Host: the hostname of the host sending the request, 
• Port: the port to which the upload server of the host is attached,
• Title: the title of the RFC For instance,peerthishost.csc.ncsu.edu who has two RFCs,RFC123 and RFC2345 locally available and
whose upload port is 5678 would first transmit the following two requests to the server:
ADD RFC 123 P2P-CI/1.0 Host: thishost.csc.ncsu.edu Port: 5678 Title: A Proferred Official ICP
ADD RFC 2345 P2P-CI/1.0 Host: thishost.csc.ncsu.edu Port: 5678 Title: Domain Names and Company Name Retrieval 
Once a peer downloads a new RFC from another peer,it may transmit a ADD request to add a new record into the server’s index. 

A lookup request from this host would like this: LOOKUP RFC 3457 P2P-CI/1.0 Host: thishost.csc.ncsu.edu Port: 5678 Title: Requirements for IPsec Remote Access Scenarios 
while a list request would be: LIST ALL P2P-CI/1.0 Host: thishost.csc.ncsu.edu Port: 5678 
The response message from the server is formatted as follows, where the status code and corresponding phrase are the same as defined above. 
version status code phrase RFC number RFC title hostname upload port number RFC number RFC title hostname upload port number .
In other words, the data part of the response lists one RFC per line, along with the information about the host containing the RFC.
The response to an ADD simply echoes back the information provided by the host:
P2P-CI/1.0 200 OK RFC 123 A Proferred Official ICP thishost.csc.ncsu.edu 5678 
The response to a LOOKUP may contain multiple lines for a given RFC,each line containing information about a different peer having the RFC.
Finally,the response to a LIST lists all the records in the server’s database,one per line. 
If the request contains an error or the requested RFC is not found in the index, an appropriate status code and phrase is returned, and the data part of the response is empty.
Note: the peer should print the responses it receives from the server to the standard output in the same format.