BitTorrent Trackerless DHT协议规范V1.0试行草案
一直以来我都有一个疑问: 一个新加入的BT客户端如何得到其他BT客户端的IP地址和端口?
如果所有的BT客户端地址都保存在BT服务器的话似乎又走CS结构的老路了,而且需要数据库支持.
以下这篇文章难道就是答案?
BitTorrent Trackerless DHT协议规范V1.0试行草案
DHT 协议
摘自 BitTorrentDev
BitTorrent 使用一个"分布式sloppy哈希表" (DHT)来为"trackerless"流存储peer联系信息。有效地使每个peer都成了一个tracker，这个协议基于Kademila网络并且在UDP上实现。
请注意本文档中使用的术语，以免混乱。"peer"是在一个TCP端口上监听的一个客户端/服务器，它实现了BitTorrent协议。"节点"是在一个UDP端口上监听的一个客户端/服务器，它实现了分布式哈希表协议。DHT由节点组成，它存储了peer的位置。BitTorrent客户端包含一个DHT节点，这个节点是用来联系DHT中其他节点以得到peer的位置，从而通过BitTorrent协议下载。
内容
· 1 概述
· 2 路由表
· 3 BitTorrent协议扩展
· 4 Torrent文件扩展
· 5 KRPC协议
o 5.1 Contact Encoding
o 5.2 Queries
o 5.3 Responses
o 5.4 Errors
§ 5.4.1错误包例子
· 6 DHT请求
o 6.1 ping
§ 6.1.1包例子
o 6.2 find_node
§ 6.2.1包例子
o 6.3 get_peers
§ 6.3.1包例子
o 6.4 announce_peer
§ 6.4.1包例子
· 7脚注
概述
每个节点有一个全局唯一的标识符，称为"节点ID"。节点ID是从一个160位空间随机选择的，这个空间同样用来表示BitTorrent infohash。"米制距离"用来比较两个节点ID之间或者一个节点ID和一个infohash之间的"远近"。节点必须维护一个含有少量其它节点联系信息的路由表。ID越靠近节点本身的ID时，路由表越详细。节点知道DHT中很多ID离自己很"近"的节点的联系信息，而离自己非常远的ID的联系信息却很少。
在Kademlia网络中，米制距离是异或计算的，结果视为无符号整数。
distance(A,B) = |A ⊗ B| ，值越小表示越近。
当节点要为流寻找peer时，它使用米制距离来比较那些ID在自己路由表中节点的流的infohash。然后它联系它所知的ID离infohash最近的节点，问它们正在下载这个流的peer的联系信息。如果一个被联系的节点知道下载这个流的peer信息，那个peer的联系信息将随着回复信息被返回。否则，那个被联系的节点必须回复在它路由表中离流的infohash最近的节点的联系信息。最初的节点重复地请求比目标infohash更近的节点直道不能再找到更近的节点为止。查询完了之后，客户端把peer联系信息加入到所有回复节点中ID离流最近的那个节点中。
请求peer的返回值包含一个不透明的值，称之为"令牌"。为了一个节点宣布它所控制的peer正在下载一个流，它必须赠送从同一个被请求的节点收到的令牌给新来的寻找peer的请求。当一个节点试图"宣布"一个流时，被请求的节点核对令牌和发出请求的节点的IP地址。这是为了防止恶意的主机雇用其它主机。由于令牌仅仅由请求节点返回给收到令牌的同一个节点，所以执行未被定义。令牌在被分布之后必须在一个合理数量的时间被接受。BitTorrent执行使用每五分钟变换一次以保持连接秘密的IP地址的SHA1哈希，和接受十分钟以内旧的令牌。
路由表
每个节点维护一个已知的好的节点路由表。路由表中的节点是用来作为在DHT中请求的起始点。路由表中的节点以回复的形式被返回给其它发出请求节点。
不是所有我们学习的的节点都是相等的。一些是"好的"一些不是。使用DHT的许多节点能够发送请求和接受回复，但是不能回复来自其它节点的请求。节点的路由表必须只包含已知的好的节点，这是很重要的。一个好的节点是一个在过去15分钟内回复过其中一个我们的请求的一个节点。一个节点如果在过去15分钟内曾经回复过其中一个我们的请求，而且发送过一个请求给我们。一个节点静止15分钟以后，变成可疑的。当未能回复连续多个请求时节点变成坏的。我们知道好的节点被给于高于未知状态的节点优先权。
