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

Question

从多个对等点成功发送和接收握手后，BitTorrent 消息链中的下一步是bitfield 消息。

bitfield 消息如下所示，第一行解释了协议段的字节大小：

<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 对应于 two's complement 中的 -1。我建议以二进制形式或十六进制形式（使用 Integer.toHexString(myByte & 0xff) 之类的东西）查看这些字节。

编辑：换一种说法，除非你只是为了它而编写代码，否则我建议using a ready-made Java BitTorrent library。当存在现有的、经过良好测试的库可以实现您需要的所有内容时，您自己从头开始编写这种东西几乎没有意义。