Please help improve this article or section by expanding it. Further information might be found on the talk page. (January 2007)

The tone or style of this article or section may not be appropriate for Wikipedia. Specific concerns may be found on the talk page. See Wikipedia's guide to writing better articles for suggestions. (December 2007)

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.

[edit] 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^{[citation needed]}
• Bitflu^[1]
• BitTorrent^{[citation needed]}
• Deluge
• 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 Azureus implementations)^[9]
• XTorrent being based on Transmission source code, equally fully supports the Azureus and µTorrent implementations as of version 1.0 (v40)^{[citation needed]}
• aria2 - µTorrent PEX support

[edit] Implementation

[edit] 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. [1]

[edit] 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 protocols 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.

[edit] References

[edit] External links

• Description on the official Azureus wiki