Skip to content
This repository has been archived by the owner on Nov 15, 2023. It is now read-only.

Convert Peerset into a shared sync struct #13021

Closed
wants to merge 6 commits into from

Conversation

dmitry-markin
Copy link
Contributor

@dmitry-markin dmitry-markin commented Dec 26, 2022

Resolves paritytech/polkadot-sdk#529.

Follow-up

Things could be simplified further by removing Message::Accept and Message::Reject variants from sc_peerset::Message and making Peerset::incoming() return result synchronously. Unfortunately, this requires modifying Notifications, and as agreed with @altonen and @bkchr should be done only after it's better covered by tests.

@dmitry-markin dmitry-markin added A0-please_review Pull request needs code review. B0-silent Changes should not be mentioned in any release notes C1-low PR touches the given topic and has a low impact on builders. D3-trivial 🧸 PR contains trivial changes in a runtime directory that do not require an audit labels Dec 26, 2022
pub async fn peer_reputation(self, peer_id: PeerId) -> Result<i32, ()> {
let (tx, rx) = oneshot::channel();
pub fn peer_reputation(&self, peer_id: PeerId) -> impl Future<Output = Result<i32, ()>> + Send {
// TODO: refactor into sync function.
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Missed this one, converting into draft.

@dmitry-markin dmitry-markin marked this pull request as draft December 26, 2022 18:43
Poll::Ready(Some(event)) => event,
Poll::Ready(None) => return Poll::Pending,
};
fn poll_next(self: Pin<&mut Self>, cx: &mut Context) -> Poll<Option<Self::Item>> {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not a huge fan of this design choice. Previously there was a clear difference between the protocols that would use Peerset and the protocol that owned Peerset and I think it made sense. Now it seems that any protocol that acquires a handle to Peerset can poll it and drain events from it even if it has no idea what to do with them.

Copy link
Contributor Author

@dmitry-markin dmitry-markin Dec 27, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Would splitting Peerset into Peerset (lacking polling) and PeersetStream, both actually containing an Arc and different only in terms of the provided interface, make it better?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The naming can be different, of course.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think splitting them into two would be good.

@paritytech-cicd-pr
Copy link

The CI pipeline was cancelled due to failure one of the required jobs.
Job name: test-linux-stable
Logs: https://gitlab.parity.io/parity/mirrors/substrate/-/jobs/2202882

@dmitry-markin
Copy link
Contributor Author

A note to not forget what is happening here. Before this PR, Peerset had a channel for incoming commands sent via PeersetHandle (rx). These commands were only processes in poll() after all the outgoing events from message_queue with commands for Notifications were sent out. This way Notifications received consistent stream of events from Peerset.

After removing the channel for incoming commands and making the interface for incoming commands synchronous, it became possible that the command from Notifications and the event-reaction to it are interleaved by old out-events not yet dispatched from message_queue. As a result, the interface contract between Notifications and Peerset is broken.

One possible solution would be to make the Notifications-looking part of the Peerset interface also synchronous. E.g., instead of pushing the out-event with Accept and Reject to the end of the queue, we can return the decision immediately from Peerset::incoming(). This requires changing the Notifications code and is blocked by #13033.

Nevertheless, it's unclear whether this would be sufficient, because Connect and Drop out-events would still be buffered in the message_queue and only delivered to Notifications during polling.

@stale
Copy link

stale bot commented Feb 25, 2023

Hey, is anyone still working on this? Due to the inactivity this issue has been automatically marked as stale. It will be closed if no further activity occurs. Thank you for your contributions.

@stale stale bot added the A3-stale label Feb 25, 2023
@dmitry-markin
Copy link
Contributor Author

Yes, I'm going to continue working on this.

@stale stale bot removed the A3-stale label Feb 27, 2023
@altonen
Copy link
Contributor

altonen commented Feb 27, 2023

Yes, I'm going to continue working on this.

Btw, based on this comment, there may be some quite significant changes to the peerset at some point.

@dmitry-markin
Copy link
Contributor Author

Btw, based on this comment, there may be some quite significant changes to the peerset at some point.

Yeah, the race conditions @tomaka is mentioning are also in the Peerset, and exactly the reason why this refactoring was not finished in one go. May be if we manage to make Peerset synchronous, it would be easier to transit to synchronous outer (external) API. Or we can try to crystallize the solution with outer API and skip the step of making Peerset synchronous completely.

@stale
Copy link

stale bot commented Mar 29, 2023

Hey, is anyone still working on this? Due to the inactivity this issue has been automatically marked as stale. It will be closed if no further activity occurs. Thank you for your contributions.

@stale stale bot added the A3-stale label Mar 29, 2023
@dmitry-markin
Copy link
Contributor Author

Superseded by #13611. Closing this PR.

@stale stale bot removed the A3-stale label Mar 29, 2023
@bkchr bkchr deleted the dm-peerset-sync-struct branch March 29, 2023 13:09
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
A0-please_review Pull request needs code review. B0-silent Changes should not be mentioned in any release notes C1-low PR touches the given topic and has a low impact on builders. D3-trivial 🧸 PR contains trivial changes in a runtime directory that do not require an audit
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Replace async sc_peerset::PeersetHandle interface with a shared struct
3 participants