我从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)，将消息中继到......
问题：
key，但维基说：在现实世界中，密钥k可以是文件内容的散列 比文件名的哈希值提供内容可寻址存储， 所以重命名文件不会阻止用户找到它。
哈希文件的内容？我怎么知道文件的内容？如果我已经知道文件的内容，那么为什么我会在DHT中搜索它？
根据维基，每个参与节点都会留出一些空间来存储文件。这是否意味着，如果我参加DHT，我必须spare 10G disk space存储key falls into the specific key-space我负责的文件？
如果确实我应该节省一些磁盘空间来存储这些文件，那么我应该如何在磁盘上存储这些(key, file-content)？我的意思是，该文件应该安排在我的磁盘上的B-tree或其他东西吗？
当查询发生时，我的计算机如何响应？我假设，首先检查queried key，如果在我的key-space中，则在我的磁盘上找到corresponding file。右
答案 0 :(得分：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的其他用途也是可能的，即它们可以存储签名的结构化数据，类似推文的文本片段或其他内容。它总是取决于您的应用程序的需求。
这只是一个基本的构建块。