BitTorrent peer (Deluge) 在说什么？

Question

我正在编写一个小应用程序来测试 torrent p2p 的工作原理，我创建了一个示例 torrent，并从我的 Deluge 客户端播种它。我正在尝试从我的应用程序连接到 Deluge 并下载文件。

有问题的 torrent 是一个单文件 torrent（文件名为 A - 没有任何扩展名），其数据是 ASCII 字符串 测试。

参考this，我能够提交初始握手并得到有效回复。

紧接着 Deluge 正在发送更多数据。从第 5 个字节开始，它似乎是一个 bitfield 消息，但我不知道该怎么做。我读到 torrent 客户端可能会发送 Bitfield 和 Have 消息的混合，以显示他们拥有 torrent 的哪些部分。 （我的客户端没有发送任何位域，因为它假设文件的任何部分都没有问题）。

如果我的理解是正确的，则说明消息大小为 2：标识符 + 有效负载之一。如果是这样，为什么它会发送这么多数据，那应该是什么？

在我的应用发送 interested 命令后也会发生同样的事情。 Deluge 以 1 字节的 unchoke 消息作为响应（但随后又追加了更多数据）。

最后，当它实际提交片段时，我不确定如何处理这些数据。第一个带下划线的字节是 84，对应于字母 T，正如预期的那样，但我无法更了解其余数据。

请注意，相关链接并未真正指定客户端在初始握手完成后应如何按顺序提供消息。我只是假设发送感兴趣和请求基于对我来说似乎有意义的东西，但我可能完全不在。

Answer 1

我认为 Deluge 不会发送您看到的额外字节。

如果您查看它们，您会注意到所有额外的字节都是握手消息中已经存在的字节，这应该是您迄今为止收到的最长消息。

我认为您正在将新消息读入同一个缓冲区，而没有将其清零或任何其他内容，因此您会再次看到来自较早消息的字节，跟随您读取的最新消息的字节。

考虑检查您使用的网络 API 是否有办法检查实际接收的字节数，并且只查看缓冲区的那一部分，而不是全部。