- 5 points:
your program compiles without errors [warnings are OK, but not
recommended], produces a single ubtorrent
executable on both Linux and SunOS. Moreover, ubtorrent
handles user's input graciously: it should report an error if the input
lacks one
parameter and stuff like that. Don't need ot be too careful, but don't
crash if
only the TCP port is typed. Please also remember to put your and your
partner's name/ID in a README file along with any compilation
instruction.
- 25
points:
the
metainfo command works. The more detailed
breakdown is as follows.
my IP/port: 4 points.
my ID, metainfo
file's name, file name, piece
length, file size, URL:
1 point each, for a total of 6 points.
pieces' hashes: 5 points.
info hash: 10 points.
We will test your program with several different .torrent
files, varying the file names, sizes, piece lengths, URLs. Thus, please
do not assume
anything about those parameters. They are supposed to be read from the
input metainfo file. You should definitely test your program with
.torrent files whose piece lengths are
different from 218. To do so, vary the number 16
below:
btmakemetafile Dan\ Hill\ \&\ Rique\ Franks\ -\ Sometimes\ When\ We\ Touch.mp3 http://127.0.0.1:6969/announce --piece_size_pow2 16
as I've explained in a blog post a while back. We won't test your
program with corrupted metainfo files. You can assume that the metainfo
file was created nicely using the btmakemetainfo
utility.
- 20
points: the
announce and trackerinfo
commands
work correctly across different endian formats. We shall only run the
opentracker on a Linux machine, because that was the only binary
version provided on the webpage. However, your program should compile
and run on both Linux & SunOS machines.
- 10 points:
announce and trackerinfo
command work when
your program is run on a Linux machine
- 5 (additional) points:
announce
and trackerinfo command work when
your program is run on a SunOS machine. This is mainly to test if you
have converted the tracker's peer list response correctly from
network-to-host byte orders.
- 5 (additional) points: when you graciously exit/quit
your
ubtorrent, you send a GET
to tracker with event=stopped. This way,
the tracker will not include you in the response to later tracker
requests.
What do I mean by "the commands work"? You should try to run several
instances of my ubtorrent on different
machines before running yours. Type announce
at my ubtorrent terminals for my ubtorrent
to inform the tracker of their existences. At least one of them must be
a tracker, and at least one
is a leecher. Use the -d 15 option to delay
their downloads so that the leecher keeps being a leecher for a while.
Then, run your ubtorrent, type announce
and then trackerinfo. The expected output is
something like this:
ubtorrent> trackerinfo
complete | downloaded | incomplete | interval | min interval |
---------------------------------------------------------------
2 | 0 | 1 | 1764 | 882 |
---------------------------------------------------------------
++++ Peer List (self not included):
IP | Port
-------------------------------
192.168.1.103 | 9997
192.168.1.103 | 9999
192.168.1.103 | 9998
You don't have to output the downloaded
field in the tracker's reply. That's optional. The complete
and incomplete fields must
report the correct numbers. And, the peer list must also be correct.
(Though not as important, interval and min
interval should be reported correctly too.)
To test the event=stopped requirement, you
can run a single instance of my ubtorrent
(remember to download the latest releases). Then, run your ubtorrent,
announce it. Type announce
and print the tracker's response with trackerinfo
on my ubtorrent's terminal. Finally, exit
your ubtorrent. At this point, you should
have sent the final GET to the tracker.
Type announce
and print the tracker's response with trackerinfo
on my ubtorrent's terminal. The output should
have one less peer than the previous output.
- 5
points: your
ubtorrent detects correctly if it
is a leecher or a seeder by looking into the current working directory
to see if a file with the same name and the same (expected) size exists.
If the file does exist, it's assumed that you're a seeder;
if not, you must be a leecher.
The gray area is when the file exists but the file size doesn't match,
in which case you should report an error.
In seeder's mode, the status command should output something like
this:
ubtorrent> status
Downloaded | Uploaded | Left | My bit field
------------------------------------------------
0 | 0 | 0 | 1111111111111111
The bit field should be all-0 in leecher's mode (in the beginning).
- 5
points: your
ubtorrent
sucessfully connect and
handshake with other instances of my ubtorrent
which are in the peer
list returned by the tracker. To test this case, run several instances
of my ubtorrent as seeders, and an instance
of yours as a leecher. The
-v option will tell you whether or not the handshakes were completed as
planned. You must attempt to make connections to peers in the tracker
response. (For instance, if we run only your ubtorrent,
they should
connect and handshake each other.)
- 5
points: your
ubtorrent handles
the bitfield message (from peers) correctly.
This must be reflected through the show
command, which shows the bitfields of the connected
peers (which are all the running peers up to some upper bound, say 30).
For example, if you are connected to a seeder and a leecher (both are
my ubtorrent instances), then the show output should be something like
this:
ubtorrent> show
ID | Peer's IP/port | Status | Bitfield | Down/s | Up/s |
----------------------------------------------------------------------------
1 | 192.168.1.103/9998 | 0101 | 0000000000000000 | 0 | 0
2 | 192.168.1.103/9999 | 0100 | 1111111111111111 | 0 | 0
- 5
points: your
ubtorrent handles
the choke, unchoke,
interested, not interested,
and have messages (from peers) correctly.
This must be reflected through the "Status" part of the show
command's output.
For example, while one of my ubtorrent is downloading,
its bitfield will change gradually from all-0 to all-1.
Keep typing show on your ubtorrent's terminal
(say, being run in seeder's mode) and you should see the gradual
transformation.
- 10
points: your
ubtorrent runs correctly as a seeder.
(CHOKE algorithm is not required to get these 10 points.)
To test this, run yours as a seeder, and several instances of mine as
leechers to see if they can download from yours successfully.
In fact, also try to run several instances of yours as seeders, not just
one single seeder.
- 10
points: your
ubtorrent runs correctly as a leecher.
The roles of your and my ubtorrent are reversed.
Make sure to run several instances of my ubtorrent as
seeders with varying delays.
You must also send the tracker a GET request with
event=completed status after you've downloaded the
entire file.
Please do remember to check the SHA1 hash value of every piece
you download. We will compare the downloaded file with the original
file byte by byte to see if they match.
The cmp file_1 file_2 command can be run to do the
comparison.
- 5
points: your
ubtorrent implements the
rarest first algorithm correctly.
- 5
points: your
ubtorrent implements the
choke (and optimistic unchoke) algorithm correctly.