Gossipsub backpressure

[AgeManning]

Backpressure PR to our fork

[AgeManning]

Yeah nice. Two things I noticed.

1. We currently don't handle the cases where the queue's are full. I guess this is a future PR. I.e we don't handle the errors when we try to send.
2. I know I'm missing something, but why are we using an unbounded channel for the priority queue and not just another bounded channel like we do with the non-priority?

[AgeManning]

I think this is true, as I recall trying to enforce conditions like this.

But we have to be absolutely sure that there is no code path where a peer can get added or removed from the peer_topics mapping and not the handler_send_queues.

If we are uncertain about this condition in any way (or are concerned a future dev may break this condition), we should log a crit instead imo.

[jxs]

a peer is added when a new ConnectionHandler is created and removed when the connection is closed. As we are using mpmc channels if that PeerId exists it has a respective ConnectionHandler (theoretically). If you prefer we can for now use a crit/error log instead

[AgeManning]

lol, was messing with gh cli, didn't mean to merge this early. But it works.

[jxs]

Yeah nice. Two things I noticed.

1. We currently don't handle the cases where the queue's are full. I guess this is a future PR. I.e we don't handle the errors when we try to send.
2. I know I'm missing something, but why are we using an unbounded channel for the priority queue and not just another bounded channel like we do with the non-priority?

1 - when the queue is full for every peer we return InsuficientPeers for individual peers we just drop the messages yeah, we can then downscore peers and when they reach 0 ban them, I think that's what you envisioned right?

2 - no worries :D, because DRAFT and PRUNE messages should still be sent if the queue is full, so I used an AtomicUsize for the cap of Publish messages