我正在努力实现另一个 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 倍数的长度切断缓冲区，但这一切都很奇怪。有谁知道为什么会发生这种情况？
规范说（强调我的）：
当节点收到 find_node 查询时，它应该使用键“nodes”和包含以下内容的字符串值进行响应紧凑节点信息为了 [...]
再向下：
节点的联系信息被编码为26字节字符串。也称为“紧凑节点信息”网络字节顺序中的 20 字节节点 ID 具有连接到末尾的紧凑 IP 地址/端口信息。
此外，您应该阅读原始的 Kademlia 论文，因为 Bittorrent BEP 建立在其中描述的概念之上，并省略了对这些概念的更深入的解释。
您可能还想阅读一些扩展，这些扩展或多或少是大多数实现的事实上的标准http://libtorrent.org/dht_extensions.html
并阅读其他与 DHT 相关的内容BEPs，其中一些被相当广泛地采用并修改/澄清了 BEP-5 指定的行为，但通常以向后兼容的方式。
例如，find_node 应该返回目标节点信息或 8 个最近的节点
节点将返回可变数量的条目。可能超过 8 个。或更少。
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
