BitTorrent Assignment 5: Seeding a File and Implementing Rate-Limiting - Prof. Neil Spring, Assignments of Computer Systems Networking and Telecommunications

The requirements for programming assignment 5 in cmsc 417, where students are tasked with seeding a file through bittorrent and implementing rate-limiting. Various aspects of the assignment, such as setting the peer id, checking file integrity, interacting with the tracker, and handling connections. Students are encouraged to use the bittorrent specification for guidance.

Typology: Assignments

Pre 2010

Uploaded on 02/13/2009

koofers-user-hb8-1
koofers-user-hb8-1 🇺🇸

4

(2)

10 documents

1 / 2

Toggle sidebar

This page cannot be seen from the preview

Don't miss anything!

bg1
cmsc 417 programming assignment #5: BitTorrent part 2
April 15, 2008
Goal: Seed a file through BitTorrent; Rate-limit.
1 Deadline
DUE: Friday, April 25. The late deadline will be Monday, April 29; you have only one late deadline to play
with.
2 Partner!
You MAY work with one partner for this assignment. BOTH partner students must turn in a working
implementation by the deadline. (this will simplify accounting.) Please include a text file “partners” in each
turnin listing both names.
3 Overview
Alter part 1 for the following:
Use the filename specified in the torrent; don’t use “downloaded” anymore. UNLESS: the filename
starts with a / or includes ’..’ (the literal, not the regex). I don’t want you to accidentally overwrite an
important file because some meanie gives you an evil torrent file. Such torrents should be discarded.
(I won’t test this; but if you corrupt a file that matters, it’s not my fault.)
Set your peer id to UM417xxww-yyy-zz, where xx and ww are your assigned account numbers, zz is a
little randomness, and yyy is your short message to share. Set ww to 00 if without help.
Check (using SHA1) any file already in place to ensure that the pieces of the file are legitimate; build
the bitmask for what you already have (which may be physically realized in a cached message, an array
of bits, or an array of pieces with flags, etc.) Pretty soon, you’ll have to resume a partial download,
so, set the bits for pieces you have based on reading the file.
Tell the tracker you have the whole file (when you do; we’ll start with the file in place for this assign-
ment). I’m pretty sure this is “left=0”. (Possibly also numwant=0.) There’s a right way to inform
the tracker of incremental progress; feel free (optional feature) to use that instead of coding the special
cases at the beginning of a download (last assignment) and at the end (this one).
Support arbitrarily many connections (though you could start dropping them if there are 50). Use
select! (or the poll function.)
Listen on a port; accept connections on that port; receive, check, and reply to handshake messages.
Provide non-empty bitmask messages of the correct length. Don’t use the uTorrent (“have” message
only) scheme.
1
pf2

Partial preview of the text

Download BitTorrent Assignment 5: Seeding a File and Implementing Rate-Limiting - Prof. Neil Spring and more Assignments Computer Systems Networking and Telecommunications in PDF only on Docsity!

cmsc 417 programming assignment #5: BitTorrent part 2

April 15, 2008

Goal: Seed a file through BitTorrent; Rate-limit.

1 Deadline

DUE: Friday, April 25. The late deadline will be Monday, April 29; you have only one late deadline to play with.

2 Partner!

You MAY work with one partner for this assignment. BOTH partner students must turn in a working implementation by the deadline. (this will simplify accounting.) Please include a text file “partners” in each turnin listing both names.

3 Overview

Alter part 1 for the following:

  • Use the filename specified in the torrent; don’t use “downloaded” anymore. UNLESS: the filename starts with a / or includes ’..’ (the literal, not the regex). I don’t want you to accidentally overwrite an important file because some meanie gives you an evil torrent file. Such torrents should be discarded. (I won’t test this; but if you corrupt a file that matters, it’s not my fault.)
  • Set your peer id to UM417xxww-yyy-zz, where xx and ww are your assigned account numbers, zz is a little randomness, and yyy is your short message to share. Set ww to 00 if without help.
  • Check (using SHA1) any file already in place to ensure that the pieces of the file are legitimate; build the bitmask for what you already have (which may be physically realized in a cached message, an array of bits, or an array of pieces with flags, etc.) Pretty soon, you’ll have to resume a partial download, so, set the bits for pieces you have based on reading the file.
  • Tell the tracker you have the whole file (when you do; we’ll start with the file in place for this assign- ment). I’m pretty sure this is “left=0”. (Possibly also numwant=0.) There’s a right way to inform the tracker of incremental progress; feel free (optional feature) to use that instead of coding the special cases at the beginning of a download (last assignment) and at the end (this one).
  • Support arbitrarily many connections (though you could start dropping them if there are 50). Use select! (or the poll function.)
  • Listen on a port; accept connections on that port; receive, check, and reply to handshake messages.
  • Provide non-empty bitmask messages of the correct length. Don’t use the uTorrent (“have” message only) scheme.
  • Reply to interested messages with unchoke messages, unchoking at most 4 clients.
  • Reply to request messages with piece messages.
  • RATE-LIMIT your uploads to an easily configured value, defaulting to 64 Kbits per second. That’s 8 KBytes per second, and that means it should take two seconds to send the 16KB stuff you’ve been asking for. You may send the 16 then wait two seconds, wait two seconds and then send the 16, or send the message in fragments (as long as you don’t corrupt the message by sending a keep-alive or something else between the fragments). That’s intended to be a global limit; you may set per- connection limits, enforce fairness, send a greater fraction of this 64 Kbits to peers you’re interested in.

The protocol is well-documented at: http://wiki.theory.org/BitTorrentSpecification. A high- level overview is in the textbook page 711.

4 Future

The final deadline (5/9) will combine upload and download (adding have messages) and class-specific exten- sions, and it will be tested against a few in-the-wild torrents. It is reasonably easy to extend the first part of the project with seeder functionality; I do not expect a separate code base. The class-specific extensions to this client may incorporate multicast neighbor discovery from early pro- gramming assignments. I’m considering replacing that with a performance goal, implementing an encrypted client, or some other task.

5 Notes

Consider encoding the protocol state machine: because each connection advances independently, you’ll advance its state (from just-opened to received-handshake) one transition at a time. I hacked at this with a bunch of flags (e.g., “expecting-handshake”), but a connection state machine would likely be a better design. Here’s a free code fragment for holding pending events, if you can understand it (event queue bits for ruby). class Schedule @@events = Array.new def Schedule.delay() if @@events.empty? then nil else [ @@events[0][0] - Time.now, 0 ].max end end def Schedule.at(time, &block) @@events.push( [ time, block ] ) @@events.sort! { |a,b| a[0] <=> b[0] } end def Schedule.run_pending() while ( !@@events.empty? and @@events[0][0] <= Time.now ) do time, block = @@events.shift block.call end end end

if false then Schedule.at(Time.now + 1) { puts "hello" } Schedule.at(Time.now + 3) { puts "goodbye" } Schedule.at(Time.now + 5) { exit } puts Schedule.delay puts Schedule.run_pending sleep 1 puts Schedule.delay puts Schedule.run_pending sleep 1 puts Schedule.delay puts Schedule.run_pending sleep 1 puts Schedule.delay puts Schedule.run_pending sleep 1 puts Schedule.delay puts Schedule.run_pending sleep 1 exit end