0

我正在使用 Mainline DHT 实现。我看到了奇怪的行为。

假设我知道节点 IP 和端口：1.1.1.1:7777。我以我自己的节点哈希作为目标向他发送“find_node”请求。我从他那里得到了 8 个节点，假设第一个哈希是：abcdeabcdeabcdeabcde 和 IP：2.2.2.2:8888。现在我向 2.2.2.2:8888 发送“ping”请求，该节点以与“find_node”响应中从 1.1.1.1:7777 得到的完全不同的哈希响应我。我看到这不是个别情况。这是怎么回事？为什么来自 2 个不同来源的同一节点的哈希值不同？感谢您的回答。

4

2 回答 2

0

这可能是一个恶意节点，它没有保持其节点 ID 一致，以努力进入尽可能多的路由表。这样做可能是为了数据收集或 DoS 放大目的。

一般来说，你不应该太相信远程节点报告和清理数据的任何东西。如果它没有保持其 ID 一致，您应该将其从路由表中删除并忽略其查询中返回的结果。我在我自己的 DHT 实现的文档中列出了BEP42之外的一系列可能的清理方法。

另一种可能性是节点 B 在此期间简单地更改了其 ID（例如，由于重新启动），而节点 A 尚未更新它或没有正确跟踪 ID 更改。但这不应该发生得太频繁。

我看到这不是个别情况。

总的来说，我只期望网络的一小部分出现这种行为。因此，您应该将发送虚假响应的唯一 IP 地址的数量与发送正常响应的唯一 IP 地址的数量进行比较。如果您的实现是幼稚的并且被恶意节点困住以联系更多恶意节点，则很容易弄错这些统计信息。

但是在查找过程中，当您从未正确清理其路由表的节点获得污染数据时，您可能会在终端阶段更频繁地看到这种情况。作为一个例子，旧的 libtorrent 版本没有（请参阅相关问题；请注意，我并没有在这里单独列出 libtorrent，许多实现在这一领域都很糟糕）。

于 2020-03-14T17:22:36.827 回答
0

可能是 2.2.2.2:8888 不知道它的外部端口/地址或者它还没有更新它。因此不同的哈希..

于 2020-03-13T09:08:00.593 回答