A peer-to-peer (p2p) file sharing service (for example, Napster) maintains a database of available files and their current locations. A file sharing client program queries this database to locate files the user is interested in downloading.
In this project, you will implement a p2p file sharing application. The application queries a central directory service to find the location(s) of a file which the user wishes to download. It then transfers the file directly from the peer which has the file - i.e. there is no intermediate server involved on the data path. We will use a custom directory server for the file lookup process. The application interacts with this directory server using UDP -- queries to the server and responses from the server are contained in UDP packets and not TCP. Your goal in Phase 1 is to design the message formats and protocol to be used for the application - directory server interaction.
In project 2, you implemented the text-based HTTP protocol. In this project, you should design a protocol with messages in binary format. IP packets and DNS packets are examples of binary message formats. In your design report, the binary packet formats must be described in a table format. For example, http://www.networksorcery.com/enp/protocol/ip.htm describes the IP header in a table format.
You will NOT be implementing the protocol and message formats you design. Please refer to the "What happens in Phase 2?" section for more details.
You should submit a design report which contains the following information:
The report must not be longer than 5 pages (single or double column, 12 point font) . Only doc, pdf, ps, html and txt formats will be accepted. The report can be structured in any way you deem fit. You will receive feedback and grades for your design within 2-3 days after the Phase 1 submission deadline.
TCP is the workhorse of today's Internet - the majority of today's Internet traffic is TCP. In projects 1 and 2, you used TCP to reliably transfer data -- between EchoClient and EchoServer in project 1 and between KeywordHunter and the web server in project 2. TCP provides a reliable in-order byte stream abstraction. It employs flow control to prevent fast senders from overwhelming slow receivers. Congestion control mechanisms in TCP react to network congestion by lowering the sending rate.
In this project, you will design and implement your own reliable transport protocol on top of UDP. In phase 1, you will design this protocol. Your protocol should have the following features:
Reliable Data Transfer: The protocol should reliably transfer data from a sender to the receiver. The UDP packets containing your data may be lost, re-ordered, replicated or delayed inside the network.
Efficient/Quick Data Transfer: The protocol should transfer data quickly by using a Sliding Window approach. Stop-and-Wait is too slow.
Congestion Control: Packet drop is often a signal of congestion. The protocol should decrease or increase its sending rate in an AIMD style depending on the state of network congestion.
You do NOT have to implement all the features of TCP. You may borrow mechanisms from TCP to implement the features described above. TCP is a symmetric protocol - a single TCP connection can simultaneously transfer data in both directions. Your protocol should transfer data in a single direction only - from sender to receiver. The protocol (and the headers associated with it) should be optimized for uni-directional data transfer.
You are NOT required to submit a design report for your transport protocol. You may submit a transport protocol design report by the Phase 1 deadline solely for the purpose of feedback - it will not be graded. All the points for Phase 1 are associated with the directory lookup design report.
In phase 2, all teams will implement the client part of a directory lookup service. The directory server will be run by the EE122 staff. The protocol and message formats understood by the server will be announced immediately after Phase 1. You need to implement only the client part of the directory service- send appropriate request messages to the EE122 directory server and parse the responses received. Your file sharing application will use this client part for locating the files the user wishes to download.
The protocol and message formats for the directory lookup service to be implemented in Phase 2 will not be the same as what you designed in Phase 1. You may have missed out some necessary messages or message fields in your design. It could also happen that you design a very comprehensive directory lookup protocol that will take too much time to implement. We are saving you time by requiring you to implement the simpler protocol and message format used by the EE122 directory server :-).
You will implement the reliable transport protocol you designed in Phase 1 and use it to transfer files you locate using the directory service.
Phase 1 is worth 20% of the project 3 grade. All the points in phase 1 are associated with the directory lookup service design report. The transport protocol design report is not mandatory and will not be graded.
Why are there no slip days for Phase 1?
Answer: Phase 2 depends on message format specifications that can be released only after all Phase 1 submissions have been turned in.
In order to avoid inconveniencing teams that submit their reports on time, there will be no slip days for phase 1.