[BitTorrent] Dynamic trackers idea

Gary Fung gary at isohunt.com
Sat Jan 1 22:39:28 EST 2005


Multitracker spec is here for a long time and is quite widely used:

http://bittornado.com/docs/multitracker-spec.txt

My BTHub project modifies torrents to add additional trackers using the multitracker spec, with the bthub.com DNS redirecting to optimal trackers based on info_hash. I just posted sample code in PHP that I use for modifying torrents to use the bthub dns:

http://isohunt.com/forum/viewtopic.php?t=746


On Fri, 31 Dec 2004 15:44:34 +0000, Antonio Augusto <khaoticmind at gmail.com> wrote:

>
>
> 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
> network.
> 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
> download.
> 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 try
> to elect a new tracker. (or maybe more than one to balance the traffic).
> 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 bad
> 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 need
> 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 for
> 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
>
>
>
>
>
>
>
>



-- 
Cheers,
Gary


 
Yahoo! Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/BitTorrent/

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

<*> Your use of Yahoo! Groups is subject to:
    http://docs.yahoo.com/info/terms/
 





More information about the BitTorrent mailing list