BEP:40
Title:Canonical Peer Priority
Version: 2d59a3b002dd57dc51fb803ce082af4f72d18b82
Last-Modified:Mon Mar 24 17:38:20 2014 -0700
Author: Arvid Norberg <arvid@bittorrent.com>, Chris Brown <cbrown@bittorrent.com>
Status: Draft
Type:Standards Track
Created:8-November-2012
Post-History:29-January-2014 Specify CRC32-C rather than SHA1 hashing, 24-March-2014 fixed typos in test vectors

Abstract

The aim of this bep is to solve two problems with BitTorrent:

  1. The barrier of entry to a swarm may be high when most peers (or at least most early peers with most of the data) are all fully connected at all times, never having a connection slot for new incoming connections. Peers are likely to attempt a new outgoing connection immediately when a peer is dropped, to reach the connection limit. This means that the number of connected peers + half-open outgoing connections always reaches the limit, resulting in new incoming connections being refused.
  2. There's an opportunity to DDoS a swarm by filling up everyone's connections slots, and continuously making incoming connections at such rate that peers won't have an opportunity to connect to anyone else.

The solution to these problems is to come up with a formula that all peers agree on to prioritize certain IP addresses for peers over others. As long as this formula is correctly defined, and all (or at least most) peers agree on what it is, all peers have equal footing on joining swarms, and a DDoS attack is only as affective as the proportion of attackers to legitimate peers.

Examples

If the client is 123.213.32.10 and the peer is 98.76.54.32, the hash that they should both arrive at is crc32-c(624C14007BD50000) or ec2d7224.

If the client is 123.213.32.10 and the peer is 123.213.32.234, the hash that they should both arrive at is crc32-c[(7BD5200A7BD520EA) or 99568189.

Notes

A peer's priority can be computed before connecting, so it may be beneficial for clients to take that into consideration when deciding which peers to connect to.

Prioritization should be used within torrents only (not at a global level). This specification is not intended to influence the method by which peer slots are divided up among torrents.

Google provides a CRC32-C reference implementation.

References

[1]BEP 10: Extension Protocol (http://www.bittorrent.org/beps/bep_0010.html)