在Kademlia论文中，第2.4节的最后一段说明为了妥善处理高度不平衡的树木......
Kademlia节点将所有有效联系人保留在大小至少为k的子树中 节点，即使这需要拆分节点所拥有的桶 ID不在。
然而，本文的前一部分似乎表明，如果一个k-bucket已经有k个元素，那么对该k-bucket的任何进一步添加都需要删除最旧的节点（首先ping它以查看它是否存活）或以其他方式缓存添加，直到该k-bucket中的插槽可用。
这篇论文似乎与这两点相矛盾。
在什么条件下应该拆分k-bucket以及为什么？保持＆＃34;所有有效的联系人＆＃34;似乎不切实际。在路由表中，因为路由表会很快变得非常大。该示例讨论了一个树，其中有许多以001开头的节点和一个以000开头的节点。以000开头的节点必须不断地将其k-bucket拆分为001以保存以001开头的每个有效节点？在一个160位的地址空间中，最终可能会在000的路由表中存储2 ^ 157个节点？
引用栏中的措词也很混乱......
＆＃34;在一个子树＆＃34; - 路由表的子树？
＆＃34;大小为至少k个节点＆＃34; - 我们使用什么度量来确定子树的大小？在这种情况下，节点是指kademlia节点还是k-buckets或其他东西？
答案 0 :(得分：5)
然而，本文的前一部分似乎表明，如果一个k-bucket已经有k个元素，那么对该k-bucket的任何进一步添加都需要删除最旧的节点（首先ping它以查看它是否存活）或以其他方式缓存添加，直到该k-bucket中的插槽可用。
只要有一个节点联系人要插入但该存储桶不符合拆分条件，这就是如何维护存储桶。
在什么条件下应该拆分k-bucket以及为什么？
作为第一近似值：无法在无法插入新节点时拆分存储桶和存储桶的ID空间覆盖您的节点ID。
这对于保持对邻居的充分了解是必要的，同时只能模糊地了解远程键空间部分。即为了地方。
覆盖不平衡树的情况 - 如果节点ID不是（随机）随机的，或者至少在叶子桶中，由于在随机分配时的统计吸收，可能会发生这种情况 - 该方法具有放松如下：
当
然后分开桶。
在实践中，这必须进一步修改，以便放松拆分用于响应，而未经请求的请求应该只使用严格拆分，否则当启动时在表启动时放松拆分时，您可能会得到一些奇怪的失真路由表还没有填充。