Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add overlay service to dispatch and handle requests #160

Merged
merged 1 commit into from Nov 8, 2021

Conversation

jacobkaufmann
Copy link
Collaborator

Related to #135. Move message dispatch and handling into OverlayService. The Overlay communicates with the associated OverlayService via a channel.

Motivation: Autonomous routing table management requires a separate task where the task must have a mutable reference to the overlay structure. We create a new overlay structure, OverlayService, and communication between this structure and Overlay occurs over a channel, which does not require a reference.

@@ -166,7 +166,7 @@ impl Discovery {
Ok(())
}

pub async fn send_talkreq(
pub async fn send_talk_req(
Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Note that this renaming was done to be consistent with discv5.


/// A node in the overlay network routing table.
#[derive(Clone)]
pub struct Node {
Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Not sure if it would be better for this to go in types.rs.

Copy link
Collaborator

Choose a reason for hiding this comment

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

Personally, I'm not a big fan of using types.rs and think this makes sense to belong here.


/// A general overlay error.
#[derive(Error, Debug)]
pub enum OverlayError {
Copy link
Collaborator Author

Choose a reason for hiding this comment

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

It looks like there are relevant new error types defined in #163 and #164.

@jacobkaufmann jacobkaufmann marked this pull request as ready for review October 27, 2021 20:53
@njgheorghita
Copy link
Collaborator

@jacobkaufmann Do you mind rebasing this off master, and I'll dig into it tomorrow

@jacobkaufmann
Copy link
Collaborator Author

@njgheorghita sure, no problem. I'm not sure if you see anything that appears out of scope for this PR. I tried to keep it small, but overlay touches a lot of things.

@njgheorghita
Copy link
Collaborator

@jacobkaufmann Yeah, it's a bit large but also sometimes that's unavoidable. It also seem like it covers some of the same territory as #163, #164 - so maybe wait until those land (which should be soon) and then either rebase off them, or leave your changes here if you feel like it's a more suitable error structure (which very well might be the case).

@jacobkaufmann jacobkaufmann force-pushed the overlay-service branch 2 times, most recently from 36f62cb to e9df7e8 Compare November 2, 2021 01:54
Copy link
Collaborator

@njgheorghita njgheorghita left a comment

Choose a reason for hiding this comment

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

Looks great! Nice work, just one question, so it's mentioned that the overlay routing table maintenance / liveness tasks are done autonomously - which I interpret as handled within discv5 - so my understanding here is that the maintenance / liveness tasks are done over the base discv5 protocol? This seems fine for PING, but are FINDNODES lookup/bootstrapping messages part of the autonomous management at all? If so, and those are going out over the base discv5 protocol, that would be corrupt the routing table

ethportal-peertest/src/events.rs Outdated Show resolved Hide resolved
ethportal-peertest/src/main.rs Outdated Show resolved Hide resolved
trin-history/src/events.rs Outdated Show resolved Hide resolved

/// A node in the overlay network routing table.
#[derive(Clone)]
pub struct Node {
Copy link
Collaborator

Choose a reason for hiding this comment

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

Personally, I'm not a big fan of using types.rs and think this makes sense to belong here.

@jacobkaufmann
Copy link
Collaborator Author

Looks great! Nice work, just one question, so it's mentioned that the overlay routing table maintenance / liveness tasks are done autonomously - which I interpret as handled within discv5 - so my understanding here is that the maintenance / liveness tasks are done over the base discv5 protocol? This seems fine for PING, but are FINDNODES lookup/bootstrapping messages part of the autonomous management at all? If so, and those are going out over the base discv5 protocol, that would be corrupt the routing table

@njgheorghita I think you are referring to the comment above OverlayService::spawn? So maybe the remark about "autonomous" processes here is premature, because those processes are not implemented in this PR. If you see #135 in the overlay/service.rs file, the main loop performs pings based on the ping queue, (#139 introduces the necessary data structure for the ping queue), and the loop also performs some maintenance tasks on the routing table for previously applied pending entries.

These processes are considered "autonomous" because we do not need to invoke a method on OverlayService for them to occur. We just have to spawn the service. Also, these processes do not occur over discv5 PING or FINDNODES messages. The ping messages that are sent are overlay PING messages, and the node updates are done via overlay FINDNODES messages that contain the latest ENR.

I hope this clarifies things. If the autonomous comment is confusing without the implementation of those processes, then I'm happy to remove it. And if anything else deserves some further elaboration, then I can add additional comments.

@njgheorghita
Copy link
Collaborator

@jacobkaufmann Ahh cool, yeah that makes perfect sense, thanks!

@@ -49,14 +46,26 @@ impl PortalnetEvents {
match std::str::from_utf8(request.protocol()) {
Ok(protocol) => match protocol {
Copy link
Member

Choose a reason for hiding this comment

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

FYI this match will not work with the latest ProtocolId update in #162. I'll create an issue to fix this in a separate PR.

@jacobkaufmann
Copy link
Collaborator Author

I think I've addressed all the comments. Waiting on #176, which @ogenev created to address the comment above, to land before I merge to ensure there are no conflicts.

@jacobkaufmann jacobkaufmann merged commit 00a9479 into ethereum:master Nov 8, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants