You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Nov 15, 2023. It is now read-only.
We can add a crate similar to sc-network-gossip, except that it keeps track of the number of valid/invalid messages for each peer and pulls messages at a slower rate for peers whose ratio is too low.
The slower pulling rate should in turn apply back-pressure on the connection, and force the sending side to slow down the sending rate.
Not all of the protocols for Parachains networking are gossip protocols. And actually, many that are currently gossip protocols, we would prefer not to be as there would be major efficiency gains to be made by having validators communicate via direct messaging.
substrate-network-gossip is also not async-friendly, so for Parachains networking (paritytech/polkadot#1344 & paritytech/polkadot#1326 ) components that we've implemented so far, we have just been rolling our own ad-hoc gossip that does handle asynchrony & backpressure, although not in a particularly intelligent way.
Because of that, all of the backpressure work on networking can happen behind the scenes, from the Parachains codebase perspective. It would make most sense to me to focus on refactoring the network service to make write_notification an async fn. The safest assumption to me right now is then to just assume that there are no messages that we can block, and then pause any networking task on awaiting this function.
Behind the scenes one layer down in libp2p we would want to be dropping peers who are not accepting messages fast enough, which, as I understand it, has not actually been a problem in practice.
Address points (1) and (2) of paritytech/polkadot#1348
We can add a crate similar to
sc-network-gossip
, except that it keeps track of the number of valid/invalid messages for each peer and pulls messages at a slower rate for peers whose ratio is too low.The slower pulling rate should in turn apply back-pressure on the connection, and force the sending side to slow down the sending rate.
"Stops processing messages" requires some modifications to the API of
sc-network
in addition to paritytech/polkadot-sdk#554. paritytech/polkadot-sdk#554 itself depends on #5938.Not strictly-speaking concerned by this issue, but related: #5481 will cause issues on the sending side if we back-pressure the connection.
The text was updated successfully, but these errors were encountered: