The difference between the IHAVE and IWANT to IANNOUNCE and INEED 2.0 definitions
- The main difference is that with 2.0 window there’s basically just one one mesh you don’t have a separate mesh where you send IHAVEs at a heartbeat interval.
- Actually, we do send IHAVE as well, but within the mesh we don’t propagate the messages—it depends on the Dannounce parameter. Dannounce determines how much of the work is based on a pull strategy. For example, if I Dannounce to “A”, that means all the mesh members will not get the message. What we do is send IANNOUNCE to them. IANNOUNCE is essentially IHAVE; the only difference is semantic. IHAVE is announced over heartbeat intervals to the metadata and mesh members. To distinguish it, they introduced a new message, IANNOUNCE, which is sent to mesh members immediately after validating the message. Similarly, INEED is like IHAVE; INEED means IWANT message, but INEED messages are transmitted only to mesh members. So in a pure pull-based setting, we can say “dannounce to A”, and every peer that gets a message sends an “announce” message to its mesh members. If any mesh member needs that message, it can ask for it by sending an IWANT or INEED message. Since we are issuing INEED messages, we are aware that we are asking for a specific message, so we only send one INEED request per outstanding message. If we’ve sent INEED, we don’t send IWANT for the same message. If we hear any announcement through the gossip mesh—any IHAVE—and we’ve already sent an IWANT, we need to send INEED for that message. The only problem is that we are not aware of the message size. In specific use cases, like blobs, we might know the message size, but in other cases we don’t, so we don’t know when to time out. There will definitely be situations when a peer announces a message, we send INEED, and the peer delays or is unable to send the message for unforeseen reasons. In their experiments, they timed out after 1 second. In our experiment, since we were testing the protocols in a purely trusted environment, we didn’t include adversaries. But in future work, we will introduce adversaries to see the protocol’s behavior in versions 1.2, 2.2, and 1.4.
1.4 inclusion into 2.0
- Would 2.0 also include the 1.4 mechanisms like IMRECEIVING and the preamble? And would large messages still benefit from an IMRECEIVING type mechanism in 2.0?
- Right now, we actually have two 1.3 proposals. If we look here, we definitely have this “Extension Control” message. This proposal—still under discussion—suggests that we can keep adding messages into one protocol version. However, negotiation might become a problem in that case, such as figuring out which messages are available in which version. That’s a good point—it may have confused some audiences. The version numbering is a bit odd, and the libp2p community is actively working on finding a better system. The goal is to have something like pluggable extensions to gossipsub. What’s now called gossipsub 1.3, 1.4, or 2.0 doesn’t necessarily mean they are mutually exclusive, nor are they strictly incremental improvements. You could use one of them in combination with another set of features and plug in the mechanisms that suit your specific application network. So for now, I would see 1.4 and 2.0 more as code names for specific proposals. Also, just to add—1.4’s production implementation has already been merged, and other implementations can test it.