Home > Specs > BitTorrent > Peer Connections
Block Requests
If a peer is interested in the remote peer, and not choked by the remote peer, it can request 16 KB (16384 bytes) blocks from the remote peer using the block request message. Requests received from a
choked peer are rejected. Requests received from an
uninterested peer are rejected.
A block request message starts with the message type 6 (one byte), and is followed by a four-byte big-endian integer that is the piece index, then a four-byte big-endian integer that is the offset into that piece (in bytes), and then a four-byte big-endian integer that is the length of the desired block.
Some clients will reject requests that aren't on even 16 KB boundaries. The length of the request should always be 16 KB unless it is the last block of the last piece in the torrent.
A pending request can be cancelled by the originator. This is done with a request cancel message. It starts with the message type 8 (one byte) and is followed by the same three integers that were in the original request.
A request should never be silently dropped, even if it is received from a remote peer that is choked or not interested. All requests must be eventually responded to, in order, with either a block data message, or a rejection.
A block data message starts with the message type 7 (one byte), and is followed by the same set of three four-byte big-endian integers from the request (piece index, block offset, block length), then the actual block data is appended.
A rejection message starts with the message type 16 (one byte), and is followed by the same set of three four-byte big-endian integers from the request (piece index, block offset, block length).
Rejection messages should not be sent to clients that didn't set the
fast mode bit in the initial handshake flags when this peer connection was first made. This is a very rare occurrence.
Requests can be pipelined. When the connection was made and the
extended handshake map received, there may have been a key
reqq
that specifies the maximum request queue depth of the remote peer. This should be the maximum number of pending requests. If this value is not present, a reasonable default is 100.