1

我正在研究 Mainline DHT，但我不了解其中的细微差别。

此处：https ://www.bittorrent.org/beps/bep_0005.html写道：““距离度量”用于比较两个节点 ID 或节点 ID 和“接近度”的信息哈希。

还写道：“宣布控制查询节点的对等点正在端口上下载种子。announce_peer 有四个参数：“id”包含查询节点的节点 ID，“info_hash”包含种子的信息哈希， “端口”包含作为整数的端口，以及为响应先前的 get_peers 查询而收到的“令牌”。”

因此，例如，我们有一个 ID 为 223456789zxcvbnmasdf 的对等点，其 IP 为 86.23.145.714，端口为：7853 我知道该对等点下载了 2 个带有信息哈希的种子文件：023456789zxcvbnmasdf 和 123456789zxcvbnmasdf。

那么我的 k-bucket 记录应该是什么样子的呢？像这样：

{"id": "223456789zxcvbnmasdf", "ip": "86.23.145.714", "port": "7853", "torrents": ["023456789zxcvbnmasdg", "123456789zxcvbnmasdh"]} ?

或者 torrent 文件是否应该像 k-buckets 中的“等效”记录（具有重复的 ips 和端口）以及对等点：

{"id": "223456789zxcvbnmasdf", "ip": "86.23.145.714", "port": "7853"},

{"id": "023456789zxcvbnmasdg", "ip": "86.23.145.714", "port": "7853"},

{"id": "123456789zxcvbnmasdh", "ip": "86.23.145.714", "port": "7853"} ?

我问是因为这不仅仅是实现的细微差别。因为“k”在所有客户端中通常是 20 或其他整数。因此，如果我使用 k-buckets 将 torrent 文件存储为完全权限成员，我将有更少的空间来存储真实的对等数据。

感谢您的回答！

4

2 回答 2

1

如何在内部构建数据取决于您。它所要做的就是履行规范的合同。原则上，可以根据异或距离将 torrent 与存储桶相关联——例如，出于资源核算的原因——但大多数实现将路由表和存储分开。

主路由表仅包含节点，即 DHT 覆盖本身的结构成员。另一方面，种子不是覆盖的一部分。它们是存储在覆盖层（哈希表抽象）之上的数据。因此得名分布式哈希表。即它们存在于不同的抽象级别。

于 2019-05-30T11:44:41.437 回答
0

k-buckets 数据结构是 bit-torrent 协议的一个实现细节，以便对等方足够快地回复FIND_PEERS和FIND_VALUE.

我在我的 kademlia 实现中所做的是将路由表保存在 python 字典中，默认情况下，我会在 5 秒内计算最近的对等点，这是我用来等待 UDP 回复的超时。为此，我需要将路由表保持在 1 000 000 个条目以下。

就像我上面说的，路由表是一个简单的 pythondict映射peerid到(address, port).

路由表存储对等点而不是值，即。不是infohash地址。

当我收到一条FIND_PEERS消息时，程序会回复以下代码：

async def peers(self, address, uid):
    """Remote procedure that returns peers that are near UID"""
    log.debug("[%r] find peers uid=%r from %r", self._uid, uid, address)
    # XXX: if this takes more than 5 seconds (see RPCProtocol) it
    # will timeout in the other side.
    uids = nearest(self._replication, self._peers.keys(), uid)
    out = [self._peers[x] for x in uids]
    return out

当我收到一条FIND_VALUE消息时，程序会回复以下代码：

async def value(self, address, key):
    """Remote procedure that returns the associated value or peers that
    are near KEY"""
    log.debug("[%r] value key=%r from %r", self._uid, key, address)
    out = await lookup(key)
    if out is None:
        # value is not found, reply with peers that are near KEY
        out = nearest(self._replication, self._peers.keys(), uid)
        return (b"PEERS", out)
    else:
        return (b"VALUE", out)

这是 的定义nearest：

def nearest(k, peers, uid):
    """Return K nearest to to UID peers in PEERS according to XOR"""
    # XXX: It only works with len(peers) < 10^6 more than that count
    # of peers and the time it takes to compute the nearest peers will
    # timeout after 5 seconds on the other side. See RPCProtocol and
    # Peer.peers.
    return nsmallest(k, peers, key=functools.partial(operator.xor, uid))

也就是说，它peers根据它们对它们进行排序peerid并返回k最小的。nsmallest应该是sort(peers, key=functools.partial(operator.xor, uid))[:k]where uidis a peeridor infohash（分别是FIND_PEERSand FIND_VALUE）的优化版本。

现在回到你的问题：

hashinfo 是否等同于 Mainline DHT 中的对等 ID？

hashinfo是一个哈希值，它与peeridie 的哈希值相同。它们是路由表中可能的键。也就是说，torrent 文件与散列相关联，对等点与称为peerid. 并且对等点拥有其附近的密钥的“所有权” peerid。但是hashinfo，如果您愿意，它不会存储在路由表或 k-buckets 中。hashinfo存储在另一个将hashinfo散列与其值相关联的映射中。

我问是因为这不仅仅是实现的细微差别。因为“k”在所有客户端中通常是 20 或其他整数。因此，如果我使用 k-buckets 将 torrent 文件存储为完全权限成员，我将有更少的空间来存储真实的对等数据。

这里对我在上面尝试解释的同一件事存在误解。hashinfo是存储字典中的键。而peerid路由表中的键又名。k-buckets 数据结构。它们都具有相同的格式，因为这就是 kademlia 路由算法的工作方式。您必须能够hashinfo与peeridwithxor进行比较才能判断哪些对等方“拥有”哪个hashinfo值。

正如您在第二个片段中看到的那样，当另一个对等方请求与哈希关联的值时，它会调用lookup(key)类似的东西，storage.get(key)除了在我的情况下，代码将值存储在数据库中。

可能对 k-buckets 用于存储DHT 路由信息这一事实存在误解。最重要的是，torrent 协议使用 DHT 来存储torrent路由信息。

值得一提的是，qadom 的 peer.py 文件是我实现受 kademlia 启发的 DHT 的地方（除了我使用 256 位哈希和放弃alpha和k参数并使用单个REPLICATION参数）。该代码大部分时间都在检查测试。

另外，我从另一个项目中获得灵感，叫做简单的 kademlia，它（尝试？）实现 k-buckets。

据我了解，Torrent DHT 路由看起来像qadombag功能，除了接收对等方必须对公告进行身份验证，而在 qadom 中，包是免费的。

另外，请查看原始的 kademlia 论文。

于 2019-05-30T13:06:17.197 回答