The fact that message transmission time increases with the message size leads to two fundamental problems:
- It takes longer for a peer to finish downloading a large message. During this time, the peer can initiate many IWANT request(s) for the same message.
- Sending a large message to all mesh members may consume considerable time. IHAVE announcements during this time may bring in many IWANT requests. Servicing these IWANTs alongside the mesh transmissions further increases message transmission time (leading to the previous problem).
Simulating variable message size transmissions in a 1500-node network (with 50-150 Mbps bandwidth/peer and 40-130 ms latency/link) reveals that the number of IWANT requests grows noticeably with the message size. Interestingly, only a few peers generate many of these requests (See Figure below).
Considering that IHAVE/IWANT-Request/IWANT-Reply message trio has some essential benefits, including:
- Resilience against non-conforming mesh members.
- Network-wide message reachability, in the case of network partitions (although such partitions are less likely to occur with higher D)
- Aiding distant peers in expediting the retrieval of overdue messages through IWANT requests, indirectly lowering message dissemination latency
A few possible modifications can still be applied while preserving the essential benefits of IHAVE/IWANT-Request/IWANT-Reply message trio:
-
Deferring IHAVE announcement till the message transmission to some mesh peers is completed:
This will have a negligible impact on short messages and indirectly prioritize large message transmission to mesh members (also reducing transmission time for individual peers). The only downside is that pulling a large message through IWANT is delayed (approximately by the message transmission time to the fastest peers)
-
Sending a message preamble (containing msgID) allows a peer to learn about ongoing large message receptions. We can defer IWANT requests for such messages.
The only downside is that a malicious mesh peer may deliberately delay message transmission after sending a preamble. Such cases can be avoided by negative peer scoring, along with IWANT request(s) after the defer-interval has completed.
-
Refraining from multiple IWANT requests for the same (large) message. However, prior knowledge of the message length is required.
Considering an IDONTWANT as a message preamble and issuing IWANT requests only for the messages for which an IDONTWANT is not received gives the following results:
