Giới thiệu

Công trình này là một nghiên cứu tiếp theo của nghiên cứu ban đầu mà chúng tôi đã thực hiện về số lượng tin nhắn trùng lặp, trước khi thông điệp nguyên thủy IDONTWANT được áp dụng:

Phương pháp

Dữ liệu được sử dụng để tạo ra nghiên cứu sau được thu thập bằng cách sử dụng trình nghe GossipSup hermes của chúng tôi tại Sydney, Úc vào 27/05/2025.

LƯU Ý: Chúng tôi cũng đã phân tích các số liệu từ một nút hermes thứ hai, đặt tại California, Hoa Kỳ, để xác minh rằng các số liệu không khác nhau nhiều, và quả thực như vậy.

Thật thú vị, đồ thị sau cho thấy nút điều khiển của chúng tôi đã gửi số lượng tin nhắn IDONTWANT tương tự như số lượng bản sao mà chúng tôi nhận được. Điều này có thể là một chỉ báo rằng IDONTWANT không hiệu quả như chúng tôi mong đợi.
Một giải thích có thể là chúng tôi gửi IDONTWANTs đúng giờ cho các nút ngang hàng của mình. Tuy nhiên, chúng tôi vẫn nhận được các tin nhắn mà chúng tôi vừa gửi IDONTWANTs, cho thấy tin nhắn đã có trên đường truyền.

hình ảnh582×350 44.9 KB

Khi nào các bản sao đến

Với mối tương quan giữa số lượng tin nhắn IDONTWANT đã gửi và các bản sao đã nhận, vẫn chưa rõ liệu IDONTWANTs có hữu ích không. Nút có thể đang gửi các tin nhắn điều khiển với độ trễ nhỏ, nhưng đủ từ thời điểm tin nhắn đến. Do đó, biểu đồ sau hiển thị khoảng thời gian giữa việc gửi các tin nhắn IDONTWANT và sự đến của tin nhắn đầu tiên. Hình ảnh cho thấy quả thực không có độ trễ giữa sự đến của tin nhắn và thông báo IDONTWANT. Đồ thị thậm chí còn cho thấy một số trường hợp mà thông báo điều khiển được gửi trước khi chúng tôi có thể theo dõi "việc chuyển" của tin nhắn.

LƯU Ý: Chúng tôi thấy các thời gian âm vì chúng tôi đọc sự đến của tin nhắn bằng thông báo Deliver, không phải khi chúng tôi nhận được tin nhắn qua RPC.

hình ảnh580×358 31.2 KB

Điều gì kích hoạt các bản sao sau các tin nhắn IDONTWANT

Như đã đề cập ở trên, thật thú vị, chúng tôi vẫn thấy các bản sao đến sau khi thông báo cho nút ngang hàng từ xa bằng một tin nhắn IDONTWANT.

Biểu đồ sau hiển thị khoảng thời gian giữa thông báo của một tin nhắn IDONTWANT và bản sao đã nhận từ cùng một nút ngang hàng. Tại đây chúng ta có thể thấy rằng một số triển khai hoặc phiên bản không dừng việc truyền tin nhắn sau khi nhận được IDONTWANT (rust-libp2p đang có công việc đang diễn ra để giải quyết vấn đề này, xem vấn đề GH và PR GH).

Đáng chú ý là đang có công việc để khắc phục trường hợp khi một RPC được xuất bản đã được xếp hàng và một tin nhắn IDONTWANT đến (vấn đề). Chúng tôi tin rằng điều này sẽ giúp giảm đáng kể số lượng bản sao.

• 30,607 ID thông điệp duy nhất (khối và blob)
• 63,735 tin nhắn trùng lặp
• 144,524 IDONTWANT đã gửi
• 25,201 IWANT đã gửi
• 14,255 ID thông điệp mà chúng tôi đã gửi cả IWANT và IDONTWANT
• 44,875 bản sao từ các đối tác được thông báo qua tin nhắn IDONTWANT (~70% bản sao) → msg_arrival > sent_idontwant > recv_duplicate
• 18,540 bản sao từ các đối tác yêu cầu thông điệp thông qua IWANT (~29% bản sao) → sent_iwant > msg_arrival > recv_duplicate (không gửi IDONTWANT để hủy IWANT)
  • (18) sent_iwant > msg_arrival > sent_idontwant
    • rất ít trường hợp chúng tôi cố gắng hủy IWANT đã gửi bằng IDONTWANT → kết quả mong đợi trong việc triển khai go, nhưng được xác định bởi đặc tả.
    • 12 trong số 18 trường hợp, chúng tôi đã nhận được một bản sao

Khuyến nghị của chúng tôi

• Nhìn chung, IDONTWANT cải thiện tình hình đáng kể, nhưng trở nên không hiệu quả khi:
  • msg_id đã được yêu cầu thông qua IWANT, trong trường hợp này chúng tôi không gửi tin nhắn IDONTWANT
  • Thông điệp đã ở trong đường ống và không bị hủy
• Tuy nhiên, vẫn còn dư địa để cải thiện việc xử lý các tin nhắn điều khiển:
  • Giới hạn số lượng tin nhắn IWANT được gửi như đã thảo luận tại vấn đề này và tại Devcon SEA. Như đã thảo luận trước đây, chúng tôi đã thấy rằng nút gửi nhiều tin nhắn IWANT dư thừa cho một ID thông điệp duy nhất
  • Trì hoãn tin nhắn IWANT đầu tiên để tránh 60% phân phối được yêu cầu 10ms trước khi thông điệp đầu tiên đến, mà chúng ta biết sẽ tạo ra các bản sao dư thừa.
    • Hủy phản hồi của IWANT khi nhận IDONTWANT, ngay cả khi thông điệp đã được truyền/trên đường truyền.
      • Điều này dường như không phải là trường hợp của tất cả các triển khai (chắc chắn không phải cho Go).
      • Đã có sẵn một kiểm tra cho các thông điệp chúng ta sắp xuất bản (liên kết). Nhưng nhiều bản sao đã đến sau trình tự: msg_arrival -> sent_idontwant -> recv_duplicate