Multitracker Metadata Extension is a metadata extension for the BitTorrent protocol that aims 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 way, 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. This allows clients to quickly find active trackers. This enables Torrent files to start downloading faster and also reduces the load on individual trackers.
Metadata Extension#
BitTorrent metadata files include 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 of 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 multi-tracker specification and both the "announce" and "announce-list" keys exist 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 improve 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 are processed in random order to avoid slow or failed download speeds caused by some 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. This approach seems to be related to the inability of different trackers to share information with each other. By trying 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, assume that 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 connection attempts in that 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 connection attempts in that order.
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 of a single tracker.
d['announce-list'] = [ [ tracker1, tracker2 ], [backup1] ]
In this 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.