Re: Dynamic trackers idea
Gary Fung <[email protected]>
| Newsgroups | gmane.network.bit-torrent.general |
|---|---|
| Message-ID | <[email protected]> |
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 <[email protected]> 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: [email protected] <*> Your use of Yahoo! Groups is subject to: http://docs.yahoo.com/info/terms/