CS 15-441 Fall 2007 Project 3

The final deadline for Project 3 is Tuesday, 12/4 at 11:59pm

Note: Please chmod +x each of the scripts before running them, else you'll get a "permission denied" error.

BitFlood Usage Example

1. Start the tracker on one of your servers. To do this, use the bf_runtracker.py script. The tracker script will take in the port number to listen to as a parameter. Keep the tracker running, as no clients can work without it.

   % ./bf_runtracker.py 18801
   	

2. Secondly, convert the file you are trying to share into a flood file. The script to do this is the bf_makeflood.py script. This script takes as parameters the file you are trying to convert, and the tracker you wish to use to distribute peer information, in hostname:port format.

% ./bf_makeflood.py movie.avi unix38.andrew.cmu.edu:18801
	

3. Distribute your .flood file (outputted by the script) to your peers. You can do this by manually copying the file to your peers, or by placing it on a central server for download.
4. Run your BitFlood implementation on the .flood file. Once the file has finished downloading, your binary should output "GOT <filename>"; to STDOUT.

% ./bitflood movie.avi.flood -n 1
GOT movie.avi
	  

5. Even after the file finishes downloading, your client will continue to share (seed) the file you are downloading. This should continue until the client is explictly killed by the user.

Resources

• Project 3 handout: project3.pdf
• Files for this project are in project3.tar.gz
• Provided BitFlood scripts can be found by running:

  % svn co https://moo.cmcl.cs.cmu.edu/441/svn/project3/bitflood
  

  You should periodically update the scripts using "svn up", as we may be updating the scripts as certain functionality may be added.

Extra Credit

Running the network simulator

• Make sure that you are using the latest networksim.py. Ensure this by checking out the latest version of the scripts.
• Set environment variable SPIFFY_ROUTING to 127.0.0.1:portnum, where portnum is a port somewhere in the valid range for your team.
• Run python bf_networksim.py topo.map trackerhost:trackerport, where trackeraddr:trackerport is replaced with the location of your running tracker.
• Enable spiffy routing in your client code.
• If you wish to see when packets are being dropped, enable the --verbose flag when running the network simulator.

Checkpoints

• 10/31: Checkpoint 1
  Running the checkpoint script:
  1. Copy your bitflood binary into the checkpoint directory.
  2. Run "python p3checkpoint1.py <team-num>"
  3. The checkpoint will output if you passed or failed, and what errors may have occurred.
  The checkpoint will do a few very simple things. First, it starts a tracker, registers itself and your bitflood client onto the tracker, and then sends your client a WHOHAS request. If the checkpoint script receives at least one correctly formed WHOHAS packet and one correctly formed IHAVE packet, your script passes the checkpoint.


• 11/06: Checkpoint 2
  
• 11/08: Alternative Checkpoint
  Running the checkpoint script:
  1. Copy your bitflood binary into the checkpoint directory.
  2. Run "python p3checkpoint2.py <team-num>"
  3. The checkpoint will output if you passed or failed, and what errors may have occurred.
  This checkpoint will test file transfers. The script will spawn two versions of your client, each with an incomplete copy of a testfile, and verify that both are able to construct a complete copy of the original file. There are no time bounds on this checkpoint, so as long as it completes, you pass the checkpoint. As stated in the handout, you should have stop-and-wait implemented by this point.
  
  Update: If your program has problems passing the checkpoint, you may use the alternate checkpoint. If your program passes either checkpoint, then you pass the checkpoint. The alternate checkpoint simply spawns two of your clients and diffs the testfiles until they match the reference. The script follows the same format as the previous python script -- copy it over the p3checkpoint2.py in the checkpoint directory and run it the same as usual.


• 11/17: Checkpoint 3
  Running the checkpoint script:
  1. Copy your bitflood binary into the checkpoint directory.
  2. Run "python p3checkpoint3.py <team-num>"
  3. The checkpoint will output if you passed or failed, and what errors may have occurred.
  This checkpoint will do the same thing as the previous checkpoint, only you will be attempting to send to a broken client. This client has a sliding window of 8 packets, but will only ACK packets that are divisible by 8 -- this means that stop-and-wait will not be able to send to this client.
  
  Included is a non-broken reference client that will pass the checkpoint. Use this client to make sure that your implementation of the BitFlood protocol is correct. Additional debugging output is included in the reference implementation.


• 11/26: Checkpoint 4
  Running the checkpoint script:
  1. Copy your bitflood binary into the checkpoint directory.
  2. Run "python p3checkpoint4.py <team-num>"
  3. The checkpoint will output if you passed or failed, and what errors may have occurred.
  This checkpoint will simulate packet loss in order to cause your window to resize. 100 packets into the first transfer, the broken client will stop accepting packets for one second, after which it will behave normally.
  
  After the transfer completes, the checkpoint will check your window_size.txt file and verify three things:
  1. The window size has gone down at some point.
  2. The window size was reduced to 1 after the loss.
  3. The window grows after being reduced to 1.