I didn’t receive many questions about UBTorrent, and that makes me worried. You have to start now! Start implementing the metainfo command first, then announce and trackerinfo.
Please ask questions soon, before it’s too late.
-
Recent Comments
i have following questions about the project 2
1. Does the client starts downloading the file as soon as it is started (in leecher state) or does he have to wait for announce command form the user?
2. Do we have to send the GET request regularly to the tracker or only when announce command is typed? i ask this question because i got confused by the “interval” key in the response from the tracker.
3. what does key in the following mean ?
GET /announce?info_hash=_tWL%26%BD%C4%BDsEn%FD%7E1%2CJ3%40s%1B&
peer_id=M3-4-2–5ffd511f4079&port=6881&key=585b8345&uploaded=0&downloaded=0&left=0&compact=1&event=started HTTP/1.1
Shashank,
1. Without ‘announce’, a peer doesn’t know info about other peers to start downloading
2. GET request is only sent when announce is type, *and* when a downloading is finished (to inform the tracker of a new status)
3. you can ignore the ‘key’ part, don’t have to send any ‘key’ to tracker
But in Project 2 specification
“what you are supposed to implement” section
the following is mentioned.
“Otherwise, it is running in the leecher state. The client then issues a GET request to the tracker rightaway.” Dr. Ngo, Please clarify this point….
Ah, so the spec is wrong on that. Please only send GET after ‘announce’ is type; run my implementation to see the expected behavior
i have one more question.
in the project spec, at “3.3.1 Tracker Request Parameters” the explanation for the event field in the request field goes like this
“event: If specified, must be one of started, completed, stopped, (or empty which is the same as not being specified). If not specified, then this request is one performed at regular intervals. “. What does it mean ?
Since GET requests in UBTorrent aren’t periodic, ‘event’ MUST be specified with each request
Oh ok.. is it ok if we send started event more than once ( i, e if user types announce command more than once ) to the tracker. or do we have to make sure that user types announce command only once or rather event started is sent only once to the tracker?
announce can be typed many times; again, run my ubtorrent implementation to see the expected behavior
one more question
1. what is the number connections that a client has to support with the remote peer…?
put some arbitrary upper bound, say 10
I have a doubt in receiving peer list from tracker HTTP Response. It is mentioned in specification every peer will have 6 bytes to represent IP address and Portno.
In which, 4 bytes are for each subnet of IP address (192 . 205 . 36 . 24)
where as, 2 bytes for port number.
I am not sure how to decode last 2 bytes of information to four digit port number.
When I tried to decode similar like first four bytes,
I get 221 202 for last 2 bytes
whereas i decoded IP address as 128.205.35.174 from first 4 bytes correctly.
Hi, 2-byte integers can store integers as large as
. You are confusing between the ASCII representation of a number which is printed to the screen, and the way computers store numbers.
Hi,
For acknowledgement part, I need to check whether unique ID sent by peer matches with peerid received from the tracker.
I tried to read HTTP Response from the tracker. It is gives response in Binary mode where I retrieved only IP address/port no of peers. not the unique peer ID.
Peer ID is present only in dictionary mode of tracker response. Do i need to do anything to get tracker response in dictionary mode??
Hi Mahesh, you can ignore the “check peer ID” part in the handshake; just use the binary mode to talk to the tracker.
Dear Professor,
During handshake, Am I supposed to handle multiple torrents(info_hash) in a single instance of my ubtorrent???
Just a single torrent
When I run a Announce command on your implementation. It gives an error “ERROR: can’t read from connection # 1, closing it”.
I think it was trying to connect to yours or something
I didnt run any other implementation other than yours and the tracker.
Dear Professor,
In handshake message, It was mentioned in specification to use UBTorrent protocol as protocol name whereas your binaries send protocol name as BitTorrent protocol.
Please use 19 and “BitTorrent Protocol”
I am unable to handshake with your binary. When I tried to read your handshake message, I got the following things.
1. First byte which was in UTF-8/ network format, which if i tried to printed as hexadecimal resulted in value 13.
2. “BitTorrent Protocol”
3. “00000000″
4. 20 byte infohash in UTF-8 format
5. 20 byte UID of peer in UTF-8 format.
Please clarify the handshake message format of your binary.
I have a doubt in showing bit field of connected peers. If I am running more than one seed (my ubtorrent), then a leecher may request different pieces from different seeders. That way, seeder may know about the pieces transferred by it. So seeder may update only those corresponding bit fields. I believe it won’t reflect the true bit field state of leecher.
Do we need to transfer bitfield of every leecher at regular intervals???
Correct me if my question is absurd!!!
I got answer for my question!!! Now, I realize the significance of HAVE message!!!
While running my UBTorrent in leecher mode, whether it is supposed to request for pieces from other leechers (who have downloaded it previously from leechers) ??
Hello Professor,
I have downloaded the opentracker code as directed in the project description and ran it. It is running properly. However when I send a GET request to the tracker using your binary(using the announce command), i get a HTTP 400 error as response.
I cannot figure out what is the problem.
Vinay, what kind if 400 error? Are you running the tracker on the same machine/IP for which the metainfo file points to?
Yes I am running it on the same machine.
My announce url = http://127.0.0.1:6969/announce and the opentracker.debug exe is under the path /ubtorrent/opentracker
and then I am running your binary from other directory.
The output for the metainfo and announce commands are as below
ubtorrent> metainfo
my IP/port : 127.0.1.1/99999
my ID : ad66313bce57d141cdd68e541d2b74b60154cc55
metainfo file : /home/vinay/ubtorrent/file/ss.mp3.torrent
info hash : f027f3265d2344c82756b2c820116f25cb815a15
file name : ss.mp3
piece length : 262144
file size : 90112 (0 * [piece length] + 90112)
announce URL : http://127.0.0.1:6969/
pieces’ hashes:
0 9e64e305080dc12910bf6f8669f36eeef5c0d7ac
ubtorrent> announce
ubtorrent>
ubtorrent>
++++ Tracker responded: HTTP/1.0 404 Not Found
Ignore this tracker response. … Tracker closed connection
and the output of the tracker is as below
vinay@ubuntu:~/ubtorrent/opentracker$ ./opentracker.debug -i 127.0.0.1
Binding socket type TCP to address [127.0.0.1]:6969… success.
Binding socket type UDP to address [127.0.0.1]:6969… success.
I guess we resolved that today. The problem is 99999 is more than the maximum port number, and thus the tracker declined the request.
hi Professor,
I am still not able to get a valid response back from the tracker (getting http 400 error).
the get request is as below
GET http://127.0.0.1:6969/announce?info_hash=%f0%27%f3%26%5d%23D%c8%27V%b2%c8%20%11o%25%cb%81Z%15&peer_id=vinayvinayvinayvinay&port=49491&uploaded=0&downloaded=0&left=0&compact=1&event=started HTTP/1.1
your binary gets a valid response back from tracker.
please suggest.
GET requests should start with
GET /announce?…
not GET http://127.0.0.1:6969/announce?…
yes i figured that out….
thanks
Hello Professor
I was testing my ubtorrent implementation with your implementation. I wanted to verify the handshaking and the exchange of the bitfield part.
There are two scenarios
1. If my ubtorrent sends the handshake to your implementation first, then after the exchange of handshake messages from both sides, I am getting unchoke message from your client in two parts (I am receiving two different messages), first I get 4 bytes and then I receive 1 byte.
2. If your ubtorrent initiates the handshake (if it sends the handshake to my ubtorrent first) then after the exchange of handshake message from both sides, I receive the bitfield sent by your implementation in two parts. I receive 4 bytes first and then I receive 2 bytes long separate message.
Is this how your implementation actually works? or its just me going wrong somewhere?
Rohit,
TCP is a byte stream service, so you should not be surprised if you get a 5-byte “message” in … 5 parts, each part 1 byte.
Hello Professor,
I have the following questions………
1. In the leecher state are we supposed to maintain the connections with the seeders once the download is complete ? (because if we close the connection we can serve more leechers as the number of connections is limited by some upper bound. )
2. Same question goes in seeder state. i.e are we supposed to maintain the connections with the leecher who has downloaded the all the pieces. (we can get this info form the bit field of the leecher and the have messages sent by him).
In both above questions if we close the connections, what about the output of “show” command ?
3. and how are we supposed to calculate the upload speed for a connection ?. I am following the strategy of calculating the time between two consecutive requests for pieces and the bytes uploaded between those requests (thanks to sandeep)(bytes uploaded / time taken), is this method correct ?
4. Is it wrong to send interested message every time before downloading a piece? I know that your implementation does not do that.
and one more thing in the ubtorrent binary (for linux 32 bits), the trackerinfo command output it shows the peer list with self included. And i think it tries to connect to itself and sends the bitfield message also (i may be wrong), if we run 32 bit binary in verbose it shows some messages which suggests above behavior.
My implementation does not try to connect to itself
this is the scenario when one instance of ubtorrent-linux-32 in seeder mode and tracker are run.
./ubtorrent-Linux-32 -f Dan\ Hill\ \&\ Rique\ Franks\ -\ Sometimes\ When\ We\ Touch.mp3.torrent -p 8798
ubtorrent release 0.7 (c) 2009-2010 Hung Q. Ngo
ubtorrent comes with ABSOLUTELY NO WARRANTY.
This is a free software which is not usable anywhere, and thus you are
free to redistribute it under whatever license your please;
ubtorrent> announce
ubtorrent>
ubtorrent>
++++ Tracker responded: HTTP/1.1 200 OK
… Tracker closed connection
ubtorrent> trackerinfo
complete | downloaded | incomplete | interval | min interval |
—————————————————————
1 | 2 | 0 | 1928 | 964 |
—————————————————————
++++ Peer List (self not included):
IP | Port
——————————-
127.0.0.1 | 8798
++++ Tracker responded: HTTP/1.1 200 OK^M
===> Ignore Content-Type: text/plain^M
===> Content-Length = 98
===> … parsing peer list from tracker, 1 peers
… Tracker closed connection
ubtorrent> NOTE: Connecting to a new peer
NOTE: Connected sucessfully to 127.0.0.1 8798
===> … made new friend at 127.0.0.1 8798
NOTE: Sending HANDSHAKE to [cid=0, ip=127.0.0.1, port=8798]
===> … Handshake sent
===> Reached the end of peer list tracker provided
===> There are 0 requests in the queue
NOTE: connection request received
===> Not trying to make new connections
===> There are 0 requests in the queue
NOTE: Reading handshake
===> … Peer’s Protocol: BitTorrent protocol
===> … reading info_hash
===> … info_hash matched
NOTE: Sending HANDSHAKE to [cid=1, ip=127.0.0.1, port=41962]
===> … Handshake sent
===> … reading peer id
===> … Handshake received
NOTE: Sending BIT_FIELD msg to [cid=1, ip=127.0.0.1, port=41962]
===> … sending len
===> … sending type 5
===> … sending payload
===> Bit field sent
===> Not trying to make new connections
===> There are 0 requests in the queue
NOTE: Reading handshake
===> … Peer’s Protocol: BitTorrent protocol
===> … reading info_hash
===> … info_hash matched
===> … reading peer id
===> … Handshake received
NOTE: Sending BIT_FIELD msg to [cid=0, ip=127.0.0.1, port=8798]
===> … sending len
===> … sending type 5
===> … sending payload
===> … sending payload
===> Bit field sent
===> Not trying to make new connections
===> There are 0 requests in the queue
===> Trying to read 2 byte(s) from socket
readn: Connection reset by peer
reading peer’s message: Invalid argument
NOTE: … can’t read from connection # 1, closing it
===> Not trying to make new connections
===> There are 0 requests in the queue
===> Not trying to make new connections
===> There are 0 requests in the queue
===> Not trying to make new connections
===> There are 0 requests in the queue
===> Not trying to make new connections
===> There are 0 requests in the queue
NOTE: BYE BYE, closing shared_fd
Ah, thanks;
I should probably rephrase: “my implementation does not try to maintain a connection to itself”;
1. You don’t have to close the connection. “Serving” can still be done with the choke algo, because we do not need to rank seeders to unchoke
2. Same answer
3. Output of the “show” command should reflect the current peers, not disconnected peers
For simplicity: upload speed = # bytes/connection duration
4. Interested/disconnected messages are only sent when there’s a change in the status (from interested to disinterested and vice versa)
I have a question about the extra bits in the bitfield. I realize that there has to be at least as many bits in the bitfield as there are pieces of the file, but I’m not sure how to calculate how many extra bits to include. It seems like that would be important since you mention in the spec that clients should drop the connection if they receive bitfields that are not of the correct size.
@Nick, the # of bits in the bitfield has to be a multiple of 8, to fit in the byte boundary. The # of extra (zero) bits can be computed from that requirement
for instance, if there are 13 pieces, then there must be 3 extra 0 bits; if there are 37 pieces then there must be 5 extra 0 bits; etc.
The link for the ubtorrent-linux 32 bit is broken
please reload, it should work now. thanks!
Professor,
Whenever I run announce and trackerinfo on my implementation and yours. The trackerinfo gives different information to mine and a different information to your implementation. My implementation interacts well with itself but doesn’t with yours since of the above problem.
Please advice
you mean different IP/ports?
Yes, and even the downloaded, uploaded sections.
it’s possible that other people running on the same machine are connecting to the tracker; also, the order in which you do ‘announce’ might affect how peers “see” the reply
Professor,
Can you upload your version of the BitTorrent. It would be great to study from that for the exams.