CS 677 Operating Systems

Spring 2002

Programming Assignment 1: A simple Napster style peer to peer file sharing system

Due: Feb 28th - in class

(for off-campus students - 14 days after viewing Lecture 5)

• You may work in groups of two for this lab assignment.
• Here are some useful references for this project.
• Answers to frequently asked questions about this assignment are here. Please check this page frequently as we plan to post clarifications on a continual basis.

1 The problem

This project has two purposes: first to get you familiarize with sockets/RPCs/RMIs, processes, threads; second to learn the design and internals of a Napster-style peer-to-peer (P2P) file sharing system.

You can be creative with this project. You are free to use any programming languages (C, C++, Java, etc) and any abstractions such as sockets, RPCs, RMIs, threads, events, etc. that might be needed.

If you are not familiar with Napster, the following links provide some background about the technology. 

1. The Technology Behind Napster

2. Another introduction to P2P file-sharing at http://www.limewire.com/index.jsp/p2p

In this project, you need to design a simple P2P system that has two components:

1. A central indexing server. This server indexes the contents of all of the peers that register with it. It also provides search facility to peers. In our simple version, you don't need to implement sophisticated searching algorithms; an exact match will be fine. Minimally, the server should provide the following interface to the peer clients:

   • register (peer id, file name, ...) -- invoked by a peer to register all its files with the indexing server. The server then builds the index for the peer. Other sophisticated algorithms such as automatic indexing are not required, but feel free to do whatever is reasonable. You may provide optional information to the server to make it more 'real', such as the clients bandwidth, etc.

   • lookup (file name) --  this procedure should search the index and return all the matching peers to the requestor.

2. A peer. A peer is both a client and a server.
   As a client, the user specifies a file name with the indexing server using "lookup". The indexing server returns a list of all other peers that hold the file. The user can pick one such peer and the client then connects to this peer and downloads the file.
   As a server, the peer waits for requests from other peers and sends the requested file when receiving a request.
   Minimally, the peer server should provide the following interface to the peer client:

   • download (file name) -- invoked by a peer to download a file from another peer.

Other requirements:

• Both the indexing server and a peer server should be able to accept multiple client requests at the same time. This could be easily done using threads. Be aware of the thread synchronizing issues to avoid inconsistency or deadlock in your system.
• No GUIs are required. Simple command line interfaces are fine.

2 Evaluation and Measurement

Deploy at least 3 peers and 1 indexing server. They can be setup on the same machine (different directories) or different machines. Each peer has in its shared directory (all of which are indexed at the indexing server) at least 10 text files of varying sizes (for example 1k, 2k, ..., 10k). Make sure some files are replicated at more than one peer sites (so your query will give you multiple results to select).

Do a simple experiment study to evaluate the behavior of your system. Compute the average response time per client search request by measuring the response time seen by a client for , say, 1000 sequential requests. Also, measure the response times when multiple clients are concurrently making requests to the indexing server, for instance, you can vary the number of concurrent clients (N) and observe how the average response time changes, make necessary plots to support your conclusions.

3 What you will submit

When you have finished implementing the complete assignment as described above, you will submit your solution in the form of printouts.

Each program must work correctly and be documented. You should hand in:

1. A copy of the output generated by running your program. When it downloads a file, have your program print a message "display file 'foo'" (don't print the actual file contents if they are large). When a peer issues a query (lookup) to the indexing server, having your program print the returned results in a nicely formatted manner.
2. A seperate (typed) document of approximately two pages describing the overall program design, a description of "how it works", and design tradeoffs considered and made. Also describe possible improvements and extensions to your program (and sketch how they might be made).
3. A program listing containing in-line documentation.
4. A seperate description of the tests you ran on your program to convince yourself that it is indeed correct. Also describe any cases for which your program is known not to work correctly.
5. Performance results.

Let us not waste a lot of trees. So, if any of the above turn out to be large, just save the relevant information in a file, leave it on your EDLAB account and submit the name of the file.

4 Grading policy for all programming assignments

Grading:

• Program Listing
  • works correctly ------------- 50%
  • in-line documentation -------- 15%
• Design Document
  • quality of design ------------ 15%
  • understandability of doc ------- 10%
• Thoroughness of test cases ---------- 10%

Grades for late programs will be lowered 12 points per day late.