Difference between revisions of "BitTorrentPeerExchangeConventions"

From Theory.org Wiki
Jump to: navigation, search
m (Undo revision 2645 by Encombe (talk))
m (Undo revision 2653 by Domtheo (talk))
Line 1: Line 1:
 
There are two common extension protocols, [http://wiki.vuze.com/w/Azureus_messaging_protocol AZMP] and [http://www.rasterbar.com/products/libtorrent/extension_protocol.html LTEP]. The common peer exchange mechanism on AZMP is [http://wiki.vuze.com/w/Peer_Exchange AZ_PEX] and on LTEP, it is ''ut_pex''.
 
There are two common extension protocols, [http://wiki.vuze.com/w/Azureus_messaging_protocol AZMP] and [http://www.rasterbar.com/products/libtorrent/extension_protocol.html LTEP]. The common peer exchange mechanism on AZMP is [http://wiki.vuze.com/w/Peer_Exchange AZ_PEX] and on LTEP, it is ''ut_pex''.
  
Both types of peer [http://wiki.tcl.tk/299 exchange] sends messages containing a group of "added" peers and "removed" peers - though not necessarily in the same list (''ut_pex'' sends IPv4 and IPv6 peers in different lists).
+
Both types of peer exchange sends messages containing a group of "added" peers and "removed" peers - though not necessarily in the same list (''ut_pex'' sends IPv4 and IPv6 peers in different lists).
  
 
It has been agreed between the Azureus and µTorrent developers that any clients which implement either of the following peer mechanisms try and obey the limits described below when sending PEX messages:
 
It has been agreed between the Azureus and µTorrent developers that any clients which implement either of the following peer mechanisms try and obey the limits described below when sending PEX messages:
Line 7: Line 7:
 
** In the case of ''ut_pex'' where there are different lists for IPv4 and IPv6 added peers, there cannot be more than 50 added peers in total. Same with removed peers.
 
** In the case of ''ut_pex'' where there are different lists for IPv4 and IPv6 added peers, there cannot be more than 50 added peers in total. Same with removed peers.
 
* A peer exchange message should not be sent more frequently than once a minute.
 
* A peer exchange message should not be sent more frequently than once a minute.
[http://www.awanirentcar.com/pricelist Sewa mobil jakarta], [http://www.grosir-kosmetik.com/62-glutera.html Glutera], [http://www.mitracatur.com/product/cotton-bud Cotton bud], [http://www.tokobungasabana.com Toko bunga jakarta], [http://www.tokobungasabana.com Toko bunga online], [http://vamostech.com/gps-tracking Gps tracking]
 
  
 
'''Some clients may choose to enforce these limits and drop connections which don't obey these limits.''' However, there should be some tolerance to clients that send a PEX message just under a minute since the last PEX message.
 
'''Some clients may choose to enforce these limits and drop connections which don't obey these limits.''' However, there should be some tolerance to clients that send a PEX message just under a minute since the last PEX message.

Revision as of 19:04, 14 April 2014

There are two common extension protocols, AZMP and LTEP. The common peer exchange mechanism on AZMP is AZ_PEX and on LTEP, it is ut_pex.

Both types of peer exchange sends messages containing a group of "added" peers and "removed" peers - though not necessarily in the same list (ut_pex sends IPv4 and IPv6 peers in different lists).

It has been agreed between the Azureus and µTorrent developers that any clients which implement either of the following peer mechanisms try and obey the limits described below when sending PEX messages:

  • There should be no more than 50 added peers and 50 removed peers sent in a PEX message (so 100 in total).
    • In the case of ut_pex where there are different lists for IPv4 and IPv6 added peers, there cannot be more than 50 added peers in total. Same with removed peers.
  • A peer exchange message should not be sent more frequently than once a minute.

Some clients may choose to enforce these limits and drop connections which don't obey these limits. However, there should be some tolerance to clients that send a PEX message just under a minute since the last PEX message.