DHT 是如何工作的？

Question

我从 wiki 中获取了关于 DHT 的基本概念：

存储数据：

在 DHT 网络中，每个节点负责特定范围的 key-space。要将文件存储在 DHT 中，首先，hash the file's name to get the file's key；第二，send a message put(key, file-content) to any node of the DHT，消息将被转发到负责key的节点，该节点将存储(key, file-content)对。

获取数据：

从 DHT 获取文件时，首先对文件名进行哈希处理以获取 key；第二次向任意节点发送消息get(key)，中继消息直到...

问题：

1. 要存储文件，我们可以对文件名进行哈希处理以获取其key，但 wiki 表示：

在现实世界中，密钥 k 可能是文件内容的哈希值，而不是 比文件名的哈希值提供内容可寻址存储， 这样重命名文件就不会妨碍用户找到它。

哈希文件的内容？我应该如何知道文件的内容？如果我已经知道文件的内容，那我为什么要在 DHT 中搜索呢？

1. 根据 wiki，每个参与节点都会腾出一些空间来存储文件。那么这是否意味着，如果我参加了 DHT，我必须 spare 10G disk space 来存储那些由我负责的 key falls into the specific key-space 的文件？

2. 如果我确实应该腾出一些磁盘空间来存储这些文件，那么我应该如何将这些(key, file-content) 存储在磁盘上？我的意思是，该文件应该被安排成B-tree 或我磁盘上的其他东西吗？

3. 当查询发生时，我的计算机如何响应？我假设首先检查queried key，如果在我的key-space 中，然后在我的磁盘上找到corresponding file。对吗？

Answer 1

DHT 只是一种算法。在其基础上，它提供分布式键值对 PUT 和 GET 操作。类似于许多编程语言中的普通 Map 或关联数组。

由于不可信节点、故障率等现实世界的限制，实际的 DHT 实现不提供任意长度的PUT(<uint8[]>, <uint8[]>) 操作。

示例：

例如，针对 bittorrent 的 kademlia 实现提供了以下接口：

• PUT(uint8[20], uint16)
• GET(uint8[20]) -> List<Pair<IP, uint16>> 其中列表仅代表实际数据的随机抽样子集

如您所见，与更通用的关联数组相比，它实际上是一个专门的非对称接口。 IP 地址始终源自 PUT 发送者的源地址，即不能显式设置。 并且 GET 返回一个列表而不是单个值，因此它实现了 MultiMap 或 Map<List>，如果你想这样看的话。

在 bittorrent 的情况下，哈希用作内容描述符，其中拥有内容的对等方在 DHT 上宣布自己。如果有人想要文件，他们会在 DHT 上查找 IP/端口对，然后通过单独的协议联系对等方，然后下载数据。

但 DHT 的其他用途也是可能的，即它们可以存储签名的结构化数据、类似推文的文本 sn-ps 或其他任何东西。这始终取决于您的应用程序的需求。

这只是一个基本的构建块。