bittorrent DHT详细规范

时间:2017-05-22 03:31:25

标签: bittorrent dht kademlia

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

所以,我决定从DHT开始,这似乎是更复杂的部分,也是较少记录的。当你停止寻找bittorrent DHT或主线DHT并开始寻找kademlia DHT时,你会得到更多的信息,但是如何将它们放在一起并不是那么明显。

这是我到目前为止所理解的(我希望填补空白):

  1. 我从我的DHT树空开始
  2. 在我的引导程序节点上使用find_nodes
  3. 将收到的节点添加到我自己的树中,这样我就可以选择更接近我自己ID的
  4. 开始向所选的find_nodes发布announce_peer并将其回复添加到我的树
  5. 返回3直到我停止接收未知/新节点
  6. 如果我收到info_hash get_peers而不是我应该将信息保存在本地数据库(发件人的info_hash和ip /端口)
  7. 如果一个节点使用info_hash我的数据库中有get_peers,那么我发送信息,否则我应该发送一个我自己的树中最近的节点列表(最接近那个info_hash)
  8. 当我在其他节点上使用info_hash时,我将收到对等点或节点,在后一种情况下,我认为节点更接近nodeId而不是我自己的info_hash所以,我应该将这些节点添加到我的树中还是根据它们开始一个新树?
  9. 当我想宣布我对announce_peer感兴趣时,我应该在任何地方使用nodeId,还是仅使info_hash更接近目标sudo snort -dev -n 20 -l /home/hduser/log9 -b -c /etc/snort5/snort.conf sudo chmod a+rwx /home/hduser/log9/snort.log.* sudo tcpdump -n -tttt -r /home/hduser/log9/snort.log.* > /home/hduser/log9/bigfile2.txt 的节点?多少足够接近?
  10. 此时我有很多节点,哪些ID更接近我自己的ID,以及有关info_hash的信息,我对此并不感兴趣。

    我担心我有一个巨大的愚蠢问题:为什么我这样做?

    我的意思是:我完成所有这些工作的自私理由是找到我感兴趣的info_hash的同伴。我明白一个info_hash的信息可能会保存在ID更接近的节点上那个info_hash。因此,如果我创建一个更靠近info_hash的节点树而不是更接近我自己的ID,那么我找到其信息的机会就更大了(此时,如果你知道这个主题,你已经注意到我有多失落)。

    我应该创建多个树吗?一个对我来说(在那里保存info_hashes的信息更接近我的nodeID人们发送给我),和其他树更接近我的每个目标info_hashes所以我可以检索他们的信息?

    我是否应该创建一个更接近我的节点ID的单个树,并希望在查询此树以获得我需要的info_hashes时获得最佳效果?

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

    嗯,任何真实的文档,流程图,欢迎任何事情!

1 个答案:

答案 0 :(得分:3)

  

所以,我已经决定从DHT开始,这似乎是更复杂的部分,而且记录的更少。

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

  

如果我收到带有info_hash的announce_peer,那么我应该将其信息保存在本地数据库(发件人的info_hash和ip / port)上

您只接受包含之前通过get_peers分发的令牌的通知。

  

当我在其他节点上使用get_peers时,我将接收对等体或节点,在后一种情况下,我认为节点更靠近info_hash而不是我自己的nodeId所以,我应该将这些节点添加到我的树中还是开始一个新节点基于它们的树?

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

  

当我想宣布我对info_hash感兴趣时,我应该在任何地方使用announce_peer,还是只使用nodeId更接近目标info_hash的节点?多少足够接近?

您执行get_peers查找,一旦完成,您就会向最近的节点集宣布返回写令牌并验证响应以确保您真正获得。如果bittorrent = 8。

  

我完成所有这些工作的自私理由是找到我感兴趣的info_hash的同伴。我明白一个info_hash的信息可能会保存在ID更接近该info_hash的节点上。因此,如果我创建一个更靠近info_hash的节点树而不是更接近我自己的ID,那么我找到其信息的机会就更大了(此时,如果你知道这个主题,你已经注意到我有多失落)。

进行查找时,您不仅访问路由表中的节点,还可以访问响应中包含的节点。这使它们迭代。每个节点的路由表对其自己的ID的偏差确保了响应包括越来越靠近目标的邻居。

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

请注意,此答案中包含的所有信息均可在BEP或Kademlia文件中找到。