BitTorrent Extension Protocol (5) –UDP Tracker Protocol for BitTorrent

Contents Introduction overhead UDP connections/spoofing Time outs Examples UDP tracker protocol Existing IPv6 Extensions References and footnotes Introduction

To discover the other peers in a swarm a client announces it's existance to a tracker. The HTTP protocol is used and a typical request contains the following Parameters:info_hash, key, peer_id, port, download Ed, left, uploaded and compact. A response contains a list of peers (host and Port) and some other information. The request and response are both quite short. Since TCP is used, a connection has to be opened and closed, introducing additional. Overhead

Using HTTP introduces significant overhead. There ' s overhead at the Ethernet layer (bytes per packet), at the IP layer (bytes/packet), at the TCP layer (20 Bytes per packet) and at the HTTP layer. About packets are used for a request plus response containing peers and the total number of bytes ' is about 1206 [1]. This overhead can is reduced significantly by using a UDP based protocol. The protocol proposed here is uses 4 packets and about 618 bytes, reducing traffic by 50%. For a-client, saving 1 kbyte every hour isn ' t significant, but for a tracker serving a million peers, reducing traffic by 50% matters a lot. An additional advantage be that's that a UDP based binary protocol doesn ' t require a complex parser and no connection handling, R Educing the complexity of tracker code and increasing it ' s performance.

(The idea is very simple, TCP is more than UDP sent packets, so it is better to use UDP. TCP is the original diagram to facilitate the use of HTTP protocol directly) UDP connections/spoofing

In the ideal case, only 2 packets would is necessary. However, it is possible to spoof the source address of a UDP packet. The tracker has to ensure this doesn ' t occur, so it calculates a value (CONNECTION_ID) and sends it to the client. If the client spoofed it ' s source address, it won ' t receive this value (unless it's sniffing the network). The connection_id would then be send to the tracker again in Packet 3. The tracker verifies the connection_id and ignores the request if it doesn ' t match. Connection IDs should not being guessable by the client. This are comparable to a TCP handshake and a SYN cookies like approach can are used to storing the connection IDs on the TRAC Ker side. A connection ID can be used for multiple requests. A client can use a connection ID until one minute after it has received it. Trackers should accept connection ID until two after it minutes send.

(prevents UDP spoofing because UDP can forge the source address.) using a mechanism similar to track ID to prevent. First customer peer handshake, tracker return an ID, the final customer resend this ID confirmation) Time Outs

UDP is an ' unreliable ' protocol. This means it doesn ' t retransmit lost packets itself. The application is responsible to this. If a response is isn't received after * 2 ^ n seconds, the client should retransmit the request, where n starts at 0 and is increased up to 8 (3840 seconds) after every retransmission. This is the necessary to rerequest a connection ID when it has expired. examples

Normal Announce:

t = 0:connect Request
t = 1:connect response
t = 2:announce Request
t = 3:annonce response

Connect times out:

t = 0:connect Request
t = 15:connect Request
t = 45:connect Request
t = 105:connect Request
etc

Announce times out:

t = 0:
t = 0:connect Request
t = 1:connect response
t = 2:announce Request
t = 17:announce Request
t = 47:announce Request
t = 107:connect request (because connection ID expired)
t = 227:connect Request
etc

Multiple requests:

t = 0:connect Request
t = 1:connect response
t = 2:announce Request
t = 3:annonce response
t = 4:announce Request
t = 5:annonce response
t = 60:announce Request
t = 61:annonce response
t = 62:connect Request
t = 63:connect response
t = 64:announce Request
t = 64:scrape Request
t = 64:scrape Request
t = 64:announce Request
t = 65:announce response
t = 66:announce response
t = 67:scrape response
t = 68:scrape response

UDP Tracker Protocol

All values are the Send in network byte (the big endian). Don't expect packets to be exactly of a certain size. Future extensions could increase the size of packets.

(The following specific protocols are not detailed, because the semantics of the standard BT protocol are exactly the same in the case of a TCP link, except that the UDP connection is used and the connection is correct.)

Before announcing or scraping, you are have to obtain a connection ID. (That is to say this has already sent a back and forth UDP packet, get the connection ID, the following is the 3rd package) Choose a random transaction ID. Fill the Connect request structure. Send the packet.

Connect Request:

Offset Size Name Value
0 64-bit Integer connection_id 0x41727101980
8 32-bit Integer Action 0//Connect
32-bit integer transaction_id

————————————————-Receive the packet. Check whether the packet is at least bytes. Check whether the transaction ID is equal to the one you chose. Check whether the action is connect. Store the connection ID for future use.

Connect response:

Offset Size Name Value
0 32-bit Integer Action 0//Connect
4 32-bit integer transaction_id
8 64-bit integer connection_id
16

————————————————-Choose a random transaction ID. Fill the announce request structure. Send the packet.

Announce Request:

Offset Size Name Value
0 64-bit Integer connection_id
8 32-bit Integer Action 1//announce
32-bit integer transaction_id
20-byte string Info_hash
20-byte string peer_id
64-bit integer Downloaded
64-bit Integer Left
64-bit Integer uploaded
32-bit Integer event 0//0:none; 1:completed; 2:started; 3:stopped
32-bit integer IP address 0//default
32-bit integer Key
32-bit integer num_want-1//default
16-bit Integer Port
98

————————————————-Receive the packet. Check whether the packet is at least bytes. Check whether the transaction ID is equal to the one you chose. Check whether the action is announce. Do not announce again until interval seconds have or a event passed has.

Announce response:

Offset Size Name Value
0 32-bit Integer Action 1//announce
4 32-bit integer transaction_id
8 32-bit integer Interval
32-bit integer leechers
32-bit integer seeders
+ 6 * N 32-bit integer IP address
6 * n 16-bit integer TCP port
+ 6 * N

————————————————-

Up to about torrents can scraped at once. A full scrape can ' t is done with this protocol. Choose a random transaction ID. Fill the scrape request structure. Send the packet.

Scrape Request:

Offset Size Name Value
0 64-bit Integer connection_id
8 32-bit Integer Action 2//Scrape
32-bit integer transaction_id
+ * N 20-byte string Info_hash
+ * N

————————————————-Receive the packet. Check whether the packet is at least 8 bytes. Check whether the transaction ID is equal to the one you chose. Check whether the action is scrape.

Scrape response:

Offset Size Name Value
0 32-bit Integer Action 2//Scrape
4 32-bit integer transaction_id
8 + * N 32-bit integer seeders
+ N 32-bit Integer completed
+ N 32-bit integer leechers
8 + * N

————————————————-

If the tracker encounters an error, it might send a error packet. Receive the packet. Check whether the packet is at least 8 bytes. Check whether the transaction ID is equal to the one you chose.

Error response:

Offset Size Name Value
0 32-bit Integer Action 3//Error
4 32-bit integer transaction_id
8 String Message Existing implementations

Azureus, Libtorrent [2], OpenTracker [3], XBT Client and XBT Tracker support this protocol. IPv6

IPV6 is isn't supported at the moment. A simple way to support IPV6 would being to increase the size of all IP addresses to 128 bits when the request was done I Pv6. However, I experience with IPv6 and discussion is needed before including it. Extensions

Extension bits or a version field are not included. Clients and trackers should not assume packets to be of a certain size. This is way, additional fields can be added without breaking.