BitTorrent Extension Protocol Handshake Signaling

In the BitTorrent network, peers signal their capability to support the BitTorrent Extension Protocol (BEP 10) during the initial peer-to-peer connection. This article explains the exact mechanism used to advertise this capability, focusing on the manipulation of the reserved byte field within the standard BitTorrent handshake and the subsequent exchange of extension metadata.

The BitTorrent Handshake Structure

When two BitTorrent clients establish a TCP connection, they immediately exchange a 68-byte handshake packet. The standard handshake payload is structured as follows:

1. Protocol Length (pstrlen): A single byte with a value of 19.
2. Protocol Identifier (pstr): The 19-byte string "BitTorrent protocol".
3. Reserved Bytes (reserved): 8 bytes (64 bits) used to signal support for protocol extensions.
4. Info Hash (info_hash): The 20-byte SHA-1 hash of the torrent’s metadata.
5. Peer ID (peer_id): A 20-byte identifier unique to the client instance.

Setting the Extension Protocol Bit

To signal support for the BitTorrent Extension Protocol (BEP 10), a client sets a specific flag within the 8-byte Reserved Bytes field of the handshake.

• Target Byte: The 6th byte of the reserved field (index 5 in zero-based indexing).
• Bit Flag: The bitmask 0x10 (the 4th bit from the least significant bit, or the 20th bit from the right across the entire 64-bit reserved field).

When sending the handshake, the client performs a bitwise OR operation on the reserved byte array:

reserved[5] |= 0x10

Establishing Extension Communication

If both connecting peers send a handshake with the 0x10 bit enabled in byte index 5, extension protocol support is mutually confirmed.

Immediately following the handshake, either peer can send standard peer messages as well as the BEP 10 extension message. The extension mechanism operates via message ID 20. The first extension message exchanged is an extended handshake message (ID 0), which carries a bencoded dictionary mapping specific extension names (such as metadata exchange or peer exchange) to dynamic message IDs used for that specific session.