{"id":380,"date":"2007-03-06T07:37:38","date_gmt":"2007-03-06T07:37:38","guid":{"rendered":"http:\/\/neosmart.net\/blog\/2007\/what-about-trackerexchange\/"},"modified":"2013-08-26T18:09:15","modified_gmt":"2013-08-26T23:09:15","slug":"what-about-trackerexchange","status":"publish","type":"post","link":"https:\/\/neosmart.net\/blog\/what-about-trackerexchange\/","title":{"rendered":"What about TrackerExchange?"},"content":{"rendered":"

Several independent torrent clients, most notably \u00b5Torrent<\/a> and Azureus<\/a>, 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.\n<\/p>\n

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.\n<\/p>\n

<\/p>\n

\u00b5Torrent also has another trackerless implementation called “PeerExchange” that does just about the same thing. But why stick to peers? Bittorrent is a centralized protocol<\/strong>. Attempting to convert the bittorrent protocol<\/strong> into a decentralized network<\/strong> isn’t going about things the right way… So here’s an idea: instead of just exchanging peers, why not exchange trackers too?\n<\/p>\n

Say Client A is using \u00b5Torrent and is downloading File 1, and has one tracker<\/strong>, and currently has a bunch of peers in its list, one of which is Client B. Client B, also using \u00b5Torrent, is connected to a bunch of other peers and two trackers<\/strong>. Using DHT or PeerExchange, Client A can get a partial list of peers<\/strong> 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.\n<\/p>\n

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<\/strong> 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?\n<\/p>\n

In the example above, when Client A communicates with Client B, it’ll request a list of trackers, not peers<\/strong>. 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.\n<\/p>\n

This results in smaller overhead, faster downloads, and more static conditions<\/strong>. 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.<\/strong>\n<\/p>\n

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<\/strong> instead of dynamic peers<\/strong> is a much more reliable solution.<\/p>\n","protected":false},"excerpt":{"rendered":"

Several independent torrent clients, most notably \u00b5Torrent 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 … Continue reading →<\/span><\/a><\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"jetpack_post_was_ever_published":false,"_jetpack_newsletter_access":"","_jetpack_dont_email_post_to_subs":false,"_jetpack_newsletter_tier_id":0,"_jetpack_memberships_contains_paywalled_content":false,"_jetpack_memberships_contains_paid_content":false,"footnotes":""},"categories":[1],"tags":[273,274,272,275],"class_list":["post-380","post","type-post","status-publish","format-standard","hentry","category-software","tag-u2torrent","tag-azureus","tag-bittorrent","tag-network-protocols"],"aioseo_notices":[],"jetpack_featured_media_url":"","jetpack_shortlink":"https:\/\/wp.me\/p4xDa-68","jetpack_sharing_enabled":true,"_links":{"self":[{"href":"https:\/\/neosmart.net\/blog\/wp-json\/wp\/v2\/posts\/380","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/neosmart.net\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/neosmart.net\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/neosmart.net\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/neosmart.net\/blog\/wp-json\/wp\/v2\/comments?post=380"}],"version-history":[{"count":1,"href":"https:\/\/neosmart.net\/blog\/wp-json\/wp\/v2\/posts\/380\/revisions"}],"predecessor-version":[{"id":1915,"href":"https:\/\/neosmart.net\/blog\/wp-json\/wp\/v2\/posts\/380\/revisions\/1915"}],"wp:attachment":[{"href":"https:\/\/neosmart.net\/blog\/wp-json\/wp\/v2\/media?parent=380"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/neosmart.net\/blog\/wp-json\/wp\/v2\/categories?post=380"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/neosmart.net\/blog\/wp-json\/wp\/v2\/tags?post=380"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}