Several independent torrent clients, most notably µTorrent and Azureus, have created “peer exchange” protocols that allow for clientless torrent downloads. By means of the now-standard DHT trackerless peer-exchange format, these clients (and others) communicate with one-another and ask for info about new peers to download from.
Long story short, they let you download torrents with dead/no trackers, and without communicating with a central server. Everyone knows the importance of trackers of course, they provide torrent clients a list of known peers to download from – leechers and seeders alike, as well as track the status of a torrent at any given time. The problem is, they disappear mighty fast.
µTorrent also has another trackerless implementation called “PeerExchange” that does just about the same thing. But why stick to peers? Bittorrent is a centralized protocol. Attempting to convert the bittorrent protocol into a decentralized network isn’t going about things the right way… So here’s an idea: instead of just exchanging peers, why not exchange trackers too?
Say Client A is using µTorrent and is downloading File 1, and has one tracker, and currently has a bunch of peers in its list, one of which is Client B. Client B, also using µTorrent, is connected to a bunch of other peers and two trackers. Using DHT or PeerExchange, Client A can get a partial list of peers from Client B to connect to. Using certain algorithms, Client A communicates with each of these peers in turn and gets a mostly-complete list of peers to download from – at least, that’s the way it’s supposed to work.
But truth be told, DHT/PeerExchange aren’t that great. A torrent (with DHT enabled) without trackers but thousands of peers won’t download anywhere near as fast as a torrent with a tracker that has the same amount of clients registered with it (or even less). So why not exchange tracker lists?
In the example above, when Client A communicates with Client B, it’ll request a list of trackers, not peers. Client B, if it understands the request, will return the tracker(s) it’s using, and Client A will add them to its list. Rinse & Repeat.
This results in smaller overhead, faster downloads, and more static conditions. Peer IP addresses change constantly, trackers don’t. As trackers expire and new ones are introduced, Client A will always have a up-to-date list, and it’ll share it alike. Trading peers is a decentralized way of doing things and has its own advantages, but so long as bittorrent relies on trackers for the original torrent, it’s still a centralized network anyhow.
Just an idea – but one that we’d definitely be interested in seeing. Especially for torrents in the gigabytes, it can take days or weeks to complete a download (especially on lower-end DSL). Having a static tracker instead of dynamic peers is a much more reliable solution.