client/finality-grandpa: Reintegrate gossip validator report stream #4661
Conversation
The `finality-grandpa` `GossipValidator` is called by the `GossipEngine` in a synchronous fashion on each gossip message. Its main task is to decide whether to gossip the given message on, or whether to drop it. In addition it also updates the reputation of a node's peers based on the incoming gossip messages. To do so it needs to be able to report the reputation change which it does through an unbounded channel (in order to stay synchronous). Previously the receiving side of this channel would be handled by a new task, polling the channel and forwarding the changes to a clone of the `GossipEngine` that it would own. Instead the receiver of the above mentioned channel is now being polled by the `NetworkBridge` within its `Future::poll` implementation. Reputation changes are reported through the already existing `GossipEngine` instance within `NetworkBridge`. For details on the overall goal, see d4fbb89.
| // thus one has to wrap gossip_validator_report_stream with an `Arc` `Mutex`. Given that it is | ||
| // just an `UnboundedReceiver`, one could also switch to a multi-producer-*multi*-consumer | ||
| // channel implementation. | ||
| gossip_validator_report_stream: Arc<Mutex<mpsc03::UnboundedReceiver<PeerReport>>>, |
There was a problem hiding this comment.
out of curiosity, what does the plan to phase out the unbounded channel look like after this?
There was a problem hiding this comment.
See #4661 (comment).
| } | ||
| pub(super) struct PeerReport { | ||
| pub who: PeerId, | ||
| pub cost_benefit: ReputationChange, |
There was a problem hiding this comment.
docs on this struct & members?
rphmeier
added
A8-looksgood
and removed
A0-please_review
@rphmeier my plan roughly looks like this:
|
The
finality-grandpaGossipValidatoris called by theGossipEnginein a synchronous fashion on each gossip message. Its main task is to
decide whether to gossip the given message on, or whether to drop it.
In addition it also updates the reputation of a node's peers based on
the incoming gossip messages. To do so it needs to be able to report the
reputation change which it does through an unbounded channel (in order
to stay synchronous).
Previously the receiving side of this channel would be handled by a new
task, polling the channel and forwarding the changes to a clone of the
GossipEnginethat it would own.Instead the receiver of the above mentioned channel is now being polled
by the
NetworkBridgewithin itsFuture::pollimplementation.Reputation changes are reported through the already existing
GossipEngineinstance withinNetworkBridge.For details on the overall goal, see d4fbb89.