Routing 为什么Kademlia会构建它的路由表呢？

我知道Kademlia路由表由160个桶组成

节点被放入bucket 0-159中，这取决于它们的前缀长度（即本地节点键和节点的异或中前导未设置位的数量）

---

为什么会这样，是否有任何性能方面的好处（除了迭代160*20个节点以找到最近的节点是不可行的之外）

Kademlia使用两个节点ID的XOR作为它们之间距离的度量。路由表bucket的思想是，节点对“靠近”它的网络有详细的了解，而从它的ID中获得的信息越少

要查找最接近某个特定键的一组节点，节点首先要从自己的路由表中查询它知道的最接近的节点。平均而言，这些查找中有一半将落在bucket 0所覆盖的地址空间中。但该存储桶只允许包含20个节点，因此这些节点实际距离最近的可能性很小。但是，该bucket中的每个节点都将对该部分地址空间有更详细的了解，并且可能能够从自己的路由表中提供一个更好的关闭节点列表，然后也可以查询这些节点，依此类推

通过这种方式，迭代查找可以非常快速地在实际最近的节点组上进行搜索

当你说

迭代160*20个节点以查找最近的节点是不可行的

我认为你的意思是，实际上询问每一个问题都是不可行的；因为遍历这样的列表以提取最近的列表正是节点处理查找请求（RPC）的方式

请注意，在实际场景中，桶数不太可能接近160。例如，对于一个10亿节点的网络，平均存储桶数将为27

至于原始Kademlia论文中选择的实际值，我不知道为什么桶大小被指定为20。但是，我认为160是从SHA1散列的位大小派生出来的。通常使用哈希函数为要存储的给定值生成密钥。如果使用SHA1的哈希冲突的风险相当低，那么这是可以接受的。如果没有，可以使用不同的哈希算法，例如SHA256将产生多达256个存储桶

为什么会这样，是否有任何性能优势

这种组织与XOR度量相结合，创建了分层的局部性，确保查询稍微靠近目标的节点时，会知道更接近目标的节点。这会产生指数收敛

也许你可以把它看作是一个分布式的区间搜索

我知道Kademlia路由表由160个桶组成

一个包含（最多）160个bucket的平面阵列只是许多实现用于近似正确路由表布局的基本方式

使用桶拆分或多主路由表，您需要一个实际的树布局，其中可能包含160多个桶

事实上，这是一个多宿DHT节点的基于树的路由表的一小部分，有89个节点ID，完整的表比这个大（这些基本上是89个ID中两个的区域）：

---

它的查找缓存甚至更大，由7k个存储桶组成。

这个多主DHT客户端是什么？你能再告诉我一些吗？我不介意看到它的来源。它在bittorrent DHT上运行吗？我自己在pythonIt中编写了一个MDHT客户端，这意味着它是一个作为多个节点运行的客户端，例如多个IP。是的，是bittorrent dht。可以在这里找到来源：是的，有性能优势。这有助于将查找时间保持在O（日志n）。详细解释

0000000...   entries:8 replacements:8
0000001000...   entries:8 replacements:8
0000001001000...   entries:8 replacements:8
00000010010010...   entries:8 replacements:8
00000010010011000...   entries:8 replacements:8
000000100100110010...   entries:8 replacements:8
0000001001001100110...   entries:8 replacements:8
00000010010011001110...   entries:8 replacements:8
0000001001001100111100...   entries:5 replacements:0
0000001001001100111101...   entries:8 replacements:0
000000100100110011111...   entries:8 replacements:0
0000001001001101...   entries:8 replacements:8
000000100100111...   entries:8 replacements:8
000000100101...   entries:8 replacements:8
00000010011...   entries:8 replacements:8
000000101...   entries:8 replacements:8
00000011...   entries:8 replacements:8
0000010...   entries:8 replacements:8
0000011000...   entries:8 replacements:8
0000011001000...   entries:8 replacements:8
00000110010010...   entries:8 replacements:8
00000110010011000...   entries:8 replacements:8
000001100100110010...   entries:8 replacements:8
0000011001001100110...   entries:8 replacements:8
00000110010011001110...   entries:8 replacements:5
0000011001001100111100...   entries:6 replacements:0
0000011001001100111101...   entries:2 replacements:0
000001100100110011111...   entries:8 replacements:0
0000011001001101...   entries:8 replacements:8
000001100100111...   entries:8 replacements:8
000001100101...   entries:8 replacements:8
00000110011...   entries:8 replacements:8
000001101...   entries:8 replacements:8
00000111...   entries:8 replacements:8