在我的新周末项目中,我决定从头开始编写一个 bittorrent 客户端,根本没有准备好使用库。经过两天寻找文档,我已经准备放弃 :smile:。我知道有 BEPs , 但他们还远远不足以理解所有规范。在阅读了更多之后,我认为跟踪器和对等协议(protocol)似乎很旧并且易于理解/实现(是的,我知道,要编写具有平衡、对等选择、优化的好代码,这并不像我刚才说的那样容易,但我只想做一些基础知识来学习,而不是与那里的数十个好客户竞争。)
所以,我决定从 DHT 开始,它似乎是更复杂的部分,而且文档也更少。当您停止寻找 bittorrent DHT 或主线 DHT 并开始寻找 kademlia DHT 时,您将获得更多信息,但如何将它们放在一起并不那么明显。
这是我目前的理解(还有我希望填补的空白):
- 我的 DHT 树是空的
- 在我的引导节点上使用
find_nodes
- 将接收到的节点添加到我自己的树中,这样我就可以选择更接近我自己 ID 的节点
- 开始向选定的节点发出
find_nodes
并将他们的响应添加到我的树 - 回到 3 直到我停止接收未知/新节点
- 如果我收到一个带有
info_hash
的announce_peer
,我应该将其信息保存在本地数据库中(发送者的 info_hash 和 ip/端口) - 如果一个节点使用
get_peers
和我在我的数据库中的info_hash
然后我发送信息否则我应该发送我自己的树中更近的节点列表(最接近那个 info_hash) - 当我在其他节点上使用
get_peers
时,我将收到对等节点或节点,在后一种情况下,我认为节点更接近info_hash
而不是我自己的nodeId
那么,我应该将这些节点添加到我的树中还是基于它们开始一棵新树? - 当我想宣布我对
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 背后的想法?
好吧,任何真实的文档、流程图,任何东西都会受到欢迎!
最佳答案
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 论文中找到。
关于bittorrent DHT 详细规范,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/44104242/