Home > Specs > BitTorrent
Info
The torrent info is a map structure that contains all the information needed to layout and hash-check the output files. It is sometimes referred to as the "info-dict" or "info-key".
The SHA-1 hash of the
BEncoded representation of this structure is used as the main identity of the torrent. This is known as the "info hash", and is used when connecting to trackers, the DHT, and other peers. Any changes to the torrent info will also change it's info hash, making it a completely different torrent.
The info is obtained either directly from a
.torrent file under the BEncoded "info" key, or downloaded directly from peers that can be obtained from the DHT using just the info-hash from a
magnet link.
The following keys are used in the torrent info:
name
This is the name of torrent. If it is a single-file torrent, this is the file name. If it is a multi-file torrent, this is the name of the outermost folder, and there will be a
files section in the info (see below).
length
If this is a single-file torrent, this is the number of bytes in the single file. Multi-file torrents do not need this key.
files
This key is present only in multi-file torrents. It contains a list of maps, one for each file.
Each file map contains the following keys:
path
This is a list of strings representing the file's path. The path should be carefully sanitized before using it to create local files.
length
This is the file length as an integer. Zero-length files will be encountered in the wild.
attr
This is often omitted. It is a string that contains single letter-codes mapping to file attributes. The only one that is important is "p", which indicates a
padding file.
piece length
This defines the smallest unit of file data that is verifiable by hashing. It is usually between 32 KB and several MB. It should be a power of 2, but torrents do exist where that is not the case.
pieces
This is a string that is the concatenation of all the SHA-1 piece hashes in the torrent.
Multiple files are covered by the piece hashes in order, without gaps. Most files will not fall evenly on piece boundaries. This also means that some pieces may cover more than one file.
The last piece may be shorter than the rest. When hashing, it should not be padded.
