Peer exchange
This article's tone or style may not reflect the encyclopedic tone used on Wikipedia. (December 2007) |
In BitTorrent file sharing networks Peer Exchange is used to help maintain the swarm of BitTorrent Clients (or [Peer-to-peer|peers]]) that are collaborating to share a given file. In the original BitTorrent design the peers depended on a file's BitTorrent tracker to find and maintain the swarm. Peer Exchange allows the members of the swarm to exchange information about the swarm directly without polling the Tracker. This both is faster and reduces the load on the Tracker.
Peer exchange does not entirely eliminate the need for a tracker since when a peer joins the swarm of a given file for the first time it still must touch base with the tracker to find the swarm. Additionally in some scenarios it is possible for the swarm to split and occasional polling of the tracker(s) will merge it back together.
Clients supporting peer exchange
Each of these clients implement some version of peer exchange:
- Vuze, formerly Azureus, and clients based on it (The Vuze PEX is only compatible with the Transmission client. PEX with other clients has been implemented into Vuze and into Azureus from 3.0.4.3 onwards)
- BitComet[citation needed]
- Bitflu[1]
- BitTorrent[citation needed]
- FlashGet[citation needed]
- KTorrent has implemented full µTorrent PEX support as of 2.1 RC1[2]
- Opera 9.5 - µTorrent PEX support[3]
- qTorrent - µTorrent PEX support
- µTorrent[4]
- libtorrent and clients based on it (Deluge[5], qBittorrent[6], MooPolice[7]) compatible with µTorrent
- rTorrent[8]
- Transmission (compatible with both the μTorrent and Vuze implementations)[9]
- XTorrent being based on Transmission source code, equally fully supports the Vuze and µTorrent implementations as of version 1.0 (v40)[citation needed]
- aria2 - µTorrent PEX support
Implementation
DHT
To create a PEX protocol providing a uniformly distributed peer selection, one could form a small DHT local to a torrent. For each desired new peer one would look up a (uniformly) random key, and use the node responsible for the key as a new peer. This is conceptually simple but would require quite some overhead.
For "trackerless" torrents, it is not clear if PEX provides any value since the mainline DHT can distribute load as necessary. Each DHT node acting as a tracker may store only a subset of the peers, but these are maximal subsets constrained only by DHT node load rather than by a single peer's view. Private torrents disable the DHT, and for this case, PEX might be useful provided the peer obtains enough peers from the tracker.
References
- ^ "Bitflu configuration example". Retrieved 2007-03-30.
- ^ "What's new in 2.1?". KTorrent official website. Retrieved 2007-03-30.
- ^ "Opera 9.5 BitTorrent support". Retrieved 2007-09-04.
- ^ "μTorrent 1.4.1 beta and 1.4.2 beta changes". Retrieved 2007-09-11.
- ^ "Deluge 0.5.1 Beta 1 changes". Retrieved 2007-09-11.
- ^ "qBittorrent official website". Retrieved 2007-05-14.
- ^ "MooPolice official website". Retrieved 2007-03-30.
- ^ "libTorrent 0.11.8 and rTorrent 0.7.8 Changelog". Retrieved 2007-09-11.
- ^ "NEWS (rev 1579)". Transmission SVN. Retrieved 2007-03-30.