引言

這項工作是我們之前關於重複訊息數量研究的後續研究，在採用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