文章出處：http://wiki.theory.org/BitTorrentSpecification
翻譯：陳亮
e-mail: [email protected]
版本: 0.1
說明：本文只翻譯了原文中的一部分
日期：2004-11-8 --- 2004-11-9
Peer wire protocol (TCP) 基於tcp的那部分協議
Overview
總述
The peer protocol facilitates the exchange of pieces as described in the metainfo file.
這個通訊協議用來更加容易的交換在一個原文件中的文件片斷。譯註：原文件是指要下載的文件。
Note here that the original specification also used the term "piece" when describing the peer protocol, but as a different term than "piece" in the metainfo file. For that reason, the term "block" will be used in this specification to describe the data that is exchanged between peers over the wire.
注意：原來的協議中指定了這個單詞“片斷”，在本協議中也出現了但是和原來的不一樣。因此，我們把它改稱爲“塊”,用來表示在本協議中傳輸的數據。
A client must maintain state information for each connection that it has with a remote peer:
--choked: Whether or not the remote peer has choked this client. When a peer chokes the client, it is a notification that no requests will be answered until the client is unchoked. The client should not attempt to send requests for blocks, and it should consider all pending (unanswered) requests to be discarded by the remote peer.
--interested: Whether or not the remote peer is interested in something this client has to offer. This is a notification that the remote peer will begin requesting blocks when the client unchokes them.
如果一個客戶端和另一個遠程的客戶端建立的連接,遠程的客戶端就必須保持兩個狀態信息。
--阻塞：表明遠程客戶端不接受本客戶端的任何請求消息。所有請求消息都將被拋棄。
--感興趣的：表明遠程客戶端接受本客戶端的請求。
Note that this also implies that the client will also need to keep track of whether or not it is interested in the remote peer, and if it has the remote peer choked or unchoked. So, the real list looks something like this:
--am_choking: this client is choking the peer
--am_interested: this client is interested in the peer
--peer_choking: peer is choking this client
--peer_interested: peer is interested in this client
注意：這也是一個暗示表示本客戶端也需要保持它是否是對遠程客戶端感興趣的。所以一其就有4種狀態：
--本對遠阻塞：本客戶端對遠程客戶端阻塞。
--本對遠感興趣：本客戶端對遠程客戶端感興趣。
--遠對本阻塞：遠程客戶端對本客戶端阻塞。
--遠對本感興趣：遠程客戶端對本客戶端是感興趣的。
Client connections start out as "choked" and "not interested". In other words:
--am_choking = 1
--am_interested = 0
--peer_choking = 1
--peer_interested = 0
用數字表示一下阻塞 和感興趣
--本對遠阻塞：1
--本對遠感興趣：0
--遠對本阻塞：1
--遠對本感興趣：0
A block is downloaded by the client when the client is interested in a peer, and that peer is not choking the client. A block is uploaded by a client when the client is not choking a peer, and that peer is interested in the client.
當遠程客戶端對本客戶端是非阻塞，本客戶端對遠程客戶端感興趣時，本客戶端可以從遠程客戶端下載一塊數據。當遠程客戶端對本客戶端感興趣，本客戶端對遠程客戶端不阻塞時，本端可以上載一塊數據到遠程客戶端。
It is important for the client to keep its peers informed as to whether or not it is interested in them. This state information should be kept up-to-date with each peer even when the client is choked. This will allow peers to know if the client will begin downloading when it is unchoked (and vice-versa).
本客戶端保持遠程客戶端對它是否感興趣的信息是重要的。即使本客戶端被阻塞，這份信息應該保持爲最新的。這將允許遠程客戶端知道如果本客戶端將要開始下載本客戶端什麼時候被阻塞。(譯註：沒看明白，也許等寫完客戶端後就明白了)
Data Types
Unless specified otherwise, all integers in the peer wire protocol are encoded as four byte big-endian values. This includes the length prefix on all messages that come after the handshake.
數據類型
除非另有說明，所有的整數型在本協議中被編碼爲4字節（高位在前低位在後）值。這個包括了在握手之後所有信息的長度-前綴。
Message flow
The peer wire protocol consists of an initial handshake. After that, peers communicate via an exchange of length-prefixed messages. The length-prefix is an integer as described above.
以下的是信息的介紹：
本協議有一個握手過程。在握手之後遠程客戶端通訊通過一個帶有長度前綴的交換信息。長度前綴在上面說明了.
Handshake
The handshake is a required message and must be the first message transmitted by the client.
handshake: <pstrlen><pstr><reserved><info_hash><peer_id>
--pstrlen: string length of <pstr>, as a single raw byte
--pstr: string identifier of the protocol
--reserved: eight (8) reserved bytes. Each bit in these bytes can be used to change the behavior of the protocol. An email from Bram suggests that trailing bits should be used first, so that leading bits may be used to change the meaning of trailing bits.
--info_hash: 20-byte SHA1 hash of the info key in the metainfo file. This is the same info_hash that is transmitted in tracker requests.
--peer_id: 20-byte string used as a unique ID for the client. This is the same peer_id that is transmitted in tracker requests.
In version 1.0 of the BitTorrent protocol, pstrlen=19, and pstr="BitTorrent protocol".
握手:
在所有的消息之前，握手必須通過。
握手格式: <pstrlen><pstr><reserved><info_hash><peer_id>
--pstrlen:<pstr>的長度。是ascii字符.必須爲'19'
--pstr: 協議定義的字符串。必須爲"BitTorrent protocol"
--reserved: 8字節的空字符.
--info_hash:20字節的SHA1值。詳細的說明看 metainfo file.是info的SHA1值。可從.torrent文件中得到。
--peer_id: 20字節的唯一值用來標識遠程客戶端。從track服務器的返回中得到。
The initiator of a connection is expected to transmit their handshake immediately. The recipient may wait for the initiator's handshake, if it is capable of serving multiple torrents simultaneously (torrents are uniquely identified by their info_hash). However, the recipient must respond as soon as it sees the info_hash part of the handshake. The tracker's NAT-checking feature does not send the peer_id field of the handshake.
連接的發起者應該立即發送它的握手字符串。連接的接收者可能在等待發起者的握手，如果它有能力爲這個文件提供下載（文件被--info_hash唯一的標識）。不論如何接收者都應該根據info_hash字段儘快的回覆發起者。track服務器的NAT檢查特性不會發送用於握手的peer_id字段????。
If a client receives a handshake with an info_hash that it is not currently serving, then the client must drop the connection.
如果遠程客戶端接收到一個info_hash不是它當前能提供的info_hash,則遠程客戶端必須斷開連接。
If the initiator of the connection receives a handshake in which the peer_id does not match the expected peer_id, then the initiator is expected to drop the connection. Note that the initiator presumably received the peer information from the tracker, which includes the peer_id that was registered by the peer. The peer_id from the tracker and in the handshake are expected to match.
如果連接的發起者收到的peer_id和期望的peer_id不一樣，則發起者斷開連接。注意：發起者可以從track服務器收到遠程客戶端的信息。peer_id字段在tracker服務器和握手中期望是一致的。
peer_id
There are mainly two conventions how to encode client and client version information into the peer_id, Azureus-style and Shadow's-style.
peer_id的說明
這是兩個主要的習慣如何編碼客戶端和客戶端的版本信息到peer_id中。有Azureus的風格 和 Shadow的風格.
Azureus-style uses the following encoding: '-', two characters for client id, four ascii digits for version number, '-', followed by random numbers.
For example: '-AZ2060-'...
known clients that uses this encoding style are:
'AZ' - Azureus
'BB' - BitBuddy
'CT' - CTorrent
'MT' - MoonlightTorrent
'LT' - libtorrent
'BX' - Bittorrent X
'TS' - Torrentstorm
'TN' - TorrentDotNET
'SS' - SwarmScope
'XT' - XanTorrent
Azureus的風格使用以下的編碼： '-', 客戶端ID兩個字符，4個ascii數據表示版本信息，'-',接着的是隨機數。如:'-AZ2060-'...
已知的客戶端使用本風格的有：
'AZ' - Azureus
'BB' - BitBuddy
'CT' - CTorrent
'MT' - MoonlightTorrent
'LT' - libtorrent
'BX' - Bittorrent X
'TS' - Torrentstorm
'TN' - TorrentDotNET
'SS' - SwarmScope
'XT' - XanTorrent
Shadow's style uses the following encoding: one ascii alphanumeric for client identification, three ascii digits for version number, '----', followed by random numbers.
For example: 'S587----'...
known clients that uses this encoding style are:
'S' - Shadow's client
'U' - UPnP NAT Bit Torrent
'T' - BitTornado
'A' - ABC
Shadow的風格使用瞭如下的編碼：一個包括ascii字母或數字的客戶端標識，三個ascii數字是版本信息, '----', 然扣是隨機數.如：'S587----'...
已知的客戶端使用本風格的有：
'S' - Shadow's client
'U' - UPnP NAT Bit Torrent
'T' - BitTornado
'A' - ABC
Bram's client now uses this style... 'M3-4-2--'.
Bram的客戶端使用這種風格... 'M3-4-2--'.
BitComet does something different still. Its peer_id consists of four ASCII characters 'exbc', followed by a null byte, followed by a single ASCII numeric digit, followed by random characters. The digit seems to denote the version of the software, though it appears to have no connection with the real version number. The digit is incremented with each new BitComet release.
BitComet使用了不同的風格。它的peer_id包括了4個ascii字符'exbc',接着是一個空字符，接着是一個ascii數字，接着是隨機字符。數字像是軟件的版本號，通過它表示有一個真實版本號。數據是增長的在每個BitComet發行版中。
Many clients are using all random numbers or 12 zeroes followed by random numbers (like older versions of Bram's client).
多數的客戶端使用所有的隨機數或是12個0接着隨機數。（像是老版本的Bram客戶端）
Messages
All of the remaining messages in the protocol take the form of <length prefix><message ID><payload>. The length prefix is a four byte big-endian value. The message ID is a single decimal character. The payload is message dependent.
消息
在協議中其餘所有的消息都要有以下的形式:<length prefix><message ID><payload>
--length prefix:前文有說明。
--message ID: 是一個10以內的十進制字符。
--payload: 是message決定的(隨着message的不同而不同)。
keep-alive: <len=0000>
The keep-alive message is a message with zero bytes, specified with the length prefix set to zero. There is no message ID and no payload.
keep-alive: <len=0000>
keep-alive（保持活動）消息是一個0字節的消息，<length prefix>爲0000.本消息沒有<message ID>和<payload>。
choke: <len=0001><id=0>
The choke message is fixed-length and has no payload.
choke: <len=0001><id=0>
choke(阻塞）消息是一個固定長度的消息，並且沒有<payload>。<length prefix>=0001, <message ID>=0。
unchoke: <len=0001><id=1>
The unchoke message is fixed-length and has no payload.
unchoke: <len=0001><id=1>
unchoke(疏通）消息是一個固定長度的消息，並且沒有<payload>。<length prefix>=0001, <message ID>=1。
interested: <len=0001><id=2>
The interested message is fixed-length and has no payload.
interested: <len=0001><id=2>
interested(感興趣的）消息是一個固定長度的消息，並且沒有<payload>。<length prefix>=0001, <message ID>=2。
not interested: <len=0001><id=3>
The not interested message is fixed-length and has no payload.
not interested: <len=0001><id=3>
not interested(不感興趣的）消息是一個固定長度的消息，並且沒有<payload>。<length prefix>=0001, <message ID>=3。
have: <len=0005><id=4><piece index>
The have message is fixed length. The payload is the zero-based index of a piece that has been successfully downloaded.
have: <len=0005><id=4><piece index>
have(擁有一個片斷)消息是一個固定長度的消息。<payload>字段表明它已經下載完哪一片，是一個基於0的索引。<length prefix>=0005, <message ID>=4。
bitfield: <len=0001+X><id=5><bitfield>
The bitfield message may only be sent immediately after the handshaking sequence is completed, and before any other messages are sent. It is optional, and need not be sent if a client has no pieces.
The bitfield message is variable length, where X is the length of the bitfield. The payload is a bitfield representing the pieces that have been successfully downloaded. The high bit in the first byte corresponds to piece index 0. Bits that are cleared indicated a missing piece, and set bits indicate a valid and available piece. Spare bits at the end are set to zero.
A bitfield of the wrong length is considered an error. Clients should drop the connection if they receive bitfields that are not of the correct size, or if the bitfield has any of the spare bits set.
bitfield: <len=0001+X><id=5><bitfield>
bitfield(比特組)消息可能只在握手完成後立既發送(在其它任何消息發送之前）。它是可選的，如果本客戶端不擁有任何片斷，則它不需要被髮送。
(比特組)消息的長度是變化的，X是後面<bitfield>(<payload>)字段的長度。<payload>字段是一個比特組表示已經被下載的片斷。第一個字節的高位應該與第一個片斷相對應,以此類推。當這個片斷沒下完或沒下時應該置0，當片斷已下完並且是活動的（可以被別人下）就置1.多餘的（最後的）位都置0.
一個錯誤是比特組長度被認爲是一個錯誤。如果本客戶端收到一個長度錯誤的或是設置了多餘的比特位的比特組，客戶端應該斷開連接。
request: <len=0013><id=6><index><begin><length>
The request message is fixed length, and is used to request a block. The payload contains the following information
--index: integer specifying the zero-based piece index
--begin: integer specifying the zero-based byte offset within the piece
--length: integer specifying the requested length. This value must not exceed 2^17 bytes, typical values are 2^15 bytes.
The observant reader will note that a block is typically smaller than a piece (which is commonly >= 2^18 bytes). A client should close the connection if it receives a request for more than 2^17 bytes.
request: <len=0013><id=6><index><begin><length>
request(請求）消息是一個固定長度的消息，它用來向遠程客戶端請求一個塊。<payload>字段包括了以下的信息:
--index:表示了欲請求片斷的索引(整數) ,4字節
--begin: 表示了在欲請求片斷中的索引。哪一塊。,4字節
--length:表示了請求塊的大小。這個值必須不大於2^17字節，典型應該是 2^15字節。,4字節
讀者注意到一片將一定要大於一塊（通常要>=2^18字節）。如果一個客戶端收到了一個大小2^^17字節,就應該關閉這個連接。
piece: <len=0009+X><id=7><index><begin><block>
The piece message is variable length, where X is the length of the block. The payload contains the following information
--index: integer specifying the zero-based piece index
--begin: integer specifying the zero-based byte offset within the piece
--block: block of data, which is a subset of the piece specified by index.
piece: <len=0009+X><id=7><index><begin><block>
piece(片斷)消息是一個變長的消息，X是<block>的長度。<payload>字段包括瞭如下的信息：
--index: 表示了片斷的索引(整數) ,4字節
--begin: 表示了在片斷中的索引。哪一塊。,4字節
--block: 是begin索引所指向的塊的數據。
cancel: <len=0013><id=8><index><begin><length>
The cancel message is fixed length, and is used to cancel block requests. The payload is identical to that of the "request" message. It is typically used during "End Game" (see the Algorithms section below).
cancel: <len=0013><id=8><index><begin><length>
cancel(取消)消息是一個固定長度的消息,並且它被用來取消塊請求。<payload>字段等同於"request"消息。
典型的它用在"End Game"中，看算法節。
Algorithms
Super Seeding
(This was not part of the original specification)
The super-seed feature in S-5.5 and on is a new seeding algorithm designed to help a torrent initiator with limited bandwidth "pump up" a large torrent, reducing the amount of data it needs to upload in order to spawn new seeds in the torrent.
When a seeding client enters "super-seed mode", it will not act as a standard seed, but masquerades as a normal client with no data. As clients connect, it will then inform them that it received a piece -- a piece that was never sent, or if all pieces were already sent, is very rare. This will induce the client to attempt to download only that piece.
When the client has finished downloading the piece, the seed will not inform it of any other pieces until it has seen the piece it had sent previously present on at least one other client. Until then, the client will not have access to any of the other pieces of the seed, and therefore will not waste the seed's bandwidth.
This method has resulted in much higher seeding efficiencies, by both inducing peers into taking only the rarest data, reducing the amount of redundant data sent, and limiting the amount of data sent to peers which do not contribute to the swarm. Prior to this, a seed might have to upload 150% to 200% of the total size of a torrent before other clients became seeds. However, a large torrent seeded with a single client running in super-seed mode was able to do so after only uploading 105% of the data. This is 150-200% more efficient than when using a standard seed.
Super-seed mode is NOT recommended for general use. While it does assist in the wider distribution of rare data, because it limits the selection of pieces a client can downlad, it also limits the ability of those clients to download data for pieces they have already partially retrieved. Therefore, super-seed mode is only recommended for initial seeding servers.
Why not rename it to e.g. "Initial Seeding Mode" or "Releaser Mode" then?
Piece downloading strategy
Clients may choose to download pieces in random order.
A better strategy is to download pieces in rarest first order. The client can determine this by keeping the initial bitfield from each peer, and updating it with every have message. Then, the client can download the pieces that appear least frequently in these peer bitfields.
End Game
When a download is almost complete, there's a tendency for the last few blocks to trickle in slowly. To speed this up, the client sends requests for all of its missing blocks to all of its peers. To keep this from becoming horribly inefficient, the client also sends a cancel to everyone else every time a block arrives.
There is no documented thresholds, recommended percentages, or block counts that could be used as a guide or Recommended Best Practice here.
Choking and Optimistic Unchoking
Choking is done for several reasons. TCP congestion control behaves very poorly when sending over many connections at once. Also, choking lets each peer use a tit-for-tat-ish algorithm to ensure that they get a consistent download rate.
The choking algorithm described below is the currently deployed one. It is very important that all new algorithms work well both in a network consisting entirely of themselves and in a network consisting mostly of this one.
There are several criteria a good choking algorithm should meet. It should cap the number of simultaneous uploads for good TCP performance. It should avoid choking and unchoking quickly, known as 'fibrillation'. It should reciprocate to peers who let it download. Finally, it should try out unused connections once in a while to find out if they might be better than the currently used ones, known as optimistic unchoking.
The currently deployed choking algorithm avoids fibrillation by only changing choked peers once every ten seconds.
Reciprocation and number of uploads capping is managed by unchoking the four peers which have the best upload rate and are interested. This maximizes the client's download rate. These four peers are referred to as downloaders, because they are interested in downloading from the client.
Peers which have a better upload rate (as compared to the downloaders) but aren't interested get unchoked. If they become interested, the downloader with the worst upload rate gets choked. If a client has a complete file, it uses its upload rate rather than its download rate to decide which peers to unchoke.
For optimistic unchoking, at any one time there is a single peer which is unchoked regardless of it's upload rate (if interested, it counts as one of the four allowed downloaders). Which peer is optimistically unchoked rotates every 30 seconds. Newly connected peers are three times as likely to start as the current optimistic unchoke as anywhere else in the rotation. This gives them a decent chance of getting a complete piece to upload.
Anti-snubbing
Occasionally a BitTorrent peer will be choked by all peers which it was formerly downloading from. In such cases it will usually continue to get poor download rates until the optimistic unchoke finds better peers. To mitigate this problem, when over a minute goes by without getting a single piece from a particular peer, BitTorrent assumes it is "snubbed" by that peer and doesn't upload to it except as an optimistic unchoke. This frequently results in more than one concurrent optimistic unchoke, (an exception to the exactly one optimistic unchoke rule mentioned above), which causes download rates to recover much more quickly when they falter.