1

我正在努力实现另一个 bittorrent 客户端，此时正在与 DHT 作斗争。它是根据本规范http://www.bittorrent.org/beps/bep_0005.html实施的，但开始调试它我注意到网络上其他节点的响应有所不同。

例如， find_node 应该返回目标节点信息或 8 个最近的节点。大多数节点回复 34 个最近的节点，通常这 34 个节点中只有 1-3 个节点成功回复了随后的 ping 请求。

是否有其他文件具有更好的实施建议？可能已经证明使用 15 分钟间隔将节点状态更改为有问题的效率不高，我必须使用 10 或其他数字？我在哪里可以找到最好的最新建议？

还有一件奇怪的事。像 router.bittorrent.com 这样的引导节点会使用更接近的节点进行回复，并且通常“节点”BDictionary 属性缓冲区长度不能被 6 整除（紧凑节点信息：IP 为 4，端口为 2）。现在，我只是在最接近 6 长度的整除处切断了缓冲区，但这一切都很奇怪。有谁知道为什么会发生这种情况？

4

1 回答 1

2

规范说（强调我的）：

当一个节点接收到一个 find_node 查询时，它应该用一个键“nodes”和一个包含[...]的紧凑节点信息的字符串的值来响应。

再向下：

节点的联系信息被编码为26 字节的字符串。也称为“紧凑节点信息”，网络字节顺序中的 20 字节节点 ID 具有连接到末尾的紧凑 IP 地址/端口信息。

此外，您应该阅读原始 Kademlia 论文，因为 bittorrent BEP 建立在其中描述的概念之上，并省略了对这些概念的更深入解释。

您可能还想阅读一些扩展，这些扩展或多或少是现在大多数实现的事实上的标准http://libtorrent.org/dht_extensions.html

并阅读其他与 DHT 相关的BEP，其中一些被相当广泛地采用并修改/澄清了 BEP-5 指定的行为，但通常以向后兼容的方式。

例如， find_node 应该返回目标节点信息或 8 个最近的节点

节点将返回可变数量的条目。可能超过 8 个。或更少。

于 2015-07-09T09:22:06.153 回答