Home > Specs > BitTorrent > Peer Connections
Info Download

If the torrent was created from a magnet link, it will not have the torrent's "info", which is a map structure that includes file layout and piece hashes.

The info can be downloaded from other peers in BEncoded form, in 16 KB (16384 bytes) chunks.


First, the length of the expected data is determined by the metadata_size value in the extended handshake received earlier.

Chunks of 16 KB can then be requested from other peers using the ut_metadata extension message, if it is supported.

The request message starts with the message type 20 (one byte), and then the message sub-type (one byte) for ut_metadata that was specified in the initial extended handshake at the beginning of the connection.  After that, a BEncoded map with the following two keys:

msg_type
The value of this key is an integer.  For a request, it should be set to 0.

piece
This is the index of the 16 KB chunk that is being requested.


A response message starts with the message type 20 (one byte), and then the message sub-type (one byte) for ut_metadata that was specified by the local peer in the initial extended handshake at the beginning of the connection.  After that, a BEncoded map with the following keys:

msg_type
The value of this key is an integer.  For a successful response, it is set to 1.  For a failure, it is set to 2.

piece
This is the index of the 16 KB chunk.

total_size
This is the total bytes in the BEncoded info map.  It should match the metadata_size key from the initial extended handshake.  This key will probably not be present if this is a failure response.

If this was a successful response, the chunk data will immediately follow the map.  If it is the last piece, it will probably be shorter than 16 KB.


When all the torrent info chunks have been gathered collectively from any number of peers, they should be concatenated and hashed.  The hash is compared against the known torrent info-hash that was in the magnet link used to create this torrent.  If they do not match, a process of elimination can identify the peer that submitted bad data.  This is done by downloading the same chunks from multiple peers until we can find a combination of chunks that does match the desired hash, and then comparing the known-good chunks against the chunks that each peer had submitted earlier.