遵循在XLattice找到的Kademlia规范，我想知道 iterativeFindNode 操作的确切工作以及它如何用于引导和刷新存储桶。该文件说：
在此过程结束时，节点将累积一组k个活动联系人或（如果RPC为FIND_VALUE）可能已找到数据值。一组三元组或值返回给调用者。 （§4.5，节点查找）
找到的节点将返回给调用者，但规范没有指定一旦返回后如何处理这些值。特别是在刷新和引导的环境中：
如果在tRefresh的任何给定存储桶范围内没有执行任何节点查找（基本Kademlia中的一小时），则该节点选择该范围内的随机数并进行刷新，即使用该数字作为键的iterativeFindNode。 （§4.6，刷新）
节点按如下方式加入网络：[...]它为n [节点ID]执行iterativeFindNode（§4.7，Join）
运行 iterativeFindNode 操作本身是否足以刷新联系人的k-buckets，或者规范是否忽略了应该将结果插入联系人桶中？
注意： iterativeFindNode 操作使用底层RPC，并通过它们可以按指定更新k-buckets：
每当节点收到另一个节点的通信时，它就会更新相应的节点 桶。 （§3.4.4，更新）
但是，只有FIND_NODE RPC的接收者才会被插入k-buckets，并且该节点的响应（包含k-contacts列表）将被忽略。
答案 0 :(得分：2)
但是，只有FIND_NODE RPC的接收者才会被插入k-buckets，并且该节点的响应（包含k-contacts列表）将被忽略。
我不能代表XLattice，但是我已经开始使用bittorrent kademlia实现，这让我觉得很奇怪。
传入的请求未被验证为可到达的节点（NAT和防火墙问题），而对传出RPC调用的响应是节点确实可达的良好指示。 因此，传入的请求只能作为暂定联系人添加，这些联系人仍需要进行验证，而传入的响应应立即用于路由表维护。
但区分响应中包含的三元组和响应本身很重要。三元组未经验证，另一方面，响应本身是对该节点活跃性的良好验证。
要点：
传入请求
传入回复
回复中的元组