BT protocol translation

Article Source: http://wiki.theory.org/bittorrentspecification Translation: Chen Liang E-mail: clzzclzz@hotmail.com version: 0.1 Description: This article only translated part of the original date: 2004-11-8 --- 2004-11-9

Peer Wire Protocol (TCP) Based on TCP's part of the protocol OverView

The Peer Protocol Facilitates The Exchange of Pieces As Described in The MetaInfo File. This communication protocol is used to exchange file pieces in one original file. A translation: The original file refers to the file that you want to download.

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 Note: Note: This word "piece" is specified in the original protocol, which also appears in this agreement but is different from the original. Therefore, we rename it "block" to indicate the data transmitted in this Agreement.

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 The Remote Peer Will Begin Requesting Blocks When The Client Unchokes Therm. If a client and another remote client established, the remote client must maintain two status information. - Block: Indicates that the remote client does not accept any request message from this client. All request messages will be abandoned. - Interested: Indicates that the remote client accepts the request of this client.

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 Note: This is also a suggestion that this client also needs to be kept It is interested in the remote client. Therefore, there are 4 states: - This pair is blocked: This client blocks the remote client. - This is far-interest: this client is interested in the remote client. - Remotely blocked: Remote client blocks this client. - Far interested in this: Remote client is interested in this client. Client Connections Start Out As "Choked" and "not interested". In Other Words: - AM_Choking = 1 --AM_INTERESTED = 0 --peer_choking = 1 --peer_interested = 0 Use the number to show blocking and interested - this pair Far blocked: 1 - this pair of distant interest: 0 - far-to-this block: 1 - far, this is interest: 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. When the remote client is non-blocking this client, this client can download a piece of data from the remote client when you are interested in the remote client. When the remote client is interested in this client, the client can upload a piece of data to the remote client when the client does not block the remote 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 ITOKED (AND Vice-Versa). This client keeps the remote client information is important to what it is interested in. Even if this client is blocked, this information should be kept to the latest. This will allow the remote client to know if this client will begin to download this client. (Translation: Didn't understand, maybe I will understand after writing the client)

Data TypesUnless 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. Data type, unless otherwise indicated, all integer in the Agreement The medium is encoded to 4 bytes (high in the front lower position) value. This includes the length-prefix of all information after the handshake. . Message flowThe peer wire protocol consists of an initial handshake After that, via peers communicate an exchange of length-prefixed messages The length-prefix is ​​an integer as described above The following is a description of information: This protocol has a handshake. After the handshake, the remote client communication passes the exchange information with a length prefix. The length prefix is ​​described above.

HandshakeThe handshake is a required message and must be the first message transmitted by the client.handshake: - pstrlen: string length of , 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" handshaking:... until all messages in And the handshake must pass. Handshake format: - pstrlen: length. It is an ASCII character. The string defined for the '19' - PSTR: protocol. The empty characters that must be "BitTorrent Protocol" - Reserved: 8 bytes. - Info_hash: 20 bytes of SHA1 value. Detailed explanation. Metainfo file. It is the SHA1 value of INFO. Can be obtained from the .torrent file. --PEER_ID: The unique value of 20 bytes is used to identify the remote client. Get it from the TRACK server.

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 SEESHE INFO_HASH Part of The Handshake. The Tracker's Nat-Cheer_id Field of the Handshake. The connection initiator should immediately send its handshake string. The connected recipient may be on the handshake of the initiator, if it has the ability to provide downloads for this file (the only ID of the file is -info_hash). No matter how the recipient should respond to the initiator as soon as the Info_hash field. The NAT check feature of the Track server does not send the peer_id field used to shake hands ????. If A Client Receives A Handshake with An Info_hash That IT IS NOT CURRENTLY Serving. The Client Must Drop The Connection. If the remote client receives an info_hash is not the info_hash it is currently available, the remote client must disconnect.

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 . Note: The initiator can receive information about the remote client from the TRACK server. The peer_id field is consistent in the Tracker server and handshake.

Peer_idthere Are Mainly Two Conventions How To Encode Client And Client Version Information INTO THE PEER_ID, AZUREUS-STYLE AND Shadow '-style.peer_ID Description This is two main habits how to encode client and client version information to peer_id. There is a style of Azureus and the style of 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 The style of 'XT' - Xantorrent Azureus uses the following encodings: '-', two characters of the client ID, 4 ASCII data represents version information, '-', then the random number. Such as: '- AZ2060-'... Known clients use this style:' AZ '- Azureus' bb' - BitBuddy 'CT' - CTORRENT 'MT' - MOONLIGHTRRENT 'LT' - LIBTORRENT 'BX' - Bittorrent X 'TS' - Torrentstorm 'TN' - TorrentDotNET 'SS' - SwarmScope 'XT' - XanTorrentShadow'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 area:' s' - Shadow's Client 'U' - UPnP Nat Bit Torrent 'T' - BitTornado 'A' - ABC The shadow style uses the following encoding: a client identifier including the ASCII letter or number, the three ASCII numbers are version information, '----', but the deduction is random number. Such as: 'S587 ----' ... known clients use this style: 's' - Shadow's Client 'u' - Upnp Nat Bit Torrent 'T' - BitTornado 'A' - ABC

BRAM's Client Now Uses this style ... 'M3-4-2 -'. BRAM's client uses this style ... '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 uses a different style. Its peer_id includes 4 ASCII characters 'exbc', followed by an empty character, followed by an ASCII number, followed by a random character. The number image is the version number of the software, which means there is a real version number. Data is growing in each BitComet release. Many Clients Are Using All Random Numbers or 12 Zeroes Followed by Random NumBers (Like Older Versions Of Bram's Client). Most clients use all random numbers or 12 0 followers. (Like old version of BRAM client)

MessagesAll of the remaining messages in the protocol take the form of . The length prefix is ​​a four byte big-endian value. The message ID is a single decimal character. The payload is message dependent All messages in the Agreement have the following forms: - Length Prefix: The foregoing has an explanation. --Message ID: is a decimal character within 10. --PayLoad: is the Message decision (with the difference between Message).

Keep-alive: 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: keEp- The Alive message is a 0-byte message. is 0000. This message is not and .

Choke: The choke message is fixed-length: choke message is a fixed length message, and no . = 0001, = 0.

UNCHOKE: The unchoke message is fixed-length: UNCHOKE message is a fixed length message, and no . = 0001, = 1. INTERESTED: The interested message is fixed-length: intended message is a fixed length message, And there is no . = 0001, = 2.

NOT INTERESTED: The not interested message is fixed-length: Not intended (not interested) message is a fixed The length of the message and there is no . = 0001, = 3.

Have: The Have Message IS Fixed Length. The payload is the zero-based index of a piece That Has Been successful downloaded.have: HAVE (with a piece) message is a fixed length message. The field indicates which piece it has been downloaded, is a 0-based index. = 0005, = 4.

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: Bitfield (Bit) message may only be sent after the handshake is completed (Before any other message sent). It is optional if this client does not have any pieces, it does not need to be sent. The length of the (Bit Group) is changed, and X is the length of the following () field. The field is a bit group indicating a piece that has been downloaded. The first byte of the first byte should correspond to the first piece, and so on. When this piece is not finished or not, it should be 0, when the pieces have been completed and the activity is active (can be under someone), the extra (last) bit is set 0. One error is the length of the bit group It is considered a mistake. If the client receives a length error or a bit set of excess bit, the client should disconnect.

request: 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 Typical SMALLER THAN A PIECE (Which IS Common "= 2 ^ 18 bytes). A Client Should Close The Connection IF IT Receives A Request for More 2 ^ 17 Bytes.Request: < ID = 6> Request message is a fixed length message, which is used to request a block to the remote client. field includes the following information: - INDEX: Index (integer), 4 bytes, 4 bytes, indicating that the index in the sequel is expressed. Which piece is. 4 bytes - Genecth: Indicates the size of the request block. This value must not be more than 2 ^ 17 bytes, and the typical should be 2 ^ 15 bytes. 4-byte readers notice that a piece will be greater than one piece (usually> = 2 ^ 18 bytes). If a client receives a size 2 ^^ 17 byte, you should close this connection. Piece: The point message is variable length, where x is the length of the block. The payload contacts 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:. PIECE message is a growing message, X is the length of . The field includes the following information: - INDEX: Index: The index (integer), 4 bytes of -bgin: indicates the index in the segment. Which piece is. 4 bytes - Block: is the data of the block pointed to by the begin index.

Cancel: The Cancel Message IS Fixed Length, and is buy to cancel block requests. The payload is identical to what of the "request" message. IT Is Typically Used During "End Game" (see the algorithms section ".cancel: Cancel (Cancel) message is a fixed length message, and It is used to cancel block requests. The field is equivalent to the "Request" message. Typical it is used in "end game" to see the algorithm section. AlgorithMssuper 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 .

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 "release mode" THEN?

Piece Downloading StrategyClients 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 GameWhen 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 UnchokingChoking 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 TOSURE THAT-IEY 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 OUSED CONNECTIONS ONCE IN A While To Find Out Iw 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 are not 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-snubbingOccasionally 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 does not upload to it except as an optimistic unchoke. This frequently results in more than one concurrent optimistic unchoke, (an exception to the exactly ONE OptiSTIC UNCHOKE Rule Mentioned Above, Which Causes Download Rates To Recover Much More Quickly WHEN THEY FALTER.