AzureusProtocolSpecs

Original page (broken)

Azureus BitTorrent EXTENDED Protocol This Azureus extension to the BitTorrent protocol is designed as a generic framework for exchanging information (messages) on peer2peer capabilities/features that extend beyond the original BitTorrent specs.

BitTorrent clients wishing to implement enhanced peer2peer capabilities and features with other clients should use this protocol as a standardized way of communicating this information. New features can easily be added, while remaining backwards compatible. The EXTENDED flag bit To indicate the ability to exchange extended information sets, in the initial peer handshake message, the first bit (high bit) of the first reserved byte (big endian, i.e. network order) is set to 1. This is the EXTENDED flag bit. If a client receives a handshake with the EXTENDED bit set, it knows that the other peer can understand BT_EXTENDED_LIST and BT_EXTENDED messages.

1. EXTENDED flag bit = first bit of first reserved byte of handshake

The BT_EXTENDED_LST message Once it has been determined that a peer understands the EXTENDED protocol via its handshake, we send a BT_EXTENDED_LST message back to that peer. (We also expect to receive a similar BT_EXTENDED_LST message from that peer if we sent it a handshake with the EXTENDED bit set.) The message BT_EXTENDED_LST is similar to the standard BitTorrent CHOKE, UNCHOKE, INTERESTED, etc. messages, only BT_EXTENDED_LST has the byte value of 20. The message's payload consists of a single bencoded dictionary of extended capability name (string) -> client-specific message id (integer) pairs. All later BT_EXTENDED messages are keyed to this message id.

1. BT_EXTENDED_LST message = length prefix, then single byte value 20, followed by bencoded dictionary of extended capability name:id pairs
2. Example: int32(length) byte(20) d13:PEER_EXCHANGEi66e12:PEER_MESSAGEi67e22:NEW_INCREDIBLE_FEATUREi68ee

The BT_EXTENDED message Once BT_EXTENDED_LST messages have been exchanged, a client can determine which peer2peer features can compatibly be used. To use an extended capability/feature, or to exchange additional info about such, a client sends (or receives) a BT_EXTENDED message, which has a byte value of 21, prefixed by the message's length, and followed by a payload keyed to the client-specific capability/feature integer id.

1. BT_EXTENDED message = length prefix, then single byte value 21, then extended feature id, then payload
2. Example: int32(length) byte(21) int32(66) d7:PEER_ID20:20_byte_peer_id_here7:PEER_IP14:141.168.99.2149:PEER_PORTi6861ee

• NOTE: The BT_EXTENDED message payload can be either bencoded or raw byte stream, depending on the specific extended feature's implementation preference. However, a bencoded payload is recommended for ease of use.

It is up to the individual extended capability/feature implementer to decide what peer2peer information needs to be exchanged. This EXTENDED protocol simply specifies how that information should be exchanged.