This article describes the known uses and allocation of bits in the BitTorrent protocol, as well as message identifiers.
Reserved Bit Allocation
Some binary bits reserved for possible future needs. These bits are not used in the current version of the protocol, but are reserved for future extensions to ensure backward compatibility without breaking existing systems. Reserved bit allocation is typically used in specific fields of the protocol, such as IP headers, TCP headers, and UDP headers. These bits can be used for future updates to the standard, allowing any future specifications or protocols to use them without changing the existing protocol. By using reserved bit allocation, protocol designers can ensure that the protocol remains backward compatible when it is expanded in the future, without breaking the functionality of existing systems.
reserved[0] ("reserved[0]" refers to a reserved field in the BitTorrent protocol message, with an original value of 0. This field is typically used for protocol extensions and updates to add new features or modify existing ones. The same applies to the following.)
0x80 Azureus Messaging Protocol (Azureus Messaging Protocol is a communication protocol related to the BitTorrent protocol, used to exchange information and data in P2P networks. Azureus is a popular BitTorrent client software that used its own communication protocol, Azureus Messaging Protocol, in its early versions to enable interaction and control between peer nodes. Azureus Messaging Protocol is commonly used to support BitTorrent-related features such as streaming downloads and torrent file sharing, as well as communication and collaboration between clients. Although Azureus Messaging Protocol has been replaced by many modern BitTorrent clients, it remains an important part of the BitTorrent technology development process.)
reserved[2]
0x08 BitTorrent Location-aware Protocol (no known implementations) (BitTorrent Location-aware Protocol (BLP) is an extension of the BitTorrent protocol designed to allow better download performance and load balancing. This protocol uses IP addresses to determine the physical location of each peer and selects the best sources based on distance. However, there are currently no known clients that use this protocol.)
reserved[5]
0x10 LTEP (Libtorrent Extension Protocol) (Libtorrent Extension Protocol (LTEP) is an extension protocol used by the libtorrent library, which enables BitTorrent clients to send and receive extension messages not defined in the original BitTorrent protocol specification. These extension messages can be used for various purposes, such as adding new features or improving the performance of BitTorrent clients.)
0x02 Extension Negotiation Protocol
0x01 Extension Negotiation Protocol (0x02 and 0x01 both represent the Extension Negotiation Protocol code. The Extension Negotiation Protocol is part of the BitTorrent protocol and is used to exchange supported protocol extensions between peers during protocol handshaking. When two peers establish a connection, they send messages containing the extensions they support. These extensions can be standard extensions like ut_metadata and ut_holepunch, or custom extensions specific to clients or applications. By using the Extension Negotiation Protocol, peers can negotiate and enable mutually supported extensions, thereby improving download efficiency and functionality.)
reserved[7]
0x01 BitTorrent DHT (0x01 represents support for BitTorrent Distributed Hash Table (DHT), which allows BitTorrent clients to find and communicate with other clients without a tracker.)
0x02 XBT Peer Exchange (0x02 represents support for XBT Peer Exchange, a P2P network protocol that optimizes tracker network load.)
0x04 suggest, haveall, havenone, reject request, and allow fast extensions (0x04 represents support for suggest, haveall, havenone, reject request, and allow fast extensions. These features can improve download efficiency, such as by sending haveall and havenone messages to inform peers about the blocks it has or does not have.)
0x08 NAT Traversal (0x08 represents support for NAT Traversal extension, which allows BitTorrent clients to connect to other clients using NAT network traversal techniques.)
0x10 hybrid torrent legacy to v2 upgrade (0x10 represents support for hybrid torrent legacy to v2 upgrade extension, which allows seamless collaboration between old and new versions of BitTorrent clients.)
Known Hash Collisions:
A hash collision occurs when two different inputs produce the same output in a hash function. The purpose of a hash function is to map data of arbitrary length to a fixed-size output. However, due to the uncertainty of inputs and the limited output space, some inputs may produce the same output. Hash functions are typically designed to have high randomness and complexity, making the probability of hash collisions very low and negligible. However, in some cases, attackers may exploit hash collisions for malicious purposes, such as forging digital signatures, performing replay attacks, or cracking passwords.
reserved[0]
0xFF BitComet Extension Protocol
reserved[1]
0xFF BitComet Extension Protocol (0xFF is a byte identifier in the BitComet Extension Protocol used to identify handshake messages of the protocol. This protocol is a special extension protocol on the BitTorrent network that adds new features to the original BitTorrent protocol to provide more efficient and reliable transmission services.)
reserved[7]
0x01 XBT Metadata Exchange (implemented only in XBT)
XBT Metadata Exchange protocol allows clients to obtain metadata information from other clients through the Tracker server without downloading the complete torrent file. This can improve download efficiency and save bandwidth in certain cases. When an XBT client connects to an XBTIT Tracker, it can send a handshake message to the Tracker indicating support for XBT Metadata Exchange, with reserved[7] set to 0x01. If the Tracker supports XBT Metadata Exchange, it will indicate it in the reply handshake message. After that, the client can obtain metadata information from other clients supporting XBT Metadata Exchange through the Tracker.
"Extension Protocol," also known as LibTorrent Extension Protocol (LTEP), is the recommended method for further extending the BitTorrent protocol. LTEP provides a standardized mechanism for adding new features to the protocol without causing conflicts with bits or message IDs. LTEP offers a more powerful and reliable way to extend the BitTorrent protocol and is recommended for developers who want to add new features to the protocol.
With LTEP, extension bit collisions become impossible because no new extension bits are allocated. Instead, all extensions are negotiated and assigned unique identifiers at the beginning of the connection. This ensures that each extension has a unique identifier that does not conflict with other extensions. Similarly, message ID collisions become impossible when using LTEP because message IDs are assigned on-demand at the beginning of the connection. This means that each message type has a unique ID that does not conflict with other message types. Although extension name collisions are still possible when using LTEP, the probability of collisions is much lower compared to previous methods. This is because all extensions are registered and tracked by the BitTorrent community, helping to ensure that new extensions do not conflict with existing ones.
Reserved Message IDs
Core Protocol:
0x00 choke
0x01 unchoke
0x02 interested
0x03 not interested
0x04 have
0x05 bitfield
0x06 request
0x07 piece
0x08 cancel
choke and unchoke are used to control upload bandwidth. When a peer chokes another peer, it tells it to stop sending any data. When unchoked, it allows the other peer to download data.
interested and not interested are used to indicate whether a peer is interested in the data owned by another peer.
have and bitfield are used to describe the data a peer already has, so that other peers can know what data they need.
request and piece are used for actual data transfer. Request contains the index and length of the desired data block, while Piece contains the actual data.
cancel allows canceling previously sent requests, which helps manage network traffic better.
DHT Extension:
0x09 port
port is used for DHT extension to expose the port number to other peers.
Fast Extension:
0x0D suggest
0x0E have all
0x0F have none
0x10 reject request
0x11 allowed fast
suggest, have all, have none, reject request, and allowed fast are all part of the Fast extension, which can improve download speed.
Additional IDs used in deployed clients:
0x14 LTEP Handshake (implemented in libtorrent, uTorrent,...)
LTEP Handshake is a handshake protocol implemented in clients such as libtorrent and uTorrent, used to perform necessary steps before starting the download.
Hash Transfer Protocol:
0x15 hash request
0x16 hashes
0x17 hash reject
hash request, hashes, and hash reject are part of the Hash Transfer Protocol, used to exchange hash values between peers to verify the integrity of shared files.
Reference links: