一直以来我都有一个疑问:一个新加入的BT客户端如何得到其他BT客户端的IP地址和端口?如果所有的BT客户端地址都保存在BT服务器的话似乎又走CS结构的老路了,而且需要数据库支持.以下这篇文章难道就是答案?BitTorrentTrackerlessDHT协议规范V1.0试行草案DHT协议摘自BitTorrentDevBitTorrent使用一个"分布式sloppy哈希表"(DHT)来为"trackerless"流存储peer联系信息。有效地使每个peer都成了一个tracker，这个协议基于Kademila网络并且在UDP上实现。请注意本文档中使用的术语，以免混乱。"peer"是在一个TCP端口上监听的一个客户端/服务器，它实现了BitTorrent协议。"节点"是在一个UDP端口上监听的一个客户端/服务器，它实现了分布式哈希表协议。DHT由节点组成，它存储了peer的位置。BitTorrent客户端包含一个DHT节点，这个节点是用来联系DHT中其他节点以得到peer的位置，从而通过BitTorrent协议下载。内容·1概述·2路由表·3BitTorrent协议扩展·4Torrent文件扩展·5KRPC协议o5.1ContactEncodingo5.2Querieso5.3Responseso5.4Errors§5.4.1错误包例子·6DHT请求o6.1ping§6.1.1包例子o6.2find_node§6.2.1包例子o6.3get_peers§6.3.1包例子o6.4announce_peer§6.4.1包例子·7脚注概述每个节点有一个全局唯一的标识符，称为"节点ID"。节点ID是从一个160位空间随机选择的，这个空间同样用来表示BitTorrentinfohash。"米制距离"用来比较两个节点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分钟以后，变成可疑的。当未能回复连续多个请求时节点变成坏的。我们知道好的节点被给于高于未知状态的节点优先权。路由表覆盖了ID空间从0到2^160的全部节点。路由表被细分为"桶"，每个桶覆盖一部分ID空间。一个空表有一个桶，其ID空间范围是min=0，max=2^160。当一个ID为"N"的节点被插入到表中时，它被放置在min<=N<max的桶中。一个空表只有一个桶所以任何节点必须适合放在其中。在变成"满"以前，每个桶只能装K个节点，确切的说是八个。当一个桶装满了已知的好的节点后，没有更多的节点可以加入，除非我们自