| 1 | BEP: 12 |
|---|
| 2 | Title: Multitracker Metadata Extension |
|---|
| 3 | Version: $Revision$ |
|---|
| 4 | Last-Modified: $Date$ |
|---|
| 5 | Author: John Hoffman <theshadow@degreez.net> |
|---|
| 6 | Status: Draft |
|---|
| 7 | Type: Standards Track |
|---|
| 8 | Created: 07-Feb-2008 |
|---|
| 9 | Post-History: |
|---|
| 10 | |
|---|
| 11 | |
|---|
| 12 | Metadata Extension |
|---|
| 13 | ================== |
|---|
| 14 | |
|---|
| 15 | In addition to the standard "announce" key, in the main area of the |
|---|
| 16 | metadata file and not part of the "info" section, will be a new key, |
|---|
| 17 | "announce-list". This key will refer to a list of lists of URLs, and |
|---|
| 18 | will contain a list of tiers of announces. If the client is compatible |
|---|
| 19 | with the multitracker specification, and if the "announce-list" key is |
|---|
| 20 | present, the client will ignore the "announce" key and only use the |
|---|
| 21 | URLs in "announce-list". |
|---|
| 22 | |
|---|
| 23 | |
|---|
| 24 | Order of Processing |
|---|
| 25 | =================== |
|---|
| 26 | |
|---|
| 27 | The tiers of announces will be processed sequentially; all URLs in each |
|---|
| 28 | tier must be checked before the client goes on to the next tier. URLs |
|---|
| 29 | within each tier will be processed in a randomly chosen order; in other |
|---|
| 30 | words, the list will be shuffled when first read, and then parsed in |
|---|
| 31 | order. In addition, if a connection with a tracker is successful, it |
|---|
| 32 | will be moved to the front of the tier. |
|---|
| 33 | |
|---|
| 34 | Examples: :: |
|---|
| 35 | |
|---|
| 36 | d['announce-list'] = [ [tracker1], [backup1], [backup2] ] |
|---|
| 37 | |
|---|
| 38 | On each announce, first try tracker1, then if that cannot be reached, |
|---|
| 39 | try backup1 and backup2 respectively. On the next announce, repeat |
|---|
| 40 | in the same order. This is meant for when the trackers are standard |
|---|
| 41 | and can not share information. |
|---|
| 42 | |
|---|
| 43 | d['announce-list'] = [[ tracker1, tracker2, tracker3 ]] |
|---|
| 44 | |
|---|
| 45 | First, shuffle the list. (For argument's sake, we'll say the list |
|---|
| 46 | has already been shuffled.) Then, if tracker1 cannot be reached, try |
|---|
| 47 | tracker2. If tracker2 can be reached, the list is now: |
|---|
| 48 | tracker2,tracker1,tracker3. From then on, this will be the order the |
|---|
| 49 | client tries. If later neither tracker2 nor tracker1 can be reached, |
|---|
| 50 | but tracker3 responds, then the list will be changed to: |
|---|
| 51 | tracker3,tracker2,tracker1, and will be tried in that order in the |
|---|
| 52 | future. This form is meant for trackers which can trade peer |
|---|
| 53 | information and will cause the clients to help balance the load |
|---|
| 54 | between the trackers. |
|---|
| 55 | |
|---|
| 56 | d['announce-list'] = [ [ tracker1, tracker2 ], [backup1] ] |
|---|
| 57 | |
|---|
| 58 | The first tier, consisting of tracker1 and tracker2, is shuffled. |
|---|
| 59 | Both trackers 1 and 2 will be tried on each announce (though perhaps |
|---|
| 60 | in varying order) before the client tries to reach backup1. |
|---|
