问题标签 [kademlia]

假设有一个 P2P 文件共享系统，它没有跟踪器，只有一个 DHT。

如何知道上传/下载特定文件的所有活动对等点的数量？

是否只是通过不断查询 DHTget_peers来获得新的对等点？有没有更好的解决方案？

在 BEP5 中说

节点的联系信息被编码为一个 26 字节的字符串。也称为“紧凑节点信息”，网络字节顺序中的 20 字节节点 ID 具有连接到末尾的紧凑 IP 地址/端口信息。

和

当一个节点接收到一个 find_node 查询时，它应该用一个键“nodes”和一个字符串的值来响应，该字符串包含目标节点或它自己的路由表中 K (8) 个最近的好节点的紧凑节点信息。

在我的 java 的 find_node 响应中，Compact 节点信息字节不是 26 字节，为什么？

我将来自 router.bittorrent.com 的 find_node 响应的节点解码为字符串，并向解码的“节点”发送了一个 find_node 请求，但我从未修改过来自该“节点”的 find_node 响应，我怀疑解码“节点”的方式是错误的，这是代码：

解码字符串代码是

有什么问题吗？

PS：send() 函数运行良好。

我的意思是，k-bucket 上的节点 ID“拥有”IP 和端口号

• 如何回答 RPC get_peers 查询？
• 关于 torrent infohash 的对等点信息存储在哪里？
• 元数据从何而来？

我在http://www.bittorrent.org/beps/bep_0005.html上阅读，但这对我来说并不清楚

我正在为试图理解看似矛盾的段落的原始论文而苦苦挣扎。一个例子是在 2.2 中，作者声明对于 160 位空间将有 160 k 个桶，然后接着说实际上桶是一个较小的数字，覆盖更广泛的位范围并由前缀二叉树组织。在该 2.4 部分中，他们讨论了导致如下解释的不平衡树，https://stackoverflow.com/a/32187456/442396，其中不清楚那里的答案是否确实反映了 MM 的意图。是否有明确记录的共识来解释如何用简单的英语解释这些歧义？

根据这个 DefCon 演讲Crawling BitTorrent DHTs for Fun，即使所有其他 Torrent 站点及其备份都被对手关闭，BitTorrent DHT 节点也可以在一夜之间从头开始构建一个 torrent 站点。

在 kademlia 中，peer 从 torrent 站点学习 infohash，为每个 torrent 索引磁力链接。对等点发出get_peers请求以获取当前正在下载和播种种子的对等点列表。节点 ID最接近 infohash的 dht 节点将元数据返回给查询节点。

无论如何，我需要 infohash 来查询同行。那么，如果一个人没有 infohash，如何在一夜之间建立一个 torrent 网站呢？我认为唯一可能的方法是详尽的密钥搜索。必须随机生成160-bitinfohash 并开始查询对等点，但这需要很长时间。

kademlia 中是否存在任何现有的远程过程调用get_infohash，例如或get_metadata允许 dht 节点查询相邻节点的 infohash，因为这是直接从 dht 节点学习 infohash 的唯一方法。

我有一个想法，用现有的BitTorrent DHT来实现一个基于关键字的实时种子搜索机制，我想知道它是否可行和现实。

我们有一个 torrent，我们希望能够keyword仅使用 DHT 找到它。

• H是一个 20 字节输出的散列函数
• infohash是种子的 info_hash（20 字节）
• sub(hash, i)返回hash从 byte 开始的 2 个字节i（例如，sub(0x62616463666568676a696c6b6e6d706f72717473, 2) = 0x6463）
• announce_peer(hash, port)发布与虚假 info_hash 关联的虚假对等点hash。fake peer 的 IP 无关紧要，我们使用该port数字来存储数据（2 个字节）。
• get_peers(hash)检索与假 info_hash 关联的假对等点hash。让我们考虑这个函数只返回一个端口号列表。
• a ++ b表示连接a和b（例如，0x01 ++ 0x0203 = 0x010203）

出版物

搜索

我知道会与id（仅 2 个字节）发生冲突，但是对于相对特定的关键字，它应该可以工作......

我们还可以通过按字母数字顺序连接多个单词来构建更具体的关键字。例如，如果我们有单词A，B并且C与种子相关联，我们可以发布关键字A、B、C、A ++ B、A ++ C和。B ++ CA ++ B ++ C

那么，这个可怕的黑客是否可行：D？我知道Retroshare 正在使用 BitTorrent 的 DHT。

我是 P2P 网络的新手，目前我尝试了解 Kademlia 论文指定的一些基本内容。我无法理解的主要事情是 Kademlia 距离度量。所有论文都将距离定义为两个 ID 的 XOR。ID 大小为 160 位，因此结果也有 160 位。问题：将这个距离表示为整数的便捷方法是什么？我检查过的一些实现使用以下内容：距离 = 160 - 前缀长度（其中前缀长度是前导零的数量）。这是正确的方法吗？

我基于 Kadelmia 方法编写 P2P 系统。我的问题与要使用的传输类型有关：UDP 或 TCP。

Kadelmia 文档定义了 UDP，但我担心的是负载大小。据我所知，UDP 被授予者交付了 548 个字节。但是有些消息由文档定义，长度大于 548 字节（例如 FIND_NODE 上的响应）。问题：我应该使用 TCP 而不是 UDP 吗？

我在这里阅读了有关 Kademlia 的论文。

我不明白数字 k 是如何选择的（对于 k 桶）。

我不明白这句话：“选择 k 使得任何给定的 k 节点都不太可能在一小时内相互失败。”

我不明白节点如何失败？