我正在编写一个小应用程序来测试 torrent p2p 的工作原理，我创建了一个示例 torrent 并从我的 Deluge 客户端播种它。我正在尝试从我的应用程序连接到 Deluge 并下载文件。
相关 torrent 是单文件 torrent(文件名为 A - 没有任何扩展名)，其数据是 ASCII 字符串测试。
引用this我能够提交初始握手并得到有效的响应。
紧接着，Deluge 就会发送更多数据。从第 5 个字节开始，它看起来像是一个位域消息，但我不知道如何理解它。我读到 torrent 客户端可能会发送 Bitfield 和 Have 消息的混合，以显示他们拥有 torrent 的哪些部分。 (我的客户端没有发送任何位字段，因为它假设不存在有问题的文件的任何部分)。
如果我的理解是正确的，它表明消息大小为 2:标识符 + 有效负载的大小。如果是这样的话，为什么它会发送这么多数据，那应该是什么？
在我的应用程序发送感兴趣命令后，也会发生同样的事情。 Deluge 以 unchoke 的 1 字节消息进行响应(但随后会再次附加更多数据)。
最后，当它实际提交片段时，我不确定如何处理这些数据。第一个带下划线的字节是 84，它对应于字母 T，正如预期的那样，但我无法对其余数据有更多的理解。
请注意，所讨论的链接并未真正指定客户端在初始握手完成后应如何按顺序提供消息。我只是假设根据对我来说有意义的内容来发送感兴趣和请求，但我可能完全没有兴趣。
最佳答案
我认为 Deluge 没有发送您所看到的额外字节。
如果您查看它们，您会发现所有额外字节都是握手消息中已经存在的字节，这应该是迄今为止您收到的最长消息。
我认为您正在将新消息读入同一缓冲区，而没有将其归零或执行任何操作，因此您会在您读取的最新消息的字节之后再次看到早期消息中的字节。
考虑检查您正在使用的网络 API 是否有办法检查实际接收到的字节数，并且只查看缓冲区的那一部分，而不是整个缓冲区。
关于bittorrent - BitTorrent 同行(Deluge)在说什么？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/50845688/