问题标签 [kademlia]

Bittorrent Mainline DHT (MDHT) 响应中的'v'键值对应什么？

这是一个示例 buncoded 响应：

我在任何地方都找不到这个密钥。

以下是我目前关于该协议的资料：

• BEP 5: DHT 协议
• Kademlia：设计规范

我正在为内部集群实施我自己的 dht。由于它将用于像bittorrent这样的文件共享程序，“Mainline DHT”是我看的第一件事。之后我发现了“纠缠”（python，使用扭曲矩阵的 dht），国会（python，使用 pyev + libev 的 dht），当然还有原始的“kademlia”。

他们在组织 k-buckets 上有不同的方法：

1) 国会，kademlia 使用固定的 160 个桶，范围为 2* i <= (每个 id 与我们的差异) < 2 *(i+1)，对于 0 <= i < 160。

2）主线DHT和纠缠使用动态桶。开始时，他们只有 1 个桶覆盖整个空间。在它被 8 个存活节点填充后，桶将被拆分为 2 个新节点。但前提是我们自己的 id 在那个桶里。如果不是 - 存储桶将永远不会被拆分。因此，很快我们将拥有 160 个离我们最近的存储桶，而其他存储桶则很少。

两种变体都足够好。但是我发现逻辑上的巨大差异检测是否属于某个存储桶的某个 id。这是我的问题。

congress 和 kademlia 将桶边界视为“与我们的最小距离”和“与我们的最大距离”。因此，我们自己的 ID 将始终在 bucket0 中。bucket1 中最多 2 个其他 id（因为它覆盖 2* 1 <= x < 2 *2 距离）总是离我们最近。所以我的大脑没有坏掉，因为一切都好。

但是，如果您查看 Mainline DHT 或 entangled，您会看到哪些桶边界被视为绝对节点 id 边界，而不是异或距离！因此，理论上完整的表 ID 0、1、2、3、4、5、6、7 将在 1 个存储桶中。

所以。为什么有些实现将桶边界视为“与我们的最大/最小距离”，而另一些实现将桶边界视为“最大/最小 160 位整数值”？

最近看了一篇关于 Kademlia 协议的文档，试图去理解这个协议，但我还是有一个疑问：为什么一个节点知道自己的 ID 而不是 ip 或端口就必须找到另一个节点？为什么他有ID而他不知道IP或端口，他从哪里得到ID？我认为两个不同节点之间的“距离”不是路由距离或真实距离，它只是一个虚拟距离，可以通过算法快速找到节点，对吗？

也许我的英语不是很清楚，因为英语不是我的母语，但如果你需要，我会尽量表达清楚。非常感谢！

为什么Kademlia 分布式哈希表使用 UDP 作为其网络传输协议，即使它不可靠？

我目前正在研究Kademlia点对点协议，我很好奇是否有人知道有效广播信息/消息的技术或方法？

有一篇论文Effcient Broadcast in Structured P2P Networks描述了Chord中的一种广播方式。他们的想法是将网络分成两部分并将广播消息发送到每个分区中的第一个节点。被联系的节点再次划分它们的“子网”并执行相同的操作。使用这种技术，您可以通过网络在生成树上广播消息。但是，我在将它应用到 Kademlia 时遇到了问题，因为很难可靠地对 Kademlia 网络进行分区。

有人知道如何实现这一目标或存在哪些替代方法？

我不想大规模淹没网络，因为这会对网络负载产生不良影响并导致大量冗余流量。

我了解 Kademlia 路由表由 160 个存储桶组成。

节点被放入存储桶 0-159，具体取决于它们的前缀长度（这是本地节点密钥和节点的 XOR 中的前导未设置位的数量）。

为什么会这样，是否涉及任何性能优势（除了迭代 160*20 节点以找到最接近的节点是不可行的事实之外）？

我知道（理论上）数据是如何存储在 DHT 中的。但是，我不确定如何更新与密钥关联的数据。这可能吗？此外，如何在 DHT 中处理冲突。

Its been the first time I read about Kademlia today, and some points I don't think I got them right.

The distance between nodes and keys is the xor of their values.

So, if I have key x and node y, the distance between them is x xor y.

But why what is the point to bucket the nodes I know about and order them by the prefix length ? That doesn't seem to be connected directly with the xor of node IDs to find closests nodes to me ?

When I get a request for a value I search in the nodes in the closests buckets to me, that is the nodes which have the largest shared prefix with me, ie the first few buckets of the 160 buckets ?

or instead I check all nodes I know about in all the buckets and I calculate the xor between the key I am looking for, and those nodes IDs, and then send my request to the top k matches based on the xoring results with the key ID ?

Sorry I am a bit new to DHTs, and found the explanations online a bit not clear.

不久前，我使用了 Kademlia (KAD) 协议。我了解它是如何工作的，并且我想到可以使用它来创建分布式数据存储。

无论如何，有一个问题：在 Kademlia 中，每个数据包都有一个“拥有”它的节点。当请求数据时，它会传播到下一个节点，但会被分配一个 TTL。之后，它将被删除。Kademlia 中的想法是，“所有者”节点在数据过期之前刷新其他节点上的数据。

据我了解，即使“所有者”节点离开网络，这也会导致缓存数据 - 但只是暂时的。如果所有者节点再也没有回来，那么从它复制到其他节点的所有数据迟早会过期，因此过一段时间数据就会消失。

虽然这对于人们想要共享文件的 P2P 网络来说是可以的，但对于分布式数据存储来说就不是很好了。

怎么可能处理这个？

或者 - 是否有另一个类似于 Kademlia 的 P2P 协议考虑到这一点？在我的想象中，“完美”的解决方案是如果总是有许多 N 个节点来保存复制的数据。一旦其中一个离开，剩余的 N-1 个节点就会寻找另一个将数据推送到的节点，这样您就会再次拥有 N 个节点。

这样的协议存在吗？

我一直在尝试了解 torrent-magnet 技术，但我似乎无法弄清楚在打开磁力链接时如何连接到第一个对等方。

当您获得如下所示的磁力链接时，它不包含初始对等点 - 只有 BitTorrent 信息哈希 (btih) 和文件名。

根据BitTorrent & Magnets：它们是如何工作的？（MakeUseOf）

如果您单击未指定跟踪器 ( tr)的磁力链接，将使用 DHT 找到第一个对等点。一旦你有了对等点，对等点交换也开始了。

Wikipedia 上的DHT 文章没有指定如何找到对等点，但在Kademlia 文章（BitTorrent DHT 所基于）中，它说

想要加入网络的节点必须首先通过引导过程。在这个阶段，加入节点需要知道已经参与 Kademlia 网络的另一个节点的 IP 地址和端口——一个引导节点（从用户获得，或从存储的列表中获得）。

但是它从哪里知道那个节点呢？我没有在磁力链接中看到地址或任何内容。由于它是分散的（无跟踪器），我不希望它提前知道节点。或者 DHT 实际上不是去中心化的？