- 1 BitTorrent Multitracker Specification
- 2 Multitracker Extension Detail
- 3 Examples
- 4 Bad Implementations
- 5 Known Implementers
- 6 Site Navigation
BitTorrent Multitracker Specification
- Based off of the official Multitracker Specification by John "TheSHAD0W" Hoffman.
- Portions edited by Harold "DreadWingKnight" Feit for clarity and to identify other tolerable implementations.
Multitracker Extension Detail
This specification is for John Hoffman's proposed extension to the BitTorrent metadata format. This extension has not been officially adopted into the main BitTorrent metadata specification as of this writing.
In addition to the standard "announce" key, in the main area of the metadata file and not part of the "info" section, will be a new key, "announce-list". This key will refer to a list of lists of URLs, and will contain a list of tiers of announces. If the client is compatible with the multitracker specification, and if the "announce-list" key is present, the client will ignore the "announce" key and only use the URLs in "announce-list".
Order of processing
The tiers of announces will be processed sequentially; all URLs in each tier must be checked before the client goes on to the next tier. URLs within each tier will be processed in a randomly chosen order; in other words, the list will be shuffled when first read (at torrent load or task start), and then parsed in order. In addition, if a connection with a tracker is successful, it will be moved to the front of the tier.
Some multitracker announce-list configurations generate peer swarm splits (usually when a tracker requires its announce urls to be first to be processed). When likely to encouter such a configuration, it is tolerable for a client to implement a system that causes each individual tier to have 1 tracker from it contacted per cycle, however the tier must be shuffled at the start of the task (same as in the BitTornado implementation above), and the last known good tracker must be moved to the front of the list every announce.
The description of these are based on BitTornado's implementation of multitracker. Those that follow that implementation will follow the rules listed here exactly.
Primary with backups
- d['announce-list'] = [ [tracker1], [backup1], [backup2] ]
On each announce, first try tracker1, then if that cannot be reached, try backup1 and backup2 respectively. On the next announce, repeat in the same order. This is meant for when the trackers are standard and can not share information.
- d['announce-list'] = [[ tracker1, tracker2, tracker3 ]]
First, shuffle the list. (For argument's sake, we'll say the list has already been shuffled.) Then, if tracker1 cannot be reached, try tracker2. If tracker2 can be reached, the list is now: tracker2,tracker1,tracker3. From then on, this will be the order the client tries. If later neither tracker2 nor tracker1 can be reached, but tracker3 responds, then the list will be changed to: tracker3,tracker2,tracker1, and will be tried in that order in the future. This form is meant for trackers which can trade peer information and will cause the clients to help balance the load between the trackers.
Load Balancing with backup
- d['announce-list'] = [ [ tracker1, tracker2 ], [backup1] ]
The first tier, consisting of tracker1 and tracker2, is shuffled. Trackers 1 and 2 will be tried on each announce (stopping on the first one that responds, though perhaps in varying order) before the client tries to reach backup1. Both tracker1 and tracker2 must fail on the same cycle before backup1 is contacted.
Load Balancing with Load Balancing backup
- d['announce-list'] = [ [ tracker1, tracker2 ], [ backup1tracker1, backup1tracker2 ], [backup2] ]
The first tier, consisting of tracker1 and tracker2, is shuffled. Trackers 1 and 2 will be tried on each announce (stopping on the first one that responds, though perhaps in varying order) before the client tries to reach either tracker in backup1. backup1's tracker1 and 2 are then tried in a similar fashion to the first tier. backup2 is not tried until the first and second tiers fail.
Announcing to EVERY tracker listed in an announce-list
This implementation is reasonable when none of the trackers share peer data, but when multiple trackers listed share peer data (such as with the EAD tracker network, or trackers that listen on multiple ports) this becomes very abusive.
Treating the entire announce-list as a single tier
This implementation could generate tracker lists where peers could get separated from the good swarms. Tiers are set up in a torrent for a reason. The reason is that each tier shares peer data and should be treated as if it were its own tracker.
Randomly announcing to a tier every announce
When you announce to a tracker in a tier successfully, you are supposed to lock-on to that tracker for subsequent announces to that tier in the sequence. When coupled with the above treating the entire announce-list as a tier problem, it's possible that your "stopped" and "completed" messages in announces won't make it into the correct tracker.
- BitTornado - Client and maker (Maker is in source package, full implementation) How to properly make multitracker torrents
- ABC - Client and maker (Maker has full implementation) How to properly make multitracker torrents
- Azureus - Client and maker (Maker has full implementation) How to properly make multitracker torrents
- BitComet - Client and maker (Maker is broken and generates a partial implementation, pure backup only, abusive in multitracker network layouts and multiple listen port trackers, maker not recommended for use)
- Rufus - Client (Does not handle multitracker properly as of 0.6.5, treats the entire announce-list as a single tier and does not lock-on to trackers within a tier properly)
- µTorrent - Client and maker (Maker has full implementation) How to properly make multitracker torrents
- Burst! and Maketorrent - Client and maker (Maker has a partial implementation, pure backup only, abusive in multitracker network layouts and multiple listen port trackers, Strongly not recommended)
- EAD TorrentBuild - Maker (Maker has full implementation) How to properly make multitracker torrents