Bittorrent 主线DHT：为什么ping中的散列与find_节点中的散列不同？

我正在与主线DHT的实施。我看到了奇怪的行为

假设我知道节点IP和端口：1.1.1.1:7777。我用我自己的节点哈希作为目标向他发送“find_node”请求。我从他那里得到了8个节点，假设第一个散列是：abcdeabcde和IP:2.2.2:8888。

---

现在我将“ping”请求发送到2.2.2.2:8888，该节点以与我在“find_node”响应中从1.1.1.1:7777获得的完全不同的哈希值响应我。我知道这不是个别情况。发生什么事了？为什么来自两个不同来源的同一节点的哈希值不同？感谢您的回答。

可能是，2.2.2.2:8888不知道其外部端口/地址，或者尚未对其进行更新。因此，不同的散列..

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

一般来说，您不应该过分信任远程节点报告和清理数据的任何内容。如果它的ID不一致，则应将其从路由表中删除，并忽略其查询中返回的结果。我已经列出了一系列可能的消毒方法

另一种可能性是节点B在此期间只是更改了其ID（例如，由于重新启动），而节点a要么尚未对其进行更新，要么未正确跟踪ID更改。但这不应该发生得太频繁

我知道这不是个别情况

总的来说，我认为这种行为只会发生在网络的一小部分。因此，您应该将发送虚假响应的唯一IP地址数与发送正常响应的唯一IP地址数进行比较。如果您的实现很幼稚，并且被恶意节点捕获，从而联系到更多恶意节点，那么这些统计信息很容易出错

---

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

请提供更多细节。我不明白，2.2.2.2:8888不知道其外部端口/地址这一事实与1.1.1.1:7777节点存储其假散列这一事实有何关联？我知道节点可以更改其散列，但根据协议，您应该在15分钟内至少ping一次已知节点，这样您将获得正确的新散列。这是因为散列由IP地址和端口组成。节点可以在获取有关其自身外部地址的信息时更新其自身id。在知道外部id之前，id是根据本地IP地址（例如192.168.0.1）和本地端口（例如6881）计算的。但是，当另一个节点（在您的示例1.1.1.1中）看到这个节点（2.2.2.2）时，它会根据它看到的ip和端口计算其id，因此散列就不同了。如果我错了，请纠正我。。。“使用SHA1和大量的熵来确保一个唯一的ID。”如果我理解正确，哈希并不取决于你的IP和端口。很抱歉，但我不得不说——那些文档非常重要。它们具有误导性和不完整性——它们给mi带来了很多麻烦。。另一方面，虽然我恨他们，但我爱他们——总比什么都没有好。我建议您使用它们作为一个一英里高的概述，对于真正的实现，请查看源代码-