		*Últimos Cambios*
	Blog personal: El hilo del laberinto

[BitTorrent] Support for "announce-list" (Second Round)

Última Actualización: 03 de Noviembre de 2004 - Miércoles

My previous patch to implement the extension "announce-list" had a lot of welcomed comments about the right algorithm to use. At first I thought that such an implementation would need an "in deep" rewrite of the standard BT client, but days later I managed to achieve a decent and fairly non-intrusive version.

The RIGHT algorithm is:

               MULTITRACKER METADATA ENTRY SPECIFICATION
               =========================================

This specification is for John Hoffman's proposed extension to the
BitTorrent metadata format.  This extension is not official as of this
writing.


* "announce-list"

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, 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.


* examples.

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.

d['announce-list'] = [ [ tracker1, tracker2 ], [backup1] ]
  The first tier, consisting of tracker1 and tracker2, is shuffled.
  Both trackers 1 and 2 will be tried on each announce (though perhaps
  in varying order) before the client tries to reach backup1.

This second patch implements the previous algorithm with minimal surgery to the standard BitTorrent client. Some comments, nevertheless:

Current implementation tries to reuse TCP ports when talking to trackers, in order to reduce NAT state if you are running the client behind a NAT server/ADSL, etc. I know it can became an issue under some circunstances, I know :). If you are stressed about this, you can easily remove that "feature" turning the variable "reuse_ports" to "False" at the beginning of "BitTorrent/Rerequester.py".
Standard code uses three threads per torrent. My code uses only two.
The timeout between failed tracker requests is defined by "http_timeout", tipically 60 seconds. If the tracker refuses connections, we tries the next one inmediately.

This patch is distributed AS IS (if it erases your harddisk is your fault, not mine ;-) ) using the original BitTorrent MIT License. I haven't removed the original code, so you can patch your client and enable/disable the new code at will.

Download the patch (20041102-1)
Warning: This patch assumes that you have installed also my previous patch. If not, the patching will fail. You will need to patch "by hand".

Historia

03/Nov/04: Primera versión de esta página.

Más información sobre los OpenBadges

Donación BitCoin: 19niBN42ac2pqDQFx6GJZxry2JQSFvwAfS