-
Notifications
You must be signed in to change notification settings - Fork 995
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
Adding example for Identify protocol #2689
Conversation
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.
Appreciate the help here. Though still a couple of comments.
examples/identify.rs
Outdated
@@ -0,0 +1,82 @@ | |||
// Copyright 2018 Parity Technologies (UK) Ltd. |
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.
Given that this example is focused on libp2p-identify
, how about moving it to protocols/identify/examples/
? To make sure one can still discover it, it can be mentioned in https://github.com/libp2p/rust-libp2p/blob/master/examples/README.md.
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 was not even aware that there are some examples placed together with some of the individual protocols. Is there a reason why not to have all the examples listed in https://github.com/libp2p/rust-libp2p/tree/master/examples/*
?
Having one canonical place where all the examples are listed, IMHO makes discovery easier.
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.
No strong opinion on my end. I see /examples
as a folder for examples that combine many protocols and protocols/xxx/examples
as a folder for examples targeting a single protocol.
Having one canonical place where all the examples are listed, IMHO makes discovery easier.
I see your point.
Maybe @elenaf9 or @thomaseizinger have an opinion here.
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 am leaning towards having examples focused on a single protocol in that protocol's folder. Since they are individual crates, imo they should "own" their own examples.
I was not even aware that there are some examples placed together with some of the individual protocols.
We should definitely mention this in the top-level examples/README.md
, which is currently not the case.
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 am leaning towards having examples focused on a single protocol in that protocol's folder. Since they are individual crates, imo they should "own" their own examples.
I share the same view. These protocols are individual crates and I think we should follow cargo conventions despite this being a large workspace.
I was not even aware that there are some examples placed together with some of the individual protocols.
We should definitely mention this in the top-level
examples/README.md
, which is currently not the case.
Another solution to this would be to do away with the current meta crate being "special" by being a workspace manifest and a crate at the same time. i.e. we could create a directory meta
which could house the libp2p
crate. This would also move the top-level examples/
directory which might make it more obvious to users that they will find examples within each crate.
examples/identify.rs
Outdated
//! cargo run --example identify | ||
//! ``` | ||
//! It will print the PeerId and the listening addresses, e.g. `Listening on | ||
//! "/ip4/0.0.0.0/tcp/24915"` |
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.
//! "/ip4/0.0.0.0/tcp/24915"` | |
//! "/ip6/2001:db8:: /tcp/24915"` |
Let's not use a wildcard address here.
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.
Given that we called swarm.listen_on
with a ipv4 wildcard address, this can never result in a ipv6 listen address, right? Thus think "/ip4/127.0.0.1/tcp/24915"
would make more sense here.
Co-authored-by: Max Inden <[email protected]>
Co-authored-by: Max Inden <[email protected]>
Co-authored-by: Max Inden <[email protected]>
Co-authored-by: Max Inden <[email protected]>
Co-authored-by: Max Inden <[email protected]>
Co-authored-by: Max Inden <[email protected]>
Gladly done. I will resolve/respond the comments in a bit. Quick question, seeing you already approved, do you prefer I create individual PR for each example added? Let me know which approach the team finds more convenient. |
That was a mistake. Sorry.
Yes. I prefer small atomic pull requests. Makes my life as a maintainer a lot easier. Thanks. |
examples/identify.rs
Outdated
@@ -0,0 +1,82 @@ | |||
// Copyright 2018 Parity Technologies (UK) Ltd. |
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.
No strong opinion on my end. I see /examples
as a folder for examples that combine many protocols and protocols/xxx/examples
as a folder for examples targeting a single protocol.
Having one canonical place where all the examples are listed, IMHO makes discovery easier.
I see your point.
Maybe @elenaf9 or @thomaseizinger have an opinion here.
Co-authored-by: Max Inden <[email protected]>
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.
🚀 Thank you!
CI failures are due to libp2p/if-watch#19. |
This is fixed now. To make CI green you would need to:
|
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.
Thanks @dadepo! Two comments, otherwise looks good to me.
examples/identify.rs
Outdated
//! cargo run --example identify | ||
//! ``` | ||
//! It will print the PeerId and the listening addresses, e.g. `Listening on | ||
//! "/ip4/0.0.0.0/tcp/24915"` |
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.
Given that we called swarm.listen_on
with a ipv4 wildcard address, this can never result in a ipv6 listen address, right? Thus think "/ip4/127.0.0.1/tcp/24915"
would make more sense here.
//! The dialing node prints out the `PeerId` of the node it is sending identify info to | ||
//! The other node prints out the received identify info. |
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 think not only the dialer, but instead both peers will sent each other identify info once they establish a connection, no?
Description
Added example for the Identify protocol.
Links to any relevant issues
Part of #2684
Change checklist