GossipSub messages relayed back to source on 3 node network

[cskiraly]

Setting up a 3 node network (nodes A,B,C) and a single GS topic. When A is sending a message to B and C, these are then relayed between them, finally sent back to A. That last step is not supposed to happen, since on that link the same message already travelled and was received.

Message sequence
A->B , A->C
B->C, C->B
C->A, B->A

[cskiraly]

was identified by @ufarooqstatus as potentially caused by https://github.com/vacp2p/nim-libp2p/blob/unstable/libp2p/protocols/pubsub/gossipsub.nim#L327

[diegomrsantos]

Could you please point out what part of the spec does it violate?

[cskiraly]

Ok, so the correct permanent link to the offending line is

nim-libp2p/libp2p/protocols/pubsub/gossipsub.nim

Line 327 in 467b5b4

discard g.validationSeen.pop(msgIdSalted, seenPeers)

Regarding what it violates:

• first of all, it is simply something better not done, just simply not reasonable to send back a message on a link where it was received.
• second, it violates https://github.com/libp2p/specs/blob/b9efe152c29f93f7a87931c14d78ae11e7924d5a/pubsub/gossipsub/gossipsub-v1.0.md#L268-L270

 In all pubsub implementations, we can first check the seen cache before forwarding messages to avoid wastefully republishing the same message multiple times.

I would qualify this as wasteful republishing.

[diegomrsantos]

Thank you for the clarification. I believe the seen cache is checked here https://github.com/vacp2p/nim-libp2p/blob/unstable/libp2p/protocols/pubsub/gossipsub.nim#L517.

[diegomrsantos]

It'd be great if you could reproduce it with a failing test similar to the ones in tests/pubsub folder.