

Study with the several resources on Docsity
Earn points by helping other students or get them with a premium plan
Prepare for your exams
Study with the several resources on Docsity
Earn points to download
Earn points by helping other students or get them with a premium plan
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
1 / 2
This page cannot be seen from the preview
Don't miss anything!


Goal: Seed a file through BitTorrent; Rate-limit.
DUE: Friday, April 25. The late deadline will be Monday, April 29; you have only one late deadline to play with.
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.
Alter part 1 for the following:
The protocol is well-documented at: http://wiki.theory.org/BitTorrentSpecification. A high- level overview is in the textbook page 711.
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.
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