-
Notifications
You must be signed in to change notification settings - Fork 0
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
feat: Add peer-resolver lib #640
Conversation
6ac62f9
to
e423d2b
Compare
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.
Preliminary remarks, good job on figuring this out! 🚀
0922b1b
to
fd7f21f
Compare
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.
One question I have is — what is a cookie in this context?
} | ||
|
||
/// This functions requests the rendezvous_point for new or updated peers since the last cookie. | ||
pub fn discover(&mut self, rendezvous_point: PeerId) { |
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 sure this function name is good, it isn't really descriptive of what it does.
I know it wraps discover
but I'm not convinced by libp2p's naming.
swarm | ||
.register(rendezvous_point, rendezvous_point_address, Some(MAX_TTL)) | ||
.await?; |
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.
Does this simply "stay on"? In other words, when does this function call exit?
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.
This function call exits as soon as the peer is registered. The peer knows this when it receives the Registered
event from the rendezvous point.
A cookie is passed into the discover function to only receive peers that have changed or joined since the last discover message was served. |
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.
Try to create a single example of using all these behaviors and you'll see how do you like the usage of the current abstraction. I have a feeling it would be easier to have a single behavior that specifies how the node operates.
@@ -0,0 +1,75 @@ | |||
# Peer Resolver | |||
|
|||
This library is intended for peer discovery in a libp2p network. |
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.
Could you remind me what is the expected usage of this library in our storage solution?
It's kinda hard to imagine for me whether those abstractions are correct, if we write the library first and the usage second.
This looks like a nice example, but not sure whether it will fit/how it will fit in our whole system.
Description
Add the peer-resolver library with bootstrap and client nodes using the rendezvous and identify protocols for peer discovery. Examples for bootstrap, identification and discovery have been added.