- Peer exchange
Peer exchange (PEX) is a feature of the BitTorrent
peer-to-peer protocol which, like trackers and DHT, can be utilized to gather peers. Using peer exchange, an existing peer is used to trade the information required to find and connect to additional peers. While it may improve (local) performance and robustness—e.g. if a tracker is slow or even down—heavy reliance on PEX can lead to the formation of groups of peers who tend to only share information with each other, which may yield slow propagation of data through the network, due to the few peers sending information to those outside the group they are in.Clients supporting peer exchange
Each of these clients implement an incompatible 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 Fact|date=March 2007
*Bitflu [cite web | title=Bitflu configuration example | url=http://bitflu.workaround.ch/config.html | accessdate=2007-03-30 ]
*BitTorrentFact|date=March 2007
*Deluge
*FlashGet Fact|date=March 2007
*KTorrent has implemented full µTorrent PEX support as of 2.1 RC1 [cite web | title=What's new in 2.1? | publisher=KTorrent official website | url=http://ktorrent.org/ | accessdate=2007-03-30 ]
*Opera 9.5 - µTorrent PEX support [cite web | title=Opera 9.5 BitTorrent support | url=http://my.opera.com/mitchman2/blog/2007/09/04/opera-9-5-alpha-and-bittorrent | accessdate=2007-09-04 ]
*qTorrent - µTorrent PEX support
*µTorrent [cite web | title=μTorrent 1.4.1 beta and 1.4.2 beta changes | url=http://forum.utorrent.com/viewtopic.php?pid=46921#p46921 | accessdate=2007-09-11 ]
*libtorrent and clients based on it (Deluge [cite web | title=Deluge 0.5.1 Beta 1 changes | url=http://forum.deluge-torrent.org/viewtopic.php?f=14&t=15#p33 | accessdate=2007-09-11 ] ,qBittorrent [cite web | title=qBittorrent official website | url=http://qbittorrent.sourceforge.net/ | accessdate=2007-05-14 ] ,MooPolice [cite web | title=MooPolice official website | url=http://www.moopolice.de/ | accessdate=2007-03-30 ] ) compatible withµTorrent
*rTorrent [cite web | title=libTorrent 0.11.8 and rTorrent 0.7.8 Changelog | url=http://rakshasa.no/pipermail/libtorrent-devel/2007-September/001241.html | accessdate=2007-09-11 ]
*Transmission (compatible with both the μTorrent and Azureus implementations) [cite web | title=NEWS (rev 1579) | publisher=Transmission SVN | url=http://transmission.m0k.org/trac/browser/trunk/NEWS?rev=1579 | accessdate=2007-03-30 ]
*XTorrent being based on Transmission source code, equally fully supports the Azureus and µTorrent implementations as of version 1.0 (v40)Fact|date=April 2007
*aria2 - µTorrent PEX supportImplementation
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. [http://dosirrah.livejournal.com/995.html]
Criticism
The main value of PEX is in its ability to reduce load on the tracker by having peers gossip. Unfortunately when there is high
churn rate ,gossip protocol s tend to result in disconnected subgraphs. This is easy to demonstrate: if a particular peer P is an articulation point, the removal of P results in two subgraphs disconnected from each other. No amount of gossiping between peers in each subgraph will enable the two subgraphs to rejoin. For this reason, careful PEX implementation to prefer peer lists from trackers is strongly encouraged.For example, if "k" connections are maintained to peers randomly drawn from the entire set of peers engaged in the torrent then the probability of maintaining connectedness rapidly approaches 1 as "k" increases. Thus the minimal number plus a safety factor to maintain a high probability of connectivity could be obtained from the tracker and the remaining from PEX.
References
External links
* [http://azureus.aelitis.com/wiki/index.php/Peer_Exchange Description on the official Azureus wiki]
Wikimedia Foundation. 2010.