致力于bep44实现，我使用定义的kademlia算法在给定哈希id的情况下找到最接近的好节点。
使用我的程序我执行go run main.go -put "Hello World!" -kname mykey -salt foobar2 -b public并获取存储在一百个节点上的值（好）。
现在，当我连续多次运行它时，由put请求写入的ip集很难相交。
这是一个问题，因为当我尝试执行get请求时，查询的ips集与put集不相交，因此找不到该值。
在我的测试中，我使用public dht bootstrap节点
"router.utorrent.com:6881",
"router.bittorrent.com:6881",
"dht.transmissionbt.com:6881",
当我查询节点时，我选择了8个最近的节点（nodes := s.ClosestGoodNodes(8, msg.InfoHash())），这些节点通常在递归遍历后以~1K查询列表结束。
根据我的理解，根据表的状态，在dht表中存储info hash的地址是确定的。在进行连续查询时，我希望表格确实会发生变化，但不会那么多。
商店节点集如何不相交？
答案 0 :(得分：1)
由于BEP44是一个扩展，它只受DHT节点子集的支持，这意味着迭代查找机制在确定最近节点集是否稳定并且终止查找时需要考虑支持。 / p>
如果某个节点在get响应中返回token，v或seq字段，那么它有资格获得最近集的只读 get < / em>的
如果某个节点返回token，那么它有资格获得 get 的最近集合，然后 put 操作。
因此，您的查找可能位于密钥空间中最接近目标ID但不符合相关操作条件的一组节点上。只要您的候选人比最知名的合格联系人更近，您就必须继续搜索。我称这个边界在扩大，因为它在概念上扩大了目标周围的搜索范围。
此外，您还需要在执行put请求时考虑错误响应或缺少响应。您可以重试节点或尝试下一个符合条件的节点。
由于我自己的DHT实现文档中的健壮性和安全性原因，我已经写下了一些additional constraints可能希望在查找中放置最接近的集合。
通常在递归遍历后以~1K查询列表结束。
这表明您的查找算法存在问题。根据我的经验，如果您正在使用并发请求进行查找，则查找应该只需要60到200 udp的请求来查找其目标，在顺序请求时可能更少。
Verbose logs终端开始关注查找如何取得进展以及我从同行那里得到多少垃圾对我有用。
在我的测试中，我使用public dht bootstrap节点
您应该将路由表写入磁盘并从那里重新加载它，并且只有当RT中的任何持久节点都不可访问时才执行引导。否则，您将浪费引导节点的资源，并且在执行任何查找之前必须首先重新填充路由表，从而浪费时间。