使用Java的BitTorrent协议 - 成功握手后的Bitfield

Question

成功发送和接收来自多个对等方的握手后,BitTorrent消息链中的下一步是位域消息.

所述位字段消息看起来像下面,其中,所述顶行explainins协议段的字节长度:

<4-bytes><1-byte><x-bytes>
<nrOfBits><identifier><bits>

我遇到的问题是,几乎所有同行似乎都在发送与上述表示不同的位域消息!消息往往看起来像这样:

size: 332, [0, 0, 0, 112, 5, 127, -1, -1, -1, -1, -5, -1, -1, -1, -1, -1, -17...]

第一个问题是我收到的大多数消息都有长度字节:

 [0, 0, 0, 112]

即使在这种情况下接收的消息总共包含332个字节,而在某些其他情况下,消息可能只有80个字节左右.

第二个问题是这些位通常是重复-1或其他一些奇怪的负值.

我不认为这可归因于我身边的低级编码问题,因为其他消息工作正常.

Answer 1

问题#1:

TCP,我假设你正在使用,是一个蒸汽协议.消息以永无止境的字节流形式出现.您必须自己将流分成单独的消息.您在单次读取中从套接字读取332个字节的事实并不意味着您已读取单个消息.Bit torrent客户端经常传递消息(一次发送多条消息,而不等待答案).如果长度为[0,0,0,112],则消息的长度为4 + 1 + 111(长度为4个字节,标识符为1个字节,111个字节为字节).而已.在这116个字节之后出现下一条消息.

编辑:关于uTP,uTorrent基于UDP的传输协议也是如此,尽管它基于面向数据报的UDP.

问题#2:

你所看到的是一个字节数组,在java中总是无符号的(这真的很烦人).它们的范围始终在-128到127之间,因此当设置第一个(最高有效位)时,java会将字节值视为负值.这样,如果位字段具有设置了所有8位的字节(二进制11111111),则将得到-1的字节值,因为二进制11111111对应于二进制补码中的 -1 .我建议以二进制形式或十六进制(使用类似的东西Integer.toHexString(myByte & 0xff))查看这些字节.

编辑:另一方面,除非您正在编写代码,否则我建议使用现成的Java BitTorrent库.当有现成的,经过良好测试的库来实现你需要的一切,然后一些时,你自己从头开始写这种东西是没有什么意义的.