-
Notifications
You must be signed in to change notification settings - Fork 2.6k
Rework the event system of sc-network
#14197
base: master
Are you sure you want to change the base?
Conversation
Substream open/close functionality is not supported so they're left as `todo!()s`. Remove `SendNotification` command as sending notifications is now supported by using the installed notification sink received in `NotificationStreamOpened` event.
The role should not be part of `NotificationStreamOpened` as `Notifications` has no knowledge of that and the protocols that are interested in that information should query it from `Peerset` (when the support for that is added)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good! Have yet to go through notifications/behaviour.rs
and notifications/service/tests.rs
— going to finish the review tomorrow.
Co-authored-by: Dmitry Markin <[email protected]>
Co-authored-by: Dmitry Markin <[email protected]>
NotificationService
sc-network
log::debug!(target: "sync", "New best block imported {:?}/#{}", hash, number); | ||
|
||
self.chain_sync.update_chain_info(&hash, number); | ||
while let Poll::Pending = self |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not quite sure why do we need a loop here (isn't it a busy loop after all?), as there were no such a thing in the previous code.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
SyncingEngine
is lagging behind in terms of refactoring and still heavily uses polling. There is work that tries to address this (#14675) and in time this call can be converted to a simple .await
.
As far as these changes are concerned, updating the handshake is now a future because the code sends the command to Notifications
directly over a bounded command channel. The channel is not busy and right now expects one message every six seconds so I don't believe this to be a grave concern. I will add a TODO to remove this ugly loop once SyncingEngine
is ready.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good! 👍
Left some comments which are mostly nitpicks, the two actually important are:
- We should insert a peer into
PeerStore
when setting the role. - There is one place where
report_notification_sink_replaced()
should be called inNotifications
.
Co-authored-by: Dmitry Markin <[email protected]>
This PR introduces
NotificationService
which gives protocols direct access to theConnectionHandler
and allows them to bypassNetworkWorker
when communicating with remote peers. When a protocol is initialized, a handle pair is created and the other half of the handle is given to the protocol which allows it to send and receive notifications and peer events from network. The other half is given toNotifications
which it uses to communicate with the protocol directly.PR also introduces the concept of configurable handshakes. This allows us to do two things:
Previously
Peerset
was entirely in control of choosing which peers to accept/reject which caused problems with/block-announces/1
. The slot allocation is part ofProtocolController
which may be incorporated intoNotificationService
in the future but whether the peer is accepted or rejected is now done by both the protocol and byPeerset
.polkadot companion: paritytech/polkadot#7582
cumulus companion: paritytech/cumulus#2983
Fixes paritytech/polkadot-sdk#515, fixes paritytech/polkadot-sdk#554, fixes paritytech/polkadot-sdk#512, fixes paritytech/polkadot-sdk#556