IMFile

Peer Exchange (PEX) provides an alternative node discovery mechanism for swarms. Nodes are guided through DHT or Tracker announces to complete the process.

It provides a more real-time swarm view than most other sources and reduces the need for frequent querying of other sources.

When used in conjunction with the specification node priority, it provides a method for quickly randomizing the swarm connection graph.

Protocol Extension#

PEX introduces a new message, ut_pex, through the extension protocol.

The message added during the handshake is negotiated as follows:

      {
        m: {
          ut_pex: <implementation-dependent local message ID (positive integer)>,
          ...
        },
        ...
      }

The extension message itself consists of the BitTorrent/extension message header and the subsequent bencoded encoded payload:

  {
    added: <one or more contacts in IPv4 compact format (string)>
    added.f: <optional, bit-flags, 1 byte per added IPv4 peer (string)>
    added6: <one or more contacts in IPv6 compact format (string)>,
    added6.f: <optional, bit-flags, 1 byte per added IPv6 peer (string)>,
    dropped: <one or more contacts in IPv6 compact format (string)>,
    dropped6: <one or more contacts in IPv6 compact format (string)>
  }

The flag definitions are as follows:

A node should only be included in the "added" field after a successful connection, and it should be included in the "dropped" field after it disconnects. Once a node has been added, the client must ensure to send the corresponding "dropped" event at the appropriate time. It is not compliant behavior to only send an "added" signal to other nodes without performing the "dropped" operation.

Reason 1: PEX aims to reflect the nodes currently connected to the client, ensuring that PEX provides more real-time information than other node discovery mechanisms. Reason 2: Only propagating verified nodes can reduce the opportunity for attackers to abuse BitTorrent swarms for distributed denial-of-service attacks.

Clients communicating with each other should limit their bulk update frequency to once per minute.

There is no need to immediately send PEX messages after the handshake. For example, during torrent startup, a client may wait until it has established enough connections to make the sent PEX messages valuable.

The added or dropped contacts should not contain duplicates.

Temporary connection-disconnection or disconnection-reconnection events can be omitted between update messages as long as they do not affect correctness.

Implementation note: For each connected node, a simple approach is to queue its unsent connection-disconnection events and ignore duplicate and transient connections when generating messages. Another more memory-efficient approach is to record a timeline of connection-disconnection events for each torrent and store a pointer for each node pointing to the timestamp of the sent event. When creating a PEX message, simply advance the pointer, taking care to eliminate duplicates and omit transient connections.

Already added contacts should not be removed within the same message.

Except for the initial PEX message, the total sum of added IPv4/IPv6 contacts should not exceed 50 entries. This also applies to dropped entries.

The message must include at least one of the following fields: added, added6, dropped, dropped6.

Clients may disconnect nodes that seriously violate these constraints.

Filling underutilized lists
Containing the following combinations:

• Meeting network connection requirements
• Disconnecting from other peer nodes while seeding
• Disconnecting duplicate nodes based on the same node ID between IPv4 and IPv6

May result in underutilized added or added6 lists. Using the PEX protocol may result in too few connected nodes in the torrent list. If a seed node has no connected nodes to propagate, while other nodes only have connected nodes that can be propagated to other seed nodes, the effectiveness of PEX will be greatly reduced, resulting in too few connected nodes in the torrent list. In seed swarms dominated by IPv4, a similar problem can occur where obtaining IPv6 connected nodes is difficult because IPv6 connected nodes are considered duplicates of already established IPv4 connections, preventing them from being propagated through PEX.

To address this issue, the BitTorrent protocol specifies an "activity requirement" to determine when a connection should be considered inactive and terminated. However, in certain cases, this activity requirement is relaxed if a client has fewer than 25 clients connected to a specific address series (e.g., IPv4 or IPv6). Instead, the client can maintain a list of up to 25 recently established and fully handshaked connections for that address series and record any reasons for disconnection. These reasons make the remote contact eligible to be included in the "added" or "added6" lists. These lists can be referred to as trusted or allowed remote hosts for a given address series. By maintaining a list of recently connected nodes and recording reasons for disconnection, the client can better manage its connections and ensure it stays connected to reliable and stable nodes in the network:

• The same node ID is connected in different address series
• Two peer nodes are unable or unwilling to establish a connection with each other to exchange shared file pieces
• Local resource limitations, such as exceeding the limit of global connections

PEX messages need to remove contacts from the "recently seen list" when including recently disconnected contacts so that they are not sent again in the next message. When the list is repopulated through transient connection-disconnection events, these events may be included in the next message if all necessary conditions are met. In other words, while populating the initial PEX message from the "recently seen list," the client can also skip certain connection-disconnection events to build the PEX message more efficiently. In simple terms, when a node disconnects from other peer nodes, it will be removed and no longer included in the next PEX message from that node. However, if the node reconnects to the network and meets certain conditions, it may appear again in the node's PEX message. Additionally, the client can also skip unnecessary connection and disconnection events to build the PEX message more efficiently.

Recently seen contacts are not necessarily currently ongoing connections, so they need to be removed in the next PEX message.

Adding and deleting the same address in the same PEX message should still be restricted.

The requirement of having fewer than 25 active connections and no more than 25 recently seen contacts is to ensure that at most two PEX messages with droppable contacts can accumulate and only send the old information when there are not enough active contacts to fill the PEX message.

Please note that this exemption rule can be applied separately to IPv4 and IPv6. Even if there are enough IPv4 active connections, if the number of IPv6-related lists is insufficient, the client can still include recently seen IPv6 contacts in the PEX message, and vice versa.

Security Considerations#

Received PEX messages should be considered untrusted and potentially malicious.
Attackers may attempt to disrupt swarms by flooding false information through collaboration with other nodes or launching distributed denial-of-service attacks (DDoS) by inducing BitTorrent clients to attempt connections to victim IP ranges, causing a sudden increase in network traffic and network congestion.

To mitigate these issues, clients should avoid obtaining all connection candidates from a single PEX source. Duplicate IP addresses (e.g., IP addresses with different ports) should be ignored. Additionally, the specification node priority can help distribute connection attempts across many subnets, reducing the impact on any potential victim subnet.

Summary#

PEX is an extension for the BitTorrent protocol. It extends the node list and enhances network connections by allowing BitTorrent clients to exchange IP addresses and port information of other users they know.

PEX allows clients to communicate directly with other clients and exchange node information. This enables faster discovery and connection to other nodes, speeding up download speeds, reducing the burden on trackers, and improving network reliability and timeliness.

It should be noted that PEX functionality can be disabled or limited as it is not constrained by the BitTorrent protocol specification and may cause issues such as fake node attacks and privacy leaks. Therefore, when using PEX, security and privacy considerations should be taken into account and configured and adjusted according to specific circumstances.

Reference Links#

• http://www.bittorrent.org/beps/bep_0011.html
• https://en.wikipedia.org/wiki/Peer_exchange