我读过 Kademlia 的文章，了解了它的基本概念。BitTorrent 的基本概念也很简单。但如果把这两者放在一起，就完全没有意义了。
从我在网上找到的信息来看，目标文件的文件哈希用于生成目标 ID 以在 DHT 中查找，然后该查找应该会找到接近目标 ID 的对等点。好的，说得通。但事实并非如此，具有接近目标 ID 的 ID 的对等点如何知道网络上的种子或其他对等点的任何信息？
任何研究相关性的尝试都会得出相同的解释，即 DHT 算法使用其 Kademlianess 来找到对等方 id 接近目标 id 的对等方，但这并不能回答问题。
答案1
据我了解，“具有目标 ID 的对等点”知道种子或其他对等点，因为这些对等点也使用完全相同的程序来店铺在该位置的有关他们自己的信息。具有该 ID 的对等点只是所有其他对等点都同意的一个位置，用于存储/检索与某事或其他事相关的数据。
DHT 是一个“分布式哈希表”，其中“哈希表“表示存储{键⇒值}映射的数据结构（也称为字典、关联数组、查找表等）。使用哈希表的程序可以放入（键，值）并且哈希表将{key⇒value}信息存储在地址X处；然后程序的不同部分可以获取（键）并且哈希表从地址 X 检索值。
当在程序中使用典型的哈希表时，它会使用类似的过程在存储给定的查找键（哈希）时为其生成内存位置，并在需要检索时执行相同的操作。数据库、文件系统、Git 等也在各个级别执行相同的操作；例如 Git 的 .git/objects/。
DHT 也一样，只是在网络层面（“分布式”部分）。虽然 BitTorrent 的 DHT 知道一些 BT 特有的东西，但从根本上讲，它仍然只是将 BitTorrent 客户端需要存储在约定位置的数据存储在其中。正如 Kad 规范所述：
为了存储<键，值>对，参与者定位...
这意味着，一般来说，它可以集成到这样的文件共享协议中：
源节点 S（拥有该文件）计算 ID 并通过 DHT 网络发送“存储”操作，存储信息 {key: fileID ⇒ value: “在节点 S 处可用”}，该信息发送到最接近该键（fileID）的节点 X。
然后将信息 {key: fileID ⇒ value: “在节点 S 处可用”} 存储在节点 X 处。
另一个对等/客户端节点 C 了解该文件的 ID，并通过 DHT 网络发送“检索”操作，该操作从节点 X 检索“在节点 S 处可用”的值。
这BitTorrent DHT实现方式与该示例类似，只调用了“存储”操作announce_peer，并且它不会完全覆盖该值，而只是将播音员的数据添加到已存储的对等体列表中。