[BitTorrent] Dynamic trackers idea

Antonio \"KhaoticMind\" Augusto khaoticmind at gmail.com
Tue Jan 4 04:46:16 EST 2005


Hey guys,

I think that you didn't get very well my idea.
I know that multiple trackers have been around for some time, but my
idea is to make them dynamic, i.e. created on demand, exactly to avoid
"problems" like the one Harold is having.

Actually i've been reading a bit more and discovered that this would
eb the same idea that is behind fastracks' Supernodes.


On Sun, 2 Jan 2005 01:24:49 -0400, Harold Feit - Depthstrike.com
Administrator <dwknight at depthstrike.com> wrote:
> 
> 
> -----BEGIN PGP SIGNED MESSAGE-----
> 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).
> 
> http://bittornado.com/docs/multitracker-spec.txt
> 
> - -----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
> 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
> 
> 
> - --
> 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
> 
> -----BEGIN PGP SIGNATURE-----
> Version: PGP 8.0.3
> 
> iQEVAwUBQdeFoF8nceBm0DUaAQIqWwf6ApIYfIVkUMjlbh31pEcYWCbZiwipa1Ab
> XKaz3Lr/FfTMAP54R8obqT4CJrLf/c3DGUuw7Qgesha8r9o87OLldd0jJ+HQb4VH
> UTiM5AKJQd+KFZeYwJ9mwVUV55sK7y1lhRHJsaKfxinwot453sdptkv6bxlMU477
> S//+C80sKegM+8j5Psx6bDOqRsQfyngttiHWa0PXpuEeKbzO6Bz59bZDYCSBD+ub
> tYXXQuZdhJFQ8ElJ9JPelCH25/LgYu1bOEsEgEnN8sz+zQHo3jLstHC3XEMb/x+g
> TIzjcFRnl6TtU2UuTsWGNGFGG4Vp3WTGY8HLAEdBh8bGZhzYPASuDQ==
> =UvSv
> -----END PGP SIGNATURE-----
> 
> 
> Yahoo! Groups Links
> 
> 
> 
> 
> 


-- 
KhaoticMind
TD of Scripting in ClanUED
http://sv4.3dbuzz.com/clanUED

"Things are like they are because that's how they are suposed to be."


 
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