bittorrent DHT 详细规范
bittorrent DHT detailed specification
在我的新周末项目中，我决定从头开始编写一个 bittorrent 客户端，根本没有准备好使用库。经过两天寻找文档，我已经准备放弃 :smile:。我知道有 BEPs，但它们远远不足以理解所有规范。在阅读了更多之后，我认为跟踪器和对等协议似乎很旧并且很容易understand/implement（是的，我知道，写一个好的代码平衡，对等selection，优化，这是就像我刚才说的那样不容易，但我只想做基础知识来学习，而不是与那里的数十个好客户竞争。）
所以，我决定从 DHT 开始，它似乎是更复杂的部分，而且文档也更少。当您停止寻找 bittorrent DHT 或主线 DHT 并开始寻找 kademlia DHT 时，您将获得更多信息，但如何将它们放在一起并不那么明显。
以下是我目前的理解（还有不足之处希望能补上）：
- 我的 DHT 树是空的
- 在我的 bootstrap 节点上使用
find_nodes
- 将接收到的节点添加到我自己的树中，这样我就可以select更接近我自己的ID
- 开始向 selected 发布
find_nodes 并将他们的回复添加到我的树
- 返回 3 直到我停止接收 unknown/new 个节点
- 如果我收到带有
info_hash 的 announce_peer，我应该将其信息保存在本地数据库（发件人的 info_hash 和 ip/port）
- 如果一个节点使用
get_peers 和我在我的数据库中的 info_hash 然后我发送信息否则我应该发送我自己的树中更近的节点列表（最接近那个info_hash)
- 当我在其他节点上使用
get_peers 时，我将收到对等节点或节点，在后一种情况下，我认为节点更接近 info_hash 而不是我自己的 nodeId那么，我应该将这些节点添加到我的树中还是基于它们开始一个新树？
- 当我想宣布我对
info_hash 感兴趣时，我应该在所有地方使用 announce_peer 还是仅对 nodeId 更接近目标 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背后的想法，我应该放弃吗？
好吧，任何真实的文档、流程图，任何东西都会受到欢迎！
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: A Peer-to-peer Information System Based on the XOR Metric"。它在 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 分发的令牌的公告。
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 查找，完成后您通知最近的节点集返回了写入令牌并验证响应以确保您确实获得了 .如果是 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).
进行查找时，您不仅会访问路由 table 中的节点，还会访问响应中包含的节点。这使它们具有迭代性。每个节点的路由 table 偏向它们自己的 ID 确保响应包括越来越接近目标的邻居。
所以交易是你负责接近你的节点 ID 的信息，其他节点将提供接近你感兴趣的节点 ID 的信息。所以你的路由 table 布局服务于其他人，他们的路由 table 布局为您服务。
请注意，此答案中包含的所有信息都可以在 BEP 或 Kademlia 论文中找到。
在我的新周末项目中，我决定从头开始编写一个 bittorrent 客户端，根本没有准备好使用库。经过两天寻找文档，我已经准备放弃 :smile:。我知道有 BEPs，但它们远远不足以理解所有规范。在阅读了更多之后，我认为跟踪器和对等协议似乎很旧并且很容易understand/implement（是的，我知道，写一个好的代码平衡，对等selection，优化，这是就像我刚才说的那样不容易，但我只想做基础知识来学习，而不是与那里的数十个好客户竞争。）
所以，我决定从 DHT 开始，它似乎是更复杂的部分，而且文档也更少。当您停止寻找 bittorrent DHT 或主线 DHT 并开始寻找 kademlia DHT 时，您将获得更多信息，但如何将它们放在一起并不那么明显。
以下是我目前的理解（还有不足之处希望能补上）：
- 我的 DHT 树是空的
- 在我的 bootstrap 节点上使用
find_nodes - 将接收到的节点添加到我自己的树中，这样我就可以select更接近我自己的ID
- 开始向 selected 发布
find_nodes并将他们的回复添加到我的树 - 返回 3 直到我停止接收 unknown/new 个节点
- 如果我收到带有
info_hash的announce_peer，我应该将其信息保存在本地数据库（发件人的 info_hash 和 ip/port） - 如果一个节点使用
get_peers和我在我的数据库中的info_hash然后我发送信息否则我应该发送我自己的树中更近的节点列表（最接近那个info_hash) - 当我在其他节点上使用
get_peers时，我将收到对等节点或节点，在后一种情况下，我认为节点更接近info_hash而不是我自己的nodeId那么，我应该将这些节点添加到我的树中还是基于它们开始一个新树？ - 当我想宣布我对
info_hash感兴趣时，我应该在所有地方使用announce_peer还是仅对nodeId更接近目标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背后的想法，我应该放弃吗？
好吧，任何真实的文档、流程图，任何东西都会受到欢迎！
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: A Peer-to-peer Information System Based on the XOR Metric"。它在 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 分发的令牌的公告。
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 查找，完成后您通知最近的节点集返回了写入令牌并验证响应以确保您确实获得了 .如果是 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).
进行查找时，您不仅会访问路由 table 中的节点，还会访问响应中包含的节点。这使它们具有迭代性。每个节点的路由 table 偏向它们自己的 ID 确保响应包括越来越接近目标的邻居。
所以交易是你负责接近你的节点 ID 的信息，其他节点将提供接近你感兴趣的节点 ID 的信息。所以你的路由 table 布局服务于其他人，他们的路由 table 布局为您服务。
请注意，此答案中包含的所有信息都可以在 BEP 或 Kademlia 论文中找到。