How ut_pex Exchanges Peer IP Addresses in BitTorrent

The ut_pex (Peer Exchange) extension enables BitTorrent clients to trade known active IP addresses and port numbers directly with one another, reducing dependency on central trackers and Distributed Hash Tables (DHT). By exchanging compact lists of recently connected and disconnected peers through standard peer-to-peer data connections, ut_pex rapidly accelerates swarm discovery, optimizes routing, and maintains robust mesh connectivity across the network.

Negotiation via the Extension Protocol (BEP 10)

Before any peer exchange occurs, two connected clients must establish that they both support the protocol. BitTorrent handles this using the Extension Protocol (BEP 10):

1. Extension Handshake: Upon initiating a standard BitTorrent handshake, clients set the extension bit in the handshake reserved bytes.
2. ID Mapping: Clients send an extension handshake message containing a bencoded dictionary with an m sub-dictionary. If a client supports Peer Exchange, it advertises a key named ut_pex mapped to a local numeric message ID (e.g., {"m": {"ut_pex": 1}}).
3. Dynamic Routing: Because ID numbers can differ per client, each client uses the recipient’s advertised ID when sending subsequent PEX messages.

Structure of the ut_pex Message

A ut_pex payload is transmitted as a standard BitTorrent extension message (message ID 20 followed by the negotiated ut_pex ID) containing a bencoded dictionary. Instead of verbose text representations, IP addresses are sent in binary compact format:

• added: A binary string of IPv4 addresses and port numbers for newly connected peers. Each peer occupies 6 consecutive bytes (4 bytes for the IPv4 address, followed by 2 bytes for the port in network byte order).
• added.f: A string of bitmask flags corresponding to each peer in added (1 byte per peer). Common flags include 0x01 (peer prefers encryption), 0x02 (peer is a seed/upload-only), and 0x04 (peer supports ut_pex).
• dropped: A 6-byte-per-peer compact binary string of IPv4 peers that the sending client has recently disconnected from or dropped from its routing table.
• added6 and added6.f: The IPv6 equivalents for newly connected peers, where each address and port occupies 18 bytes (16 bytes for IPv6, 2 bytes for port).
• dropped6: An 18-byte-per-peer compact binary string of dropped IPv6 peers.

Direct Exchange Workflow

Once connected and negotiated, the peer exchange operates continuously through a streamlined cycle:

1. Local State Tracking: The client monitors changes in its internal swarm table, noting any newly connected peers or recently severed connections.
2. Rate Limiting: To prevent bandwidth saturation, ut_pex messages are throttled, typically broadcasted no more than once every 60 seconds per peer connection.
3. Differential Updates: Instead of broadcasting the full routing table, the client generates a delta update containing only the peers added or dropped since the previous message.
4. Peer Ingestion: When a client receives a ut_pex message, it parses the compact byte strings, extracts the valid IP/port pairs, filters out already-connected or blacklisted nodes, and attempts direct TCP/uTP connections to the newly discovered addresses.

Torrent Privacy Restrictions

If a torrent’s metainfo file contains the private: 1 flag inside its info dictionary, compliant BitTorrent clients automatically disable ut_pex alongside DHT and Local Peer Discovery (LPD). This enforces that peer acquisition occurs exclusively through authorized private trackers, preventing the unauthorized leakage of peer IP addresses across external networks.