bittorrent DHT 详细规范

Question

在我的新周末项目中，我决定从头开始编写一个 bittorrent 客户端，根本没有准备好使用库。经过两天寻找文档，我已经准备放弃 :smile:。我知道有 BEPs , 但他们还远远不足以理解所有规范。在阅读了更多之后，我认为跟踪器和对等协议(protocol)似乎很旧并且易于理解/实现(是的，我知道，要编写具有平衡、对等选择、优化的好代码，这并不像我刚才说的那样容易，但我只想做一些基础知识来学习，而不是与那里的数十个好客户竞争。)

所以，我决定从 DHT 开始，它似乎是更复杂的部分，而且文档也更少。当您停止寻找 bittorrent DHT 或主线 DHT 并开始寻找 kademlia DHT 时，您将获得更多信息，但如何将它们放在一起并不那么明显。

这是我目前的理解(还有我希望填补的空白):

1. 我的 DHT 树是空的
2. 在我的引导节点上使用find_nodes
3. 将接收到的节点添加到我自己的树中，这样我就可以选择更接近我自己 ID 的节点
4. 开始向选定的节点发出find_nodes并将他们的响应添加到我的树
5. 回到 3 直到我停止接收未知/新节点
6. 如果我收到一个带有 info_hash 的 announce_peer，我应该将其信息保存在本地数据库中(发送者的 info_hash 和 ip/端口)
7. 如果一个节点使用 get_peers 和我在我的数据库中的 info_hash 然后我发送信息否则我应该发送我自己的树中更近的节点列表(最接近那个 info_hash)
8. 当我在其他节点上使用 get_peers 时，我将收到对等节点或节点，在后一种情况下，我认为节点更接近 info_hash 而不是我自己的 nodeId 那么，我应该将这些节点添加到我的树中还是基于它们开始一棵新树？
9. 当我想宣布我对 info_hash 感兴趣时，我应该在所有地方使用 announce_peer 还是只在靠近 nodeId 的节点上使用 announce_peer目标 info_hash？距离足够近多少？

此时我有很多节点的 ID 更接近我自己的 ID，关于 info_hash 的信息我不是很感兴趣。

恐怕我有一个巨大的愚蠢问题:我为什么要那样做？

我的意思是:我做所有这些工作的自私原因是为了找到我感兴趣的 info_hash 的同行。我理解一个 info_hash 的信息很可能保存在 ID 更接近该 info_hash 的节点上.因此，如果我创建一个更接近 info_hash 而不是更接近我自己的 ID 的节点树，我找到它的信息的机会就更大(在这一点上，如果你知道这个主题，你已经注意到我是多么迷茫)。

我应该创建多棵树吗？一个给我(用来保存 info_hashes 的信息更接近人们发送给我的 nodeID)，另一个树更接近我的每个目标 info_hashes 以便我可以检索它们的信息？

我是否应该创建一个更接近我的节点 ID 的树，并希望在查询这棵树以获取我需要的 info_hashes 时最好？

我是否应该放弃，因为我完全误解了 DHT 背后的想法？

好吧，任何真实的文档、流程图，任何东西都会受到欢迎!

Answer 1

So, I have decided to start by the DHT which seems to the the more complex part and also the less documented.

需要阅读由 Peter Maymounkov 和 David Mazieres 撰写的原始 kademlia 论文“Kademlia:基于 XOR 度量的点对点信息系统”。它在 BEP-5 中很早就被引用

if I receive an announce_peer with an info_hash than I should save its information on a local DB (the info_hash and ip/port of the sender)

您只接受包含先前通过 get_peers 分发的 token 的公告。

when I use get_peers on other nodes I will receive peers or nodes, in the later case I think the nodes are closer to the info_hash and not to my own nodeId so, should I add these nodes to my tree or start a new tree based on them?

您使用临时树 - 或按相对于目标 ID 的联系人 ID 排序的列表 - 进行迭代查找，因为它们与您的节点 ID 不平衡。

when I want to announce I am interested on an info_hash should I use announce_peer everywhere or just to the nodes with nodeId closer to the target info_hash? How much is closer enough?

您执行 get_peers 查找，完成后您向 𝑲 最接近的节点集宣布返回写入 token 并验证响应以确保您确实获得 𝑲。在 bittorrent 𝑲 = 8 的情况下。

my selfish reason to do all this work is to locate peers to the info_hash I'm interested in. I understand that the information of one info_hash is likely to be saved on a node which ID is closer to that info_hash. So my chances to find its information is bigger if I create a tree of nodes closer to the info_hash and not closer to my own ID (at this point, if you know the subject, you already noticed how lost I am).

在进行查找时，您不仅会访问路由表中的节点，还会访问响应中包含的节点。这使它们具有迭代性。每个节点的路由表都偏向于它们自己的 ID，确保响应包括越来越接近目标的邻居。

所以交易是您负责接近您的节点 ID 的信息，而其他节点将提供接近您感兴趣的节点 ID 的信息。因此您的路由表布局为他人服务，他们的路由表布局为您服务。

请注意，此答案中包含的所有信息都可以在 BEP 或 Kademlia 论文中找到。