Multitracker Metadata Extension is a metadata extension for the BitTorrent protocol designed to improve the efficiency of collaboration between multiple BitTorrent trackers. This extension allows Torrent files to contain a list of addresses from multiple trackers, and clients can use these addresses to connect to any available tracker. This means that if one tracker is offline, clients can still download or share files through other trackers.
Unlike the standard BitTorrent protocol, the Multitracker Metadata Extension includes a list of tracker addresses, allowing clients to find active trackers more quickly. This enables Torrent files to start downloading faster and also reduces the load on individual trackers.
The BitTorrent metadata file includes two keys: one is the standard "announce" key, and the other is the new "announce-list" key. Both keys are used to specify a list of URL addresses for BitTorrent tracker servers that clients can use.
Unlike the "announce" key, the "announce-list" key refers to a nested list, where each inner list represents a priority level for a tracker server. This means that clients will first send requests to all servers in the first inner list, and if they are unavailable or unresponsive, they will try the servers in the next inner list until they find an available tracker server.
If a client supports the Multitracker specification and both the "announce" and "announce-list" keys are present in the metadata file, the client will only use the URL address list in the "announce-list" and ignore the addresses in the "announce" key. This can improve download efficiency and reliability because using multiple tracker servers makes it easier for download tasks to find other peers and increase download speed.
Execution Order#
The URL address list in the "announce-list" key is processed one by one according to priority levels (tiers). The client will process the URL addresses in the list one by one according to the priority levels, instead of processing all addresses simultaneously. Within each priority level, the URL addresses will be processed in random order to avoid slow or failed downloads due to certain addresses being at the front. Additionally, if a client successfully connects to a Tracker server, the priority level of that server will be moved to the front of the list, increasing the probability of communication with that server and speeding up the download.
Example:
d['announce-list'] = [ [tracker1], [backup1], [backup2] ]
When an "announce" event occurs, it is recommended to first attempt to connect to "tracker1". If the connection fails (possibly because the tracker is unavailable), then attempt to connect to "backup1", and if that fails as well, try "backup2". The same attempt order should be repeated for the next announcement - first try "tracker1", then "backup1", and finally "backup2" if necessary. The reason for this approach seems to be related to the inability of different trackers to share information with each other. By attempting to connect to each tracker in the same order every time, the system can ensure that the most preferred tracker is always attempted first, while still having alternative options in case that tracker is unavailable.
d['announce-list'] = [[ tracker1, tracker2, tracker3 ]]
First, assuming a list of trackers has been shuffled. When a client needs to connect to a tracker, it will attempt to connect in the following order:
- First attempt to connect to "tracker1".
- If unable to connect to "tracker1", attempt to connect to "tracker2".
- If able to connect to "tracker2", rearrange the tracker list to "tracker2,tracker1,tracker3" and continue with subsequent connection attempts in this order.
- If unable to connect to "tracker2" or "tracker1", but able to connect to "tracker3", rearrange the tracker list to "tracker3,tracker2,tracker1" and continue with subsequent attempts.
Load balancing strategy between trackers. This approach allows for the exchange of information between clients and trackers, enabling load balancing and avoiding performance degradation due to overload on a single tracker.
d['announce-list'] = [ [ tracker1, tracker2 ], [backup1] ]
During the process, the system is divided into three tiers: tracker1, tracker2, and backup1. The first tier includes tracker1 and tracker2, and their order may be random. When an "announce" event occurs, the system will attempt to connect to tracker1 and tracker2 in a certain order (the order may be different for each event) before attempting to use backup1. In other words, the system will try to connect to tracker1 and tracker2 before attempting to use backup1.