feat: idontwant on publish #1230
Conversation
richard-ramos
force-pushed
the
idontwant-publish
branch
2 times, most recently
from
c8d250c to
43104a0
Compare
richard-ramos
force-pushed
the
idontwant-publish
branch
from
43104a0 to
4f9c21f
Compare
| @@ -784,6 +797,9 @@ method publish*(g: GossipSub, topic: string, data: seq[byte]): Future[int] {.asy | |||
|
|
|||
| g.broadcast(peers, RPCMsg(messages: @[msg]), isHighPriority = true) | |||
|
|
|||
| if isLargeMessage(msg, msgId): | |||
| g.sendIDontWant(msg, msgId, peers) | |||
There was a problem hiding this comment.
... why should we send IDONTWANT after broadcasting the message? If the other peers receive the message, they already know that I don't want it.
There exists a case where sending it before broadcasting makes sense, though I'm not sure how well it has been studied, ie it needs research: when streaming a large message to a peer, this takes time - in the meantime, the peer might start streaming the same message to us - an IDONTWANT before sending the message tells the other peer not to do that.
|
I think there's some confusion about #1224 here - what that issue addresses is the case where a message exists "out of band" and is published on gossipsub - the aim is to tell my neighbours that I have received the message out of band already, and they should not waste bandwidth on sending me an extra copy. In this particular case, the message is a "blob" from a blob transaction - most of the time, blobs are in the mempool before they are added in a block so if I have the blob in the mempool, there's no point receiving it over gossipsub also. |
Would you say that in this case I should instead provide a way for someone using gossipsub to indicate that they don't want to receive some message? (i.e. something like If so, do you think it makes sense to also keep the changes i'm proposing (and changing the order so the IDONTWANT is sent before the broadcast? or should that be researched first? |
|
Other implementations do seem to send it before it's published unless i understood wrong: |
I think a function like that is broadly useful, yes - though the docs should make clear that it's a "hint".
they certainly have to be reordered - the policy for when to send a pre-emptive idontwant is however not clear to me - the only time it is useful is during the aforementioned case where the other peer makes the decision to start sending the message while we are also sending it .. it happens, but ... only when streaming time is large enough - all other times, it's a waste of time and bandwidth, and I'm not sure the threshold is well understood. Perhaps this has been answered already somewhere but doing a bit of digging might be the right course of action here. |
Closes #1224
The following changes were done:
nim-libp2p/libp2p/protocols/pubsub/gossipsub.nim
Lines 800 to 801 in 4f9c21f