hashinfo 是否等同于 Mainline DHT 中的 peer ID？
Is hashinfo equivalent to peer ID in Mainline DHT?
我正在研究 Mainline DHT，但我不明白任何细微差别。
此处：https://www.bittorrent.org/beps/bep_0005.html 写道："A "distance metric" 用于比较两个节点 ID 或节点 ID 和 "closeness."
的信息哈希
还写："Announce that the peer, controlling the querying node, is downloading a torrent on a port. announce_peer has four arguments: "id”包含查询节点的节点 ID，"info_hash" 包含 torrent 的信息哈希，"port" 包含作为整数的端口，以及"token" 收到对先前 get_peers 查询的响应。"
因此，例如，我们有一个 ID 为 223456789zxcvbnmasdf 的对等点，其 IP 为 86.23.145.714，端口为：7853
我知道这个同行下载了 2 个带有信息哈希的 torrent 文件：023456789zxcvbnmasdf 和 123456789zxcvbnmasdf。
那么我的 k-bucket 记录应该是什么样子的？
像这样：
{"id": "223456789zxcvbnmasdf", "ip": "86.23.145.714", "port": "7853", "torrents": ["023456789zxcvbnmasdg", "123456789zxcvbnmasdh"]} ?
或者 torrent 文件应该像 k-buckets 中的 "equivalent" 记录（具有重复的 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 文件存储为全权成员，我将更少 space 来存储真实的对等数据。
感谢解答！
如何在内部构建数据由您决定。它所要做的就是履行规范的约定。原则上，可以根据异或距离将种子与桶相关联——例如出于资源统计的原因——但大多数实现将路由 table 和存储分开。
主路由table只包含节点，DHT覆盖本身的结构成员。另一方面，种子不是覆盖的一部分。它们是存储在覆盖层之上的数据，散列 table 抽象。因此得名，分布式哈希 Table。 IE。它们存在于不同的抽象层次上。
k-buckets 数据结构是 bit-torrent 协议的一个实现细节，因此对等节点可以足够快地回复 FIND_PEERS 和 FIND_VALUE.
我在我的 kademlia 实现中所做的是将路由 table 保存在 python 字典中，并且我在默认情况下计算 5 秒内最近的对等点，这是我使用的超时等待 UDP 回复。为此，我需要将路由 table 保持在 1 000 000 个条目以下。
就像我上面说的，路由 table 是一个简单的 python dict 映射 peerid 到 (address, port)。
路由 table 存储对等点而不是值，即。不是 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))
也就是说，它根据 peerid 和 return 最小的 k 对 peers 进行排序。 nsmallest 应该是 sort(peers, key=functools.partial(operator.xor, uid))[:k] 的优化版本，其中 uid 是 peerid 或 infohash（分别是 FIND_PEERS 和 FIND_VALUE ).
现在回到你的问题：
Is hashinfo equivalent to peer ID in Mainline DHT?
hashinfo 是一个 hash-something，它与 peerid 是同一种哈希，即。它们是路由 table 中的 可能 键。也就是说，torrent 文件与哈希相关联，对等点与称为 peerid 的相同类型的哈希相关联。同龄人拥有 "ownership" 个靠近其 peerid 的键。但是 hashinfo 不会存储在路由 table 或 k-buckets 中（如果您愿意）。 hashinfo 存储在另一个映射中，该映射将 hashinfo 散列与其值相关联。
I am asking because this is not just implementation nuance. Because "k" is normally 20 or some other integer in all clients. So if I would use k-buckets to store torrent files as full-right members, I would have less space to store real peers data.
这里有 mis-understanding 关于我在上面解释的相同内容。 hashinfo 是存储字典中的键。而 peerid 又名路由 table 中的键。 k-buckets 数据结构。它们都具有相同的格式，因为这就是 kademlia 路由算法的工作方式。您必须能够将 hashinfo 与 peerid 与 xor 进行比较，以便能够分辨出哪些同行 "own" 哪些 hashinfo 值。
正如您在第二个片段中看到的那样，当另一个对等点请求与哈希关联的值时，它调用 lookup(key) 类似于 storage.get(key) 除了在我的例子中代码存储数据库中的值。
也许有一个mis-understanding关于k-buckets用于存储DHT路由信息的事实。 在之上，torrent协议使用DHT存储torrent路由信息。
对于它的价值，qadom's peer.py file 是我实现受 kademlia 启发的 DHT 的地方（除了我使用 256 位散列并放弃 alpha 和 k 参数并使用单个REPLICATION 参数）。代码在大部分时间都有效检查测试。
此外，我从另一个名为 kademlia 的项目中获得灵感，它（尝试？）实现 k-buckets.
据我所知，torrent DHT 路由看起来像 qadom bag functions 除了接收端必须验证公告，而在 qadom 包中是 free-for-all.
另外，查看原始的 kademlia 论文。
我正在研究 Mainline DHT，但我不明白任何细微差别。
此处：https://www.bittorrent.org/beps/bep_0005.html 写道："A "distance metric" 用于比较两个节点 ID 或节点 ID 和 "closeness."
的信息哈希还写："Announce that the peer, controlling the querying node, is downloading a torrent on a port. announce_peer has four arguments: "id”包含查询节点的节点 ID，"info_hash" 包含 torrent 的信息哈希，"port" 包含作为整数的端口，以及"token" 收到对先前 get_peers 查询的响应。"
因此，例如，我们有一个 ID 为 223456789zxcvbnmasdf 的对等点，其 IP 为 86.23.145.714，端口为：7853 我知道这个同行下载了 2 个带有信息哈希的 torrent 文件：023456789zxcvbnmasdf 和 123456789zxcvbnmasdf。
那么我的 k-bucket 记录应该是什么样子的？ 像这样：
{"id": "223456789zxcvbnmasdf", "ip": "86.23.145.714", "port": "7853", "torrents": ["023456789zxcvbnmasdg", "123456789zxcvbnmasdh"]} ?
或者 torrent 文件应该像 k-buckets 中的 "equivalent" 记录（具有重复的 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 文件存储为全权成员，我将更少 space 来存储真实的对等数据。
感谢解答！
如何在内部构建数据由您决定。它所要做的就是履行规范的约定。原则上，可以根据异或距离将种子与桶相关联——例如出于资源统计的原因——但大多数实现将路由 table 和存储分开。
主路由table只包含节点，DHT覆盖本身的结构成员。另一方面，种子不是覆盖的一部分。它们是存储在覆盖层之上的数据，散列 table 抽象。因此得名，分布式哈希 Table。 IE。它们存在于不同的抽象层次上。
k-buckets 数据结构是 bit-torrent 协议的一个实现细节，因此对等节点可以足够快地回复 FIND_PEERS 和 FIND_VALUE.
我在我的 kademlia 实现中所做的是将路由 table 保存在 python 字典中，并且我在默认情况下计算 5 秒内最近的对等点，这是我使用的超时等待 UDP 回复。为此，我需要将路由 table 保持在 1 000 000 个条目以下。
就像我上面说的，路由 table 是一个简单的 python dict 映射 peerid 到 (address, port)。
路由 table 存储对等点而不是值，即。不是 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))
也就是说，它根据 peerid 和 return 最小的 k 对 peers 进行排序。 nsmallest 应该是 sort(peers, key=functools.partial(operator.xor, uid))[:k] 的优化版本，其中 uid 是 peerid 或 infohash（分别是 FIND_PEERS 和 FIND_VALUE ).
现在回到你的问题：
Is hashinfo equivalent to peer ID in Mainline DHT?
hashinfo 是一个 hash-something，它与 peerid 是同一种哈希，即。它们是路由 table 中的 可能 键。也就是说，torrent 文件与哈希相关联，对等点与称为 peerid 的相同类型的哈希相关联。同龄人拥有 "ownership" 个靠近其 peerid 的键。但是 hashinfo 不会存储在路由 table 或 k-buckets 中（如果您愿意）。 hashinfo 存储在另一个映射中，该映射将 hashinfo 散列与其值相关联。
I am asking because this is not just implementation nuance. Because "k" is normally 20 or some other integer in all clients. So if I would use k-buckets to store torrent files as full-right members, I would have less space to store real peers data.
这里有 mis-understanding 关于我在上面解释的相同内容。 hashinfo 是存储字典中的键。而 peerid 又名路由 table 中的键。 k-buckets 数据结构。它们都具有相同的格式，因为这就是 kademlia 路由算法的工作方式。您必须能够将 hashinfo 与 peerid 与 xor 进行比较，以便能够分辨出哪些同行 "own" 哪些 hashinfo 值。
正如您在第二个片段中看到的那样，当另一个对等点请求与哈希关联的值时，它调用 lookup(key) 类似于 storage.get(key) 除了在我的例子中代码存储数据库中的值。
也许有一个mis-understanding关于k-buckets用于存储DHT路由信息的事实。 在之上，torrent协议使用DHT存储torrent路由信息。
对于它的价值，qadom's peer.py file 是我实现受 kademlia 启发的 DHT 的地方（除了我使用 256 位散列并放弃 alpha 和 k 参数并使用单个REPLICATION 参数）。代码在大部分时间都有效检查测试。
此外，我从另一个名为 kademlia 的项目中获得灵感，它（尝试？）实现 k-buckets.
据我所知，torrent DHT 路由看起来像 qadom bag functions 除了接收端必须验证公告，而在 qadom 包中是 free-for-all.
另外，查看原始的 kademlia 论文。