소개

이 연구는 IDONTWANT 메시지 원시 유형이 채택되기 전에 수행한 중복 메시지 수에 대한 원래 연구의 후속 연구입니다:

방법론

다음 연구를 생성하는 데 사용된 데이터는 호주 시드니에 위치한 GossipSup 리스너 hermes를 사용하여 27/05/2025에 수집되었습니다.

참고: 숫자가 크게 다르지 않음을 확인하기 위해 미국 캘리포니아에 위치한 두 번째 hermes 노드의 숫자도 분석했으며, 실제로 그러했습니다.

흥미롭게도, 다음 그래프는 우리의 제어 노드가 수신한 중복 메시지 수와 거의 비슷한 수의 IDONTWANT 메시지를 보냈음을 보여줍니다. 이는 IDONTWANT가 우리가 기대한 만큼 효과적이지 않을 수 있음을 나타낼 수 있습니다.
가능한 설명 중 하나는 우리가 메시 피어에게 제때 IDONTWANT를 보냈지만, 방금 IDONTWANT를 보낸 메시지를 여전히 수신하고 있다는 것입니다. 이는 메시지가 이미 네트워크에 있었음을 나타냅니다.

image582×350 44.9 KB

중복 메시지는 언제 도착하는가

보낸 IDONTWANT 메시지 수와 수신된 중복 메시지 간의 상관관계를 고려할 때, IDONTWANT가 유용한지는 여전히 불분명합니다. 노드가 메시지 도착 후 작지만 충분한 지연 시간을 두고 제어 메시지를 보낼 수 있습니다. 따라서 다음 차트는 IDONTWANT 메시지 전송과 첫 번째 메시지 도착 사이의 시간 차이를 보여줍니다. 그림은 메시지 도착과 IDONTWANT 알림 사이에 실제로 지연이 없음을 보여줍니다. 그래프는 심지어 제어 알림이 "배달" 추적이 가능해지기 전에 전송된 경우도 보여줍니다.

참고: RPC를 통해 메시지를 수신한 시점이 아니라 전달 알림으로 메시지 도착을 읽기 때문에 음수 시간을 볼 수 있습니다.

image580×358 31.2 KB

IDONTWANT 메시지 후 중복이 트리거되는 원인

앞서 언급했듯이, 흥미롭게도 원격 피어에게 IDONTWANT을 알린 후에도 여전히 중복 메시지가 도착합니다.

다음 차트는 IDONTWANT 메시지 알림과 동일한 피어로부터 수신된 중복 메시지 사이의 시간 차이를 보여줍니다. 여기서 일부 구현 또는 버전이 IDONTWANT를 수신한 후에도 메시지 전송을 중단하지 않음을 알 수 있습니다(rust-libp2p는 이 문제를 해결하기 위한 진행 중인 작업이 있으며, GH 이슈 및 GH PR 참조).

게시된 RPC가 대기 중일 때 IDONTWANT 메시지가 도착하는 경우를 수정하기 위한 진행 중인 작업이 있음을 주목할 가치가 있습니다(이슈 참조). 이것이 중복 수를 크게 줄이는 데 도움이 될 것으로 믿습니다.

• 30,607 고유한 메시지 ID (블록 및 블롭)
• 63,735 중복된 메시지
• 144,524 발송된 IDONTWANTs
• 25,201 발송된 IWANTs
• 14,255 우리가 IWANT와 IDONTWANT를 모두 보낸 메시지 ID
• 44,875 IDONTWANT 메시지를 통해 알림을 받은 피어로부터의 중복 (~70% 중복) → msg_arrival > sent_idontwant > recv_duplicate
• 18,540 IWANT를 통해 메시지를 요청한 피어로부터의 중복 (~29% 중복) → sent_iwant > msg_arrival > recv_duplicate (IWANT를 취소할 IDONTWANT 없음)
  • (18) sent_iwant > msg_arrival > sent_idontwant
    • 보낸 IWANT를 IDONTWANT로 취소하려 한 매우 드문 경우 → Go 구현에서 예상된 결과이지만 사양에 의해 정의됨.
    • 해당 18 사례 중 12개에서 중복을 수신

우리의 권장사항

• 전반적으로, IDONTWANTs는 상황을 크게 개선하지만 다음과 같은 경우 비효과적해집니다:
  • msg_id가 이미 IWANT를 통해 요청된 경우, 이 경우 IDONTWANT 메시지를 보내지 않습니다
  • 메시지가 이미 파이프에 있고 취소되지 않는 경우
• 그럼에도 불구하고 제어 메시지 처리에는 여전히 개선의 여지가 있습니다:
  • 이 이슈와 Devcon SEA에서 논의된 대로 보내는 IWANT 메시지 수를 제한합니다. 앞서 언급했듯이, 노드가 단일 메시지 ID에 대해 많은 중복 IWANT 메시지를 보내는 것을 확인했습니다
  • 첫 번째 IWANT 메시지를 지연시켜 첫 번째 메시지 도착 10ms 전에 요청된 분포의 60%를 피합니다. 이는 중복 복사본을 생성할 것임을 알고 있습니다.
    • IDONTWANT 수신 시 IWANT의 응답을 취소하며, 메시지가 이미 전송 중이거나 전선에 있더라도 그렇게 합니다.
      • 이는 모든 구현에 해당되지 않습니다(Go의 경우 확실히 아님).
      • 게시하려는 메시지에 대한 이미 확인이 있습니다 (링크). 하지만 많은 중복이 시퀀스 후에 도착했습니다: msg_arrival -> sent_idontwant -> recv_duplicate