最新的bittorrent DHT实施建议是什么？

我正在努力实现另一个bittorrent客户端，目前正在与DHT进行斗争。它是根据这个规范实现的，但是在开始调试它时，我注意到网络上其他节点的响应是不同的

例如，find_节点应该返回目标节点信息或8个最近的节点。大多数节点使用34个最近的节点进行回复，通常只有34个节点中的1-3个节点成功回复后续的ping请求

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

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

说明书上说（我的重点）：

当节点接收到find_节点查询时，它应该使用键“nodes”和包含[…]的紧凑节点信息的字符串值进行响应

再往下看：

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

---

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

您可能还想了解一些扩展，这些扩展或多或少是现在大多数实现的事实标准

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

---

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

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