种子中的 DHT
我正在编写一个 P2P 实现，我希望将其去中心化。然而，我在理解 BitTorrent 等协议中的 DHT 工作原理时遇到了一些困难。
如果没有跟踪器，客户端如何知道对等点在哪里？对等点是否存储在实际的 torrent 文件中？
I'm coding a P2P implementation that I would like to make decentralized. However I'm having some trouble grasping how DHT in protocols like BitTorrent works.
How does the client know where the peers are if there is no tracker? Are peers stored in the actual torrent file?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
对于无跟踪器/DHT 种子，对等 IP 地址使用 BitTorrent infohash 作为密钥存储在 DHT 中。由于跟踪器所做的基本上就是响应 put/get 请求，因此此功能与 DHT（分布式哈希表）提供的接口完全对应：它允许您通过 infohash 在 DHT 中查找和存储 IP 地址。
因此，“get”请求将查找 BT infohash 并返回一组 IP 地址。 “put”存储给定 infohash 的 IP 地址。这对应于您向跟踪器发出的“宣布”请求，以接收对等 IP 地址的字典。
在 DHT 中，对等点被随机分配来存储属于密钥空间一小部分的值；散列确保密钥在参与的对等点之间随机分布。 DHT 协议（Kademlia 用于 BitTorrent）确保 put/get 请求有效地路由到负责的对等点用于维护给定密钥的 IP 地址列表。
With trackerless/DHT torrents, peer IP addresses are stored in the DHT using the BitTorrent infohash as the key. Since all a tracker does, basically, is respond to put/get requests, this functionality corresponds exactly to the interface that a DHT (distributed hash table) provides: it allows you to look up and store IP addresses in the DHT by infohash.
So a "get" request would look up a BT infohash and return a set of IP addresses. A "put" stores an IP address for a given infohash. This corresponds to the "announce" request you would otherwise make to the tracker to receive a dictionary of peer IP addresses.
In a DHT, peers are randomly assigned to store values belonging to a small fraction of the key space; the hashing ensures that keys are distributed randomly across participating peers. The DHT protocol (Kademlia for BitTorrent) ensures that put/get requests are routed efficiently to the peers responsible for maintaining a given key's IP address lists.
一般理论可以在维基百科关于 Kademlia 的文章中找到。 bittorrent使用的具体协议规范在这里：http://wiki.theory.org/BitTorrentDraftDHTProtocol
The general theory can be found in wikipedia's article on Kademlia. The specific protocol specification used in bittorrent is here: http://wiki.theory.org/BitTorrentDraftDHTProtocol
bittorrent 和 DHT 的情况是，在开始时，bittorrent 使用 torrent 文件中嵌入的信息从 DHT 转到跟踪器或一组节点之一。然后，一旦它找到一个节点，它就可以继续寻找其他节点并持续使用 DHT，而不需要集中式跟踪器来维护它。
原始信息引导后续 DHT 的使用。
What happens with bittorrent and a DHT is that at the beginning bittorrent uses information embedded in the torrent file to go to either a tracker or one of a set of nodes from the DHT. Then once it finds one node, it can continue to find others and persist using the DHT without needing a centralized tracker to maintain it.
The original information bootstraps the later use of the DHT.
DHT 节点具有唯一标识符，称为节点 ID。节点 ID 是从与 BitTorrent 信息哈希相同的 160 位空间中随机选择的。紧密程度是通过比较节点 ID 的路由表来衡量的，节点越接近，越详细，从而产生最优结果，
然后使它们比使用简单无符号整数的前身“Kademlia”更最优：距离（A，B）= |A xor乙|值越小越接近。异或。除了不安全之外，它的逻辑也存在缺陷。
如果您的客户端支持 DHT，则保留 8 个字节，其中包含 0x09，后跟带有 UDP 端口和 DHT 节点的 2 字节有效负载。如果握手成功，上述过程将继续。
DHT nodes have unique identifiers, termed, Node ID. Node IDs are chosen at random from the same 160-bit space as BitTorrent info-hashes. Closeness is measured by comparing Node ID's routing tables, the closer the Node, the more detailed, resulting in optimal
What then makes them more optimal than it's predecessor "Kademlia" which used simple unsigned integers: distance(A,B) = |A xor B| Smaller values are closer. XOR. Besides not being secure, its logic was flawed.
If your client supports DHT, there are 8-bytes reserved in which contains 0x09 followed by a 2-byte payload with the UDP Port and DHT node. If the handshake is successful the above will continue.