Author: Arvid Norberg, arvid@libtorrent.org Ludvig Strigeus, ludde@utorrent.com

extension protocol for bittorrent

The intention of this protocol is to provide a simple and thin transport for extensions to the bittorrent protocol. Supporting this protocol makes it easy to add new extensions without interfering with the standard bittorrent protocol or clients that don't support this extension or the one you want to add.

To advertise to other clients that you support, one bit from the reserved bytes is used.

The bit selected for the extension protocol is bit 20 from the right (counting starts at 0). So (reserved_byte[5] & 0x10) is the expression to use for checking if the client supports extended messaging.

Once support for the protocol is established, the client is supposed to support 1 new message:

name id
extended 20

This message is sent as any other bittorrent message, with a 4 byte length prefix and a single byte identifying the message (the single byte being 20 in this case). At the start of the payload of the message, is a single byte message identifier. This identifier can refer to different extension messages and only one ID is specified, 0. If the ID is 0, the message is a handshake message which is described below. The layout of a general extended message follows (including the message headers used by the bittorrent protocol):

size description
uint32_t length prefi