BitTorrent protocol specification series-Part 1

Identification
BitTorrent is a peer-to-peer file sharing protocol designed by blem Cohen. This Protocol makes it easier for multiple peers to transmit files through untrusted networks.

Purpose
The purpose of this specification is to introduce in detail the BitTorrent protocol Specification V1.0. Bram protocol specification website http://www.bittorrent.com/protocol.html briefly describes this protocol, in part of the scope of lack of detailed description of behavior. This document is written in clear and clear wording, hoping that it can become a formal specification and, of course, can be used as a basis for future implementation and discussion.

This document is intended to be developed by BitTorrentCommunityMaintenance and use. You are welcome to make contributions to it. The content only represents the current protocol, but it has been used by many existing client implementations.

Application Scope
This document applies to the first version (V1.0) of the BitTorrent protocol specification ). Currently, this document applies to the torrent file structure specification, peer wire protocol specification, and tracker HTTP/HTTPS protocol specification. If a new revision is made to an agreement, go to the corresponding page, instead of here.

(Note: During the translation process of this document, if there are no terms corresponding to the standard translation, such as torrent, peer, tracker, etc)

Conventions
Many conventions are used in this document to express information in a concise and accurate manner.

Peer v/s client: In this document, a peer can be any BitTorrent client involved in download. The client is also a peer, although the BitTorrent client runs on a local machine. Readers of this specification may think that they are connected to many peer clients.
Piece (piece) v/s block: In this document, a piece refers to a part of downloaded data described in the metainfo file, it can be verified by SHA-1 hash. A block is a part of the data that the client requests to the peer. Two or more parts form a complete piece that can be verified.
Defacto standard: italic text indicates that a rule is so common in many different BitTorrent client implementations that the rule is treated as an actual standard.
(Note: Peer translation is generally 'terminal', So P2P should be translated into peer-to-peer, but there is no standard translation method. Therefore, it is not translated in this article, at the same time, the reader should distinguish peer-to-peer from the Point-to-Point Protocol on the data link layer (also abbreviated as P2P)

B encoding (bencoding)
B encoding is a simple way to describe and organize data. The following types are supported: byte string, integer, lists, and dictionaries.

Byte string
The Byte string is encoded as follows: <length of a string encoded in ASCII format >:< string data>
Note: The Byte string encoding does not start or end with a separator.

Example: 4: Spam indicates the byte string "spam"

Integer
Integers are encoded as follows: I <an integer encoded in ASCII format> E
The START "I" and the end "E" are the start and end separators respectively. Negative numbers such as i-3e can be used. However, you cannot put "0" in front of a number, such as "i04e ". In addition, "i0e" is valid.
For example, "i3e" indicates the integer "3"

Note: The maximum number of digits of this integer is not specified)

Lists
Lists is encoded as follows: L <B encoding value> E
The START separator "L" (L is lower-case l, rather than upper-case I) and the end separator "E" are respectively the start and end separators. Lists can contain any B-encoded type, including integers, strings, dictionaries, and other lists.
For example, L4: spam4: eggse indicates the lists containing two strings: ["spam", "eggs"]

Dictionaries
Dictionaries is encoded as follows: d <B encoding string> <B encoding element> E
The start and end separators are respectively "D" and "E. Note that the key must be encoded as a string by B. The value can be any B-encoded type, including integers, strings, lists, and other dictionaries. The key must be a string and appear in the order of order (in the order of the original string, rather than in the alphabetical order ). Strings use the binary comparison method, rather than the natural comparison specific to a certain culture (that is, they are neither compared by Chinese nor sorted by English ).
Example 1: D3: cow3: moo4: spam4: eggse indicates dictionary {"cow" => "moo", "spam" => "eggs "}
Example 2: D4: spaml1: A1: Bee indicates dictionary {"spam" => ["A", "B"]}

Example 3: D9: publisher3: bob17: publisher-webpage15: www. example. com18: publisher. location4: homee indicates dictionary {"publisher" => "Bob", "publisher-webpage" => "www.example.com", "publisher. location "=>" home "}

(Note: For string and integer, there are official translations, but there is no unified translation for list and dictionary, as shown in the original article, I believe that those who have studied Java and C # will not be unfamiliar with these two terms)

B coding implementation
C
perl
JAVA
python by hackon
decoding encoding bencoded data with Haskell by EDI
Objective- c By chrome