bt peer通信协议报文格式

接下来协议的所有报文采用如下的结构：<length prefix><message ID><payload>。length prefix(长度前缀)是一个4字节的大端(big-endian)值。message ID是单个十进制值。playload与消息相关。

l  keep-alive: <len=0000>

keep-alive消息是一个0字节的消息，将length prefix设置成0。没有message ID和payload。如果peers在一个固定时间段内没有收到任何报文(keep-alive或其他任何报文)，那么peers应该关掉这个连接，因此如果在一个给定的时间内没有发出任何命令的话，peers必须发送一个keep-alive报文保持这个连接激活。通常情况下，这个时间是2分钟。

l  choke: <len=0001><id=0>

choke报文长度固定，并且没有payload。

l  unchoke: <len=0001><id=1>

unchoke报文长度固定，并且没有payload。

l  interested: <len=0001><id=2>

interested报文长度固定，并且没有payload。

l  not interested: <len=0001><id=3>

not interested报文长度固定，并且没有payload。

l  have: <len=0005><id=4><piece index>

have报文长度固定。payload是piece(片)的从零开始的索引，该片已经成功下载并且通过hash校验。

实现者注意：实际上，一些客户端必须严格实现该定义。因为peers不太可能下载他们已经拥有的piece(片)，一个peer不应该通知另一个peer它拥有一个piece(片)，如果另一个peer拥有这个piece(片)。最低限度”HAVE suppresion”会使用have报文数量减半，总的来说，大致减少25-35%的HAVE报文。同时，给一个拥有piece(片)的peer发送HAVE报文是值得的，因为这有助于决定哪个piece是稀缺的。

一个恶意的peer可能向其他的peer广播它们不可能下载的piece(片)。Due to this attempting to model peers using this information is a bad idea.

l  bitfield: <len=0001+X><id=5><bitfield>

bitfield报文可能仅在握手序列发送之后，其他消息发送之前立即发送。它是可选的，如果一个客户端没有piece(片)，就不需要发送该报文。

bitfield报文长度可变，其中x是bitfield的长度。payload是一个bitfield，该bitfield表示已经成功下载的piece(片)。第一个字节的高位相当于piece索引0。设置为0的位表示一个没有的piece，设置为1的位表示有效的和可用的piece。末尾的冗余位设置为0。

长度不对的bitfield将被认为是一个错误。如果客户端接收到长度不对的bitfield或者bitfield有任一冗余位集，它应该丢弃这个连接。

l  request: <len=0013><id=6><index><begin><length>

request报文长度固定，用于请求一个块(block)。payload包含如下信息：

n  index: 整数，指定从零开始的piece索引。

n  begin: 整数，指定piece中从零开始的字节偏移。

n  length: 整数，指定请求的长度。

l  piece: <len=0009+X><id=7><index><begin><block>

piece报文长度可变，其中x是块的长度。payload包含如下信息：

n  index: 整数，指定从零开始的piece索引。

n  begin: 整数，指定piece中从零开始的字节偏移。

n  block: 数据块，它是由索引指定的piece的子集。

l  cancel: <len=0013><id<=8><index><begin><length>

cancel报文长度固定，用于取消块请求。playload与request报文的playload相同。一般情况下用于结束下载。

l  port: <len=0003><id=9><listen-port>

port报文由新版本的Mainline发送，新版本Mainline实现了一个DHT tracker。该监听端口是peer的DHT节点正在监听的端口。这个peer应该插入本地路由表(如果支持DHT tracker的话)。