BT DHT协议规范

 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的请求。当一个