问题标签 [kademlia]

我在 Java 中的 Kademlia 的 GitHub 上查看了一些实现，但我没有找到任何不手动端口转发项目所在的路由器（无论是通过打孔还是 UPnP）并且仍在积极更新的工作。你们中的任何人都可以推荐任何图书馆吗？

如果没有，我将如何自己实施呢？我对 Kademlia 论文比较熟悉，但我对 Java 中的网络不是很熟悉。

编辑：我被告知打孔对 DHT 没用。因此，我仍然想知道是否有任何使用 UPnP 的 Java Kademlia 库得到维护，或者关于如何将 UPnP 用于我编写的 Java 程序的任何信息。

所以我们可以确定 XOR 距离度量是一个真正的度量（它是对称的，满足三角不等式等）

在阅读 Kademlia 及其 k-buckets 之前，我在想，每个节点都会简单地找到自己的 id 并存储其最近的 k 个邻居，反之亦然。节点会定期 ping 它们的邻居，如果它们没有响应，则将它们从列表中逐出。

现在，如果我想找到某个关键 X，我只需将此请求发送到我的邻居中与 X 最接近的节点，并且这会递归地继续，直到您获得一个在其自身及其所有邻居中最接近 X 的节点。该节点将在那些存储 X 值的节点中，然后他们将反转步骤（即展开堆栈）以将值返回给请求者。

节点在加入网络时只需查找自己的 id，然后添加每个 ots 邻居。

似乎比 Kademlia 简单得多。这行得通吗？它只是因为每次查找可能有更多的跃点而慢得多吗？

一段时间以来，我一直在研究 DHT，尤其是 kademlia。我正在尝试在 Kademlia DHT 上实现一个 p2p 网络。我希望能够向全网八卦消息。根据我对使用八卦协议的研究，但是当我已经使用 dht 来存储对等点时，添加另一个全新的协议来传播消息似乎很奇怪。是否有一个八卦协议可以在像 Kademlia 这样的 DHT 拓扑上运行或与它一起工作？

我正在阅读Kademlia 白皮书并尝试实现路由表。

我正在使用 160 位地址空间并有一个​​ 160 k-buckets 的数组。据我了解，此实现将通过节点 ID 具有多少前导零位将节点 ID 存储在存储桶中。即bucket[0]，节点 ID 将具有 160 个前导零（只有 1 个节点），并且bucket[159]将具有没有前导零的节点（整个地址空间的 50%）。

问题 使用这个实现，当找到最接近目标 nodeId 的 k 节点时，我会只计算目标的前导零并返回该 k 桶中的所有内容吗？

使用这个实现，我看不到任何地方/不需要使用 Kademlia 构建的 XOR，所以我认为我的实现不正确。

对于 P2P 网络，我知道一些网络具有初始引导节点。然而，人们会假设所有新节点都从所述引导节点学习对等节点，网络将难以添加新对等节点，最终会出现许多派系——不平衡，因为没有更好的词。

有什么方法可以防止这种情况发生吗？我知道一些 DHT 将它们的路由表构建为不太容易受到此影响，但我认为问题仍然存在。

为了澄清，我问的是存在/通常用于对等网络的哪种对等混合算法。

语境

我正在尝试实现 Kadmelia 的 K-Bucket 算法来跟踪更近的节点。我从理论上理解算法是如何工作的

1. 当一个新节点added
2. 如果桶大小没有超过 k（桶大小），我们将它添加到当前桶中
3. 否则，我们拆分桶并通过循环每个位来划分父桶中的联系人并将它们分成两个桶。
4. 这也意味着对于给定的节点，会有k * 8桶（或列表）

问题

问题是指本示例中采用的方法http://blog.notdot.net/2009/11/Implementing-a-DHT-in-Go-part-1

假设我们已将 Node 定义为长度为 20 的字节数组

我试图了解该PrefixLen函数实际计算前缀和填充路由表的作用。我了解该方法的每个组件的作用。我的意思是，我了解位移运算符的作用，并AND用 1 检查该位是否已设置。

我不明白的是返回值以及为什么以这种方式设置它们。

返回值如何适合用作路由表的索引？

这种方法与循环遍历每一位有何相同之处？作者如何使用 PrefixLen 方法达到相同的结果。

您能否通过示例帮助我理解这一点。提前致谢。

kademlia论文讨论了桶的组织、拆分、合并和找到正确的桶以抽象、简洁和令人困惑的术语插入。

§2.2 讨论了一组固定的 160 个桶，每个桶覆盖键空间的一个固定子集。但是后面的章节涉及到额外的拆分和桶，涵盖了键空间的不同部分。不太适合固定列表

组织桶的正确方法是什么？

_{Meta：由于混淆反映在许多问题中，并且部分信息分散在许多答案中，因此此问答旨在提供易于链接的澄清}

我正在尝试根据符合BEP42的 NodeId 计算

我不够聪明，无法理解 BEP42 中给出的示例代码但是创建 nodeId 的算法给出为： crc32c((ip & 0x030f3fff) | (r << 29))

还有一个结果表，从中我们可以看到，如果使用的随机种子是“86”（我假设是十进制），那么 IP 地址 21.75.31.124 的一个好的节点 ID 将从 5a3ce9 开始。

所以我尝试以下方法：

但是我得到了 6ea6c88c，这几乎在所有方面都是错误的。8472 有一些代码用于确定客户端的 nodeId 是否符合 BEP42，但我也不理解该代码。

谁能告诉我上面的代码有什么问题？

我知道在 SO 的某个地方之前有一个关于这个的问题，但我找不到了。NodeId和InfoHash的关系。下图大致正确吗？

背景 （无需阅读）

我正在尝试用 Java 实现我自己的 DHT/bittorrent 应用程序。我知道已经有一些我永远不会更好的优秀实现。但这纯粹是一种享乐主义的追求。肯尼迪说了什么？“我们选择这样做不是因为它很容易......”

我已经克服了简单的部分，即编写低级套接字处理和远程过程调用语法等。现在我进入了困难的部分，我必须负责任地行事并为 DHT 上的传入请求提供服务。（维护 KBucket 等）

我认为最接近这个问题。

构建路由表的一种明显方法是简单地维护一个文字表。映射（异或，节点）

Kademlia 讨论了由 XOR 的最高有效位组织的“桶”的使用。“桶”的实际目的是什么？ 当我们可以简单地将“实际”XOR 作为映射中的键时，为什么还要搞乱“最长前缀”？

显然地图可能有 2^160 大，但我们可以使用一些启发式方法来限制地图的大小，而不是实现一些任意的桶概念？在任何情况下（无论是否存储桶），当搜索一个接近我们被要求找到的 nodeId 时，我们仍然必须遍历表中的所有节点并对每个节点执行 XOR？

我错过了什么？