SyntaxHighlighter

2009/04/22

BT Protocol Specification Memo

According to the BT protocol specification and Bittorrent Protocol Specification v1.0, BT Metainfo File (.torrent) format is defined as below:
announceThe URL of the tracker
infonameThe suggested name to save the file as.
piece lengthThe number of bytes in each piece
piecesmultiple 20-byte HASH strings for each piece
lengthThe length of the file in byte. This is exclusive to files
filespathThe subdir name and the name of each sub file.
lengthThe length of each sub file in byte.
nodesThe list of host/IP and port pairs for DHT extension (introduced in BEP 5)


To make a handshake between peers, peers send following data to each other on a TCP connection.
0001020304050607080910111213141516171819202122232425262728293031
19 [1]"BitTorrent Protocol" [19]RESERVED ZERO [8]
info_hash [20]peer id [20]



After making the handshake, peers exchange messages of keep alive and other types. Messages consist of length and the data.

Keep-alive message has only a length data, zero; there is no data field. It can be just ignored. It is generally sent once every two minutes, however timeout may not be concerned to it.
0001020304050607080910111213141516171819202122232425262728293031
Msg Len=0 [4]


Other BT messages are possibly:
  • 0 - choke
  • 1 - unchoke
  • 2 - interested
  • 3 - not interested
  • 4 - have
  • 5 - bitfield
  • 6 - request
  • 7 - piece
  • 8 - cancel
All messages start with the length data and the message type in single byte.
  1. choke
    2. 0001020304050607080910111213141516171819202122232425262728293031
    Msg Len=1 [4]Msg Type=0 [1]

    There is no data in "choke" message.

  2. unchoke
    3. 0001020304050607080910111213141516171819202122232425262728293031
    Msg Len=1 [4]Msg Type=1 [1]

    There is no data in "unchoke" message.

  3. interested
    4. 0001020304050607080910111213141516171819202122232425262728293031
    Msg Len=1 [4]Msg Type=2 [1]

    There is no data in "interested" message.

  4. not interested
    5. 0001020304050607080910111213141516171819202122232425262728293031
    Msg Len=1 [4]Msg Type=3 [1]

    There is no data in "not interested" message.

  5. have
    6. 0001020304050607080910111213141516171819202122232425262728293031
    Msg Len=5 [4]Msg Type=4 [1]index [4]

    "have" message contains one index number whose piece was obtained and whose hash code was verified successfully.

  6. bitfield
    7. 000102030405060708...
    Msg Len=??? [4]Msg Type=5 [1]... [4]...

    "bitfield" is sent as the first message, however downloaders without any data may skip the message. Each bit represents the index of pieces. The flag of each bit means that one if the indexed piece has been sent already, zero if not.

  7. request
    8. 0001020304050607080910111213141516171819202122232425262728293031
    Msg Len=13 [4]Msg Type=6 [1]index [4]begin [4]length [4]

    "request" needs three numerical values: index, begin, and length.
    • "index" means the index number of pieces
    • "begin" is an offset to start download.
    • "length" is the length to download, which is expressed by power of 2. All current implementations use 215.


  8. piece
    9. 0001020304050607080910111213141516171819202122232425262728293031
    Msg Len=13 [4]Msg Type=7 [1]index [4]begin [4]piece [4]

    "piece" is correlated to "request" message. To make it possible to download a part of a piece, this message is used. This massage contains

  9. cancel
    10. 0001020304050607080910111213141516171819202122232425262728293031
    Msg Len=13 [4]Msg Type=8 [1]index [4]begin [4]length [4]

    "cancel" has the same payload format to "request" message. This is only sent when the download is almost completed. At the end of download, there is tendency that network of a few device is crowded. To reduce requests queued in vain at that time, this "cancel" message is used.

  10. port (added in BEP 5)
    11. 0001020304050607080910111213141516171819202122232425262728293031
    Msg Len=3 [4]Msg Type=9 [1]UDP port [2]

時刻: 9:12 ラベル:

0 件のコメント:

コメントを投稿

登録: コメントの投稿 (Atom)