java - 使用 Java 的 BitTorrent 协议(protocol) - 成功握手后的位字段

Question

成功发送和接收来自多个点的握手后，BitTorrent 消息链的下一步是位域消息。

bitfield 消息如下所示，其中顶行解释了协议(protocol)段的字节大小:

<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 是一种 Steam 协议(protocol)。消息以永无止境的字节流形式出现。您必须自己将流分成单独的消息。事实上，您在一次读取中从套接字中读取了 332 个字节并不意味着您已经读取了一条消息。 Bit Torrent 客户端通常通过管道传输消息(一次发送多条消息，无需等待答复)。如果长度为 [0,0,0,112]，则消息的长度为 4 + 1 + 111(4 个字节的长度，一个字节用于标识符，以及 111 个位域字节)。而已。在这 116 个字节之后是下一条消息。

编辑:uTP 也是如此，它是基于 uTorrent UDP 的传输协议(protocol)，尽管它基于面向数据报的 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 .如果现有的、经过良好测试的库可以实现您需要的一切，那么您自己从头开始编写此类内容几乎没有意义。