我正在努力实施另一个bittorrent客户端，并且此时正在与DHT抗争。它是根据此规范http://www.bittorrent.org/beps/bep_0005.html实现的，但是开始调试它时我注意到其他节点＆＃39;网络上的回复各不相同。
例如，find_node应该返回目标节点信息或8个最近的节点。大多数节点回复34个最近的节点，通常只有1-3个节点成功回复后续的ping请求。
是否有其他文档具有更好的实施建议？可能已经证明，使用15分钟间隔将节点状态更改为可疑是不高效的，我必须使用10或其他数字？我在哪里可以找到最新的最新建议？
还有一件奇怪的事情。像router.bittorrent.com这样的引导节点回复更近的节点，通常是＆＃34;节点＆＃34; BDictionary属性缓冲区长度不能被整除为6（紧凑节点信息：IP为4，端口为2）。现在，我只是将最接近可分割的缓冲区切断为6长度，但这一切都很奇怪。有人知道为什么会这样吗？
答案 0 :(得分：2)
规范说（强调我的）：
当一个节点收到一个find_node查询时，它应该用一个键＆＃34;节点＆＃34;和包含 [...]
的紧凑节点信息的字符串的值
再向下：
节点的联系信息编码为 26字节字符串。也称为＆＃34;压缩节点信息＆＃34; 网络字节顺序中的20字节节点ID具有连接到末尾的紧凑IP地址/端口信息。
此外，您应该阅读原始的Kademlia论文，因为bittorrent BEP建立在其中描述的概念之上，并且省略了对这些概念的更深层次的解释。
您可能还想阅读一些现在大多数实现的或多或少事实上标准的扩展程序http://libtorrent.org/dht_extensions.html
阅读其他与DHT相关的BEPs，其中一些被广泛采用并修改/澄清BEP-5指定的行为，但通常采用向后兼容的方式。
例如，find_node应该返回目标节点信息或8个最近的节点
节点将返回可变数量的条目。可能超过8或更少。