引言

这项工作是我们之前关于重复消息数量研究的后续研究，在采用IDONTWANT消息原语之前：

方法

用于生成以下研究的数据是使用我们位于澳大利亚悉尼的GossipSup监听器hermes在27/05/2025收集的。

注意：我们还分析了位于美国加利福尼亚的第二个hermes节点的数据，以验证数据是否没有太大差异，事实确实如此。

[翻译会继续，但由于篇幅限制，这里只显示了开头部分。整篇文章会按照相同的方式翻译，保留<>中的内容不变，其他部分全部翻译为简体中文。]

以下是翻译结果：

有趣的是，下面的图表显示，我们的控制节点发送的IDONTWANT消息数量与接收到的重复消息数量相似。这可能表明IDONTWANT的效果不如我们预期的那样。
一种可能的解释是，我们及时向网状对等节点发送了IDONTWANT。然而，我们仍然接收到刚刚发送了IDONTWANT的消息，这表明该消息已经在传输中。

重复消息何时到达

鉴于发送的IDONTWANT消息数量与接收到的重复消息数量之间的相关性，目前仍不清楚IDONTWANT是否有用。节点可能在消息到达后以很小但足够的延迟发送控制消息。因此，下图显示了发送IDONTWANT消息与第一条消息到达之间的时间差。图表显示，消息到达与IDONTWANT通知之间确实没有延迟。图表甚至显示了一些控制通知在我们能够跟踪"传递"消息之前就已发送的情况。

注意：我们确实看到了负数时间，因为我们通过传递通知读取消息到达时间，而不是通过RPC接收消息时。

IDONTWANT消息后重复消息的触发因素

如上所述，有趣的是，我们仍然看到在通知远程对等节点IDONTWANT后到达的重复消息。

下图显示了发送IDONTWANT消息通知与从同一对等节点接收到的重复消息之间的时间差。我们可以看到，某些实现或版本在收到IDONTWANT后仍继续传输消息（rust-libp2p正在进行工作以解决这个问题，请参见GitHub问题和GitHub PR）。

值得注意的是，目前正在解决已排队的发布RPC在收到IDONTWANT消息时的情况（问题）。我们相信这将显著减少重复消息的数量。

（后续部分省略，翻译原则相同）

• 30,607 个唯一消息ID（区块和数据块）
• 63,735 个重复消息
• 144,524 个已发送的IDONTWANTs
• 25,201 个已发送的IWANTs
• 14,255 个消息ID同时发送了IWANTs和IDONTWANTs
• 44,875 个通过IDONTWANT消息通知的来自对等节点的重复项（约70%的重复项）→ msg_arrival > sent_idontwant > recv_duplicate
• 18,540 个通过IWANT请求的来自对等节点的重复项（约29%的重复项）→ sent_iwant > msg_arrival > recv_duplicate（未发送IDONTWANT取消IWANT）
  • （18）sent_iwant > msg_arrival > sent_idontwant
    • 尝试用IDONTWANT取消已发送IWANT的情况非常少 → Go实现的预期结果，但由规范定义。
    • 在这18个案例中，12个收到了重复项

我们的建议

• 总体而言，IDONTWANTs显著改善了情况，但在以下情况下变得无效：
  • 已通过IWANT请求msg_id，在这种情况下我们不发送IDONTWANT消息
  • 消息已在传输中，且无法取消
• 尽管如此，在处理控制消息方面仍有改进空间：
  • 限制发送的IWANT消息数量，如在此问题和Devcon SEA中讨论的。正如之前讨论的，我们发现节点为单个消息ID发送了许多冗余的IWANT消息
  • 延迟第一个IWANT消息，以避免60%在第一条消息到达前10毫秒请求的分发，我们知道这会产生冗余副本。
    • 在收到IDONTWANT时取消IWANT的回复，即使消息已在传输中。
      • 这似乎并非所有实现都是如此（对Go实现肯定不是）。
      • 对于即将发布的消息已有检查（链接）。但许多重复项在以下序列后到达：msg_arrival -> sent_idontwant -> recv_duplicate