Username:      Password:



Anatomy of a torrent session

(Updated to reflect the tracker changes. 21-09-2008)

There seems to be a lot of confusion about how the statistics updates work. The following is a capture of a full session to see what's going on behind the scenes. The client communicates with the tracker via simple http GET commands. The very first in this case was:

GET /3bfa64edd509add1c7516d7a62700366/announce?info_hash=%D9%A5%7B%B4%0E%1EZ%F9qS%0D8%B0%BF%26%9Ft%0F%92%F3&peer_id=-TR1320-

Let's explain what each parameter stands for:
  • info_hash - is just the hash identifying the torrent
  • peer_id - as the name suggests, identifies the client (TR1320 identifies Transmission 1.32, the rest is random)
  • port - just tells the tracker which port the client will listen to for incoming connections
  • uploaded=0 - this and the following are the relevant ones, and are self-explanatory)
  • downloaded=0
  • left=10235611 - how much left
  • compact - setting this to 1 indicates that the client accepts a compact response (it shouldn't bother you, really)
  • numwant - it's number of peers that the client would like to receive from the tracker, this value is permitted to be zero, if omitted defaults to 50 peers (optional)
  • key - an additional identification that is not shared with any users, it is intended to allow a client to prove their identity should their IP address change (optional)
  • event=started - tells the tracker that the client has just started

Notice that the client IP doesn't show up here (although it can be sent by the client if it configured to do so). It's up to the tracker to see it and associate it with the user_id.
(Server replies will be omitted, they're just lists of peer ips and respective ports.)
At this stage the user's profile will be listing this torrent as being leeched.

From now on the client will keep send GETs to the tracker. We show only the first one as an example,

GET /3bfa64edd509add1c7516d7a62700366/announce?info_hash=%D9%A5%7B%B4%0E%1EZ%F9qS%0D8%B0%BF%26%9Ft%0F%92%F3&peer_id=-TR1320-

As you can see at this stage the user had uploaded 0MB and downloaded approximately 13.21MB. Whenever the tracker receives these GETs it updates both the stats relative to the 'currently leeching/seeding' boxes and the total user upload/download stats. These intermediate GETs will be sent either periodically (every 15 min or so, depends on the client and tracker) or when you force a manual announce in the client.

Finally, when the client was closed it sent

GET /3bfa64edd509add1c7516d7a62700366/announce?info_hash=%D9%A5%7B%B4%0E%1EZ%F9qS%0D8%B0%BF%26%9Ft%0F%92%F3&peer_id=-TR1320-

Notice the all-important "event=completed". It is at this stage that the torrent will be removed from the user's profile. If for some reason (tracker down, lost connection, bad client, crash, ...) this last GET doesn't reach the tracker this torrent will still be seen in the user profile until some tracker timeout occurs. It should be stressed that this message will be sent only when closing the client properly, not when the download is finished. (The tracker will start listing a torrent as 'currently seeding' after it receives a GET with left=0).

There's a further message that causes the torrent to be removed from the user's profile, namely "event=stopped". This is usually sent when stopping in the middle of a download.

One last note: some clients have a pause/resume option. This will not send any message to the server. Do not use it as a way of updating stats more often, it just doesn't work.