In a torrent with a deep directory structure (or just directories with long names), those directory names will be duplicated multiple time, exacerbating the problem. In v1 torrents, file lists are expressed as a single list of files with full paths. The exceptions are torrents with a lot of small files then it’s the file list that use the most space. directory structureĪs mentioned earlier, most of the time the piece-hashes take up the majority of space in the info-dictionary. This addresses a long-standing wish to more easily identify duplicate files, or finding multiple sources for files, across swarms. All files will be aligned to pieces, which means there are implicit pad files after each file.Files that are identical can also more easily be identified across different swarms, since their root hash only depends on the content of the file. Identical files will always have the same hash and can more easily be moved from one torrent to another (when creating torrents) without having to re-hash anything.torrent file size is not smaller for a v2 torrent, since it still contains the piece hashes, but the info-dictionary is, which is the part needed for magnet links to start downloading.Įxample tree for a file with 4 blocks and a piece size of 32 kiB (2 blocks per piece) per-file hash treesīitTorrent v2 not only uses a hash tree, but it forms a hash tree for every file in the torrent. This helps distributing and storing the hashes so they don’t have to be recomputed when restarting a client that’s seeding. torrent file must still contain these piece hashes (really the hashes in the merkle tree representing the piece-level). However, instead of piece hashes actually being the hash of the content of the piece, it’s the root of the hash tree of the piece. The concept of piece size still exists and is still used in the peer-wire protocol as it is today. The leaves of the hash trees are always 16 kiB (the block size), regardless of the piece size. This is a great improvement over the heuristics necessary to identify the bad peer in v1, sometimes referred to as smart-ban. The peer that sent the corrupt data can also be identified with certainty. Meaning if a peer sends corrupt data, it can be discovered immediately and only 16 kiB need to be re-downloaded. Downloaded data can be validated on a block level.This shaves off start-up latency when adding a magnet link, since fewer bytes need to be downloaded before the torrent download itself can start. The torrent metadata (specifically the info-dictionary portion of a.BitTorrent v2 uses merkle hash trees for pieces (but a different protocol that the one tribler implemented). torrent files small because all you need is the root hash of the tree. A consequence of large piece sizes is that if a hash fails, one has to re-download a larger portion of the file, until the piece passes the hash check.Īn old idea to improve both of these metrics is to use merkle hash trees to represent the piece hashes (originally implemented in tribler). torrent file size within reason for large files, the piece size can be increased, meaning each hash represents a larger portion of the file. In most cases, the piece hashes is the bulk of the size of. torrent file/metadata (in the info-dictionary). In BitTorrent v1, pieces are hashed and the resulting hashes are included in the. More on this later, under backwards compatibility. It means that fundamentally a v2 torrent will be identified by a different hash than a v1 torrent, which would always create a separate swarm, even when sharing the same files. This was one of the original rationales for creating a v2 protocol to begin with. To handle this, DHT- and tracker announces and lookups for v2 torrents use the SHA-256 info-hash truncated to 20 bytes. In BitTorrent v2, the info-dictionary is also computed by SHA-256, which poses a compatibility challenge with the DHT and trackers, which have protocols that expect 20 byte hashes. One consequence of this is that hashes are 32 bytes instead of 20 bytes. The hash function for piece data was changed to SHA-256. This post describes the new features of the BitTorrent v2 protocol. Given a new hash function would not be backwards compatible, a few other changes were proposed as well, while we were taking the compatibility hit anyway. What is BitTorrent v2?īitTorrent v2 kick-started with an effort to transition away from SHA-1 as the hash function for pieces, shortly after google announced having produced a collision. BiglyBT also has an implementation of BitTorrent v2 to be released in the near future. The libtorrent support for bittorrent v2 was mostly implemented by Steven Siloti. Most of the specification work of BEP 52 was done by the8472. One of them is support for BitTorrent v2. Libtorrent-2.0 has just been released with a few major new features.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |