Comparison between the different Bittorrent tracker modes:
(Ratings: 3.35 / 5 - Votes: 23) |
|
BitTorrent is a peer-to-peer file sharing protocol designed by Bram Cohen. Visit his pages at
www.bitconjurer.org BitTorrent is designed to facilitate file transfers among multiple peers across unreliable networks.
The purpose of this article is not to explain how all different bittorrent tracker modes work,but to compare the consequences of each mode on the average trafic generated.
We won't explain here how Bittorrent works, so if you want to learn more about bittorrent, check
here.
There are 4 different modes for a tracker to send its data to the client:
- normal http mode
- no_peer_id http mode
- compact http mode
- udp mode
We will take into consideration in this study only the 3 http modes:
Announce Data :
In order to see what is the impact of each mode on the trafic of your tracker, I have been doing some tests onto a .torrent file with 2000 peers on it, and reported the results into this chart :

Legend:
- #1: normal mode
- #2: normal mode (gzipped)
- #3: compact mode
- #4: compact mode (gzipped)
- #5: no_peer_id mode
- #6: no_peer_id mode (gzipped)
|
(The exact results are #1: 3364 bytes, #2: 1362 bytes, #3: 362 bytes, #4: 365 bytes, #5:1773 bytes and #6: 572 bytes)
As you may notice, the compact mode gives the best results. Though, even if using GZIP compression generally reduces the output generated by the tracker, we can see that in compact mode, gzipped data uses more bytes than non gzipped one !
Using compact mode, the output size is divided by 10 !
Scrape Data :
Now we compare size differences for the scrape data. In this test,we have chosen a tracker with 137 torrents onto it.

Legend:
- #1: normal mode
- #2: normal mode (gzipped)
- #3: compact mode
- #4: compact mode (gzipped)
|
(The exact results are #1: 9274 bytes, #2: 3629 bytes, #3: 3188 bytes, #4: 2996 bytes)
The compact scrape mode doesn't exist currently, it's just a new scrape scheme I (sqrtboy@phpsoft.org) have been working around.
As you may notice, compact scrape mode is still better than gzipped normal mode, though the differences are very low. Using compact scrape + gzip compression gives the best results !
Here would be the implementation of compact scrape :
When BT client ask for scrape, the tracker would reply :
"d6:scrape".length($data).":".$data."e";
where $data will be built the following way :
for each infohash :
$data .= $infohash . $leechers . $seeders . $times_completed ;
where :
- $infohash: 20 bytes infohash of the torrent
- $leechers: 2 bytes value : number of leechers, example: 150 leechers => 0x00 0x96
- $seeders: 2 bytes value : number of seeders, example: 1578 seeders => 0x06 0x2A
- $times_completed: 2 bytes value : number of times_completed, example: 150 times completed => 0x00 0x96
If the number of leechers, seeders or downloaded times is higher to 65535 (FF FF), it will be set to 65535.
You might have noticed too that length of $data must be a multiple of 26, if it is not, then the tracker has sent corrupted data.
To know if the bt client supports compact scrape feature or not, the client can send in the GET request the key "compact=1", if the tracker doesn't support compact scrape, it will skip this param and gives a normal scrape, else it will gives the compact one.
Now, the PROS and CONS about this method :
- PROS: It uses less bandwith and can be easily implanted on any existant tracker
- CONS: BT clients need more computing to interpret the scrape data, since the result is not an array but just a string.
If you are interested in this work, I have written a scrape converter in PHP that would take the scrape data and converts it to compact scrape data.Contact me
here
I hope that this document helped you to understand how much using BT clients supporting compact mode and/or no_peer_id mode could help tracker sites to reduce their bandwith consumption.