[BitTorrent] Dynamic trackers idea

Harold Feit - Depthstrike.com Administrator dwknight at depthstrike.com
Sun Jan 2 00:24:49 EST 2005

Hash: SHA1

I currently administer a 5-way implementation of a linked tracker
system that uses a persistent connection link to cause common
torrents across the trackers to operate as one unified swarm. In
order to get the most effecitve load balancing and failover, I use a
single-tier multitracker torrent (generated out of a specialized php
script for disk space efficiency and ease of network expansion, since
I only need to modify the configuration file for the script to add an
additional tracker).

I find that using multitracker is much more reliable than using any
DNS-based load balancing since multitracker lets the more powerful
and resiliant trackers handle more peers, and lets any one tracker
have whatever problems, disappear for extended periods, and return,
only requiring an update of the allowed torrents list to include new
torrents from the absence.

The tracker network I currently run was originally formed out of the
connections from 6 volunteers (including me). Of those original 6, 3
of them are still tracking within the confines of the network.

Once a solution for uploading the same torrent to multiple trackers
at the same time has been found (if someone's willing to write one
for the benefit of all who plan to use multitracker, feel free to
contact me directly), I will probably start expanding the network
again. The major slow-down for me currently is authorizing new
torrents across the entire network, since I have to upload them to
each tracker individually.

Multitracker itself has been around for over a full year, and is
quite widely implemented (BitTornado, Azureus and BitComet being
CONFIRMED cores that support it within a reasonable scope of the
specification). I highly endorse its use in the case of people having
multiple trackers who want automated failover.

The following torrent generation utilities are confirmed to support
making torrents in all forms listed in the spec document:
ABC's Integrated Torrent Generator
Azureus' Integrated Torrent Generator
BitComet's Integrated Torrent Generator
BitTornado's btmaketorrentgui.py

The multitracker implementation itself has only a practical
limitation on how many backup/linked trackers are defined in the
torrent. The theoretical limitation is near the upper-limit of the
theoretical size of the .torrent metafile (which is quite large). 


- -----Original Message-----
From: Antonio Augusto [mailto:khaoticmind at gmail.com] 
Sent: Friday, December 31, 2004 11:45 AM
To: BitTorrent at yahoogroups.com
Subject: [BitTorrent] Dynamic trackers idea

Heya guys,

This is my first message to the group, and also my first attempt to
the P2P development world at all. So it might not be as good as I
first though ;)

Any way...
My idea would be to allow trackers to be created dynamically in the
In my idea the .torrent file would be changed to contain up to five
trackers (one main tracker and 4 "backups") and additional space to a
list of known peers (lets say 50 for now). So, once you start the
download it would normally connect to the tracker, and start the
If the first tracker did not work it would try to connect to one of
the backups ones. If it did not found any active tracker it'd start
querying the other peers in the list to which is the actual tracker
for this file (and update the backup list as appropriated).

Now, why would the tracker go down?
Well... for any number of reasons. But the thing is that , once a
tracker goes down the peers would communicate among themselves and
to elect a new tracker. (or maybe more than one to balance the
I'm pretty sure there are some efficient "electing algorithms" out
there. But i didn't look for any right now.

Any ways, when the new tracker is elected the clients would update
they "backup list" to reflect this change on the topology, so new
clients (that downloaded the new .torrent) would be able to connect
even if the original tracker is down, and latter "resumes" would also
use the backup trackers if the original one is down.

One variation on the topic would be to allow the peers to dynamically
change the topology (i.e. find new trackers) randomly, and not only
when a tracker goes down. This could be useful for example, when a
tracker has been chosen (one with low bandwidth), and after that
another peer joined the network, and has better condition to handle
the traffic.
This could also be useful when the network gets to big, so you would
need to redistribute the trackers/create new trackers.

I think that the impact wouldn't be so big for the trackers for a
number of reasons:
1) the tracker elect would host only one file (not thousands of files
like the trackers we have in the current model)
2) the electing algorithm would help to establish that the current
tracker is the one that can best handle the traffic (maybe based on
earlier traffic reports)
3) the elect tracker could have advantages on the queue list of the
peers, so to enable him to achieve better downloads
4) the tracker would change from time to time, so a host wouldn't
to keep with the traffic all the time

this last assumptions are supposing that the trackers/backups would
exchange a list of any needed info periodically.

Well... i think thats it :)
I also thought about the possibility of making it possible to look
a file through the network (no need to have separate websites fr
that), but thats another topic i think :)

So... start the critics (constructive ones please ;)

Yahoo! Groups Links


- -- 
No virus found in this incoming message.
Checked by AVG Anti-Virus.
Version: 7.0.296 / Virus Database: 265.6.7 - Release Date: 12/30/2004

- -- 
No virus found in this outgoing message.
Checked by AVG Anti-Virus.
Version: 7.0.296 / Virus Database: 265.6.7 - Release Date: 12/30/2004

Version: PGP 8.0.3


Yahoo! Groups Links

<*> To visit your group on the web, go to:

<*> To unsubscribe from this group, send an email to:
    BitTorrent-unsubscribe at yahoogroups.com

<*> Your use of Yahoo! Groups is subject to:

More information about the BitTorrent mailing list