-
Notifications
You must be signed in to change notification settings - Fork 1k
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(transport): allow ListenerId
to be user-controlled
#3567
Conversation
Can you run rustfmt? I'll have a look at the code over the next days. It is a breaking change so we'll likely hold off a bit on merging that to reduce the rate of breaking changes. |
Agree with that. |
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 in favor of this but it is a breaking change so we can't merge it immediately.
Test failure should go away once you update to latest master. |
This comment was marked as resolved.
This comment was marked as resolved.
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'd like to move away from random ListenerId
s and instead use the same pattern we used for ConnectionId
s: a static atomic counter.
core/src/transport.rs
Outdated
@@ -54,6 +55,8 @@ pub use self::memory::MemoryTransport; | |||
pub use self::optional::OptionalTransport; | |||
pub use self::upgrade::Upgrade; | |||
|
|||
static NEXT_LISTENER_ID: AtomicU64 = AtomicU64::new(1); |
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.
Should we change this to AtomicUsize
and use usize in ListenerId
instead?
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 don't think it really matters, happy to leave it as a u64. What do you think?
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 we can leave it
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.
Adding to the above the argument of portability.
PowerPC and MIPS platforms with 32-bit pointers do not have AtomicU64 or AtomicI64 types.
https://doc.rust-lang.org/std/sync/atomic/index.html#portability
Thus slight preference for AtomicUsize
from my end. Also consistent with ConnectionId
.
ListenerId
to be user-controlled
Looking forward to this! I updated the PR description to reflect why we are doing this. Once the remaining comments are resolved, I'd also like @mxinden to have a look at this although I do think we are in agreement 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.
LGTM, thanks for the effort!
I would like @mxinden to also review this.
Co-authored-by: Thomas Eizinger <[email protected]>
This pull request has merge conflicts. Could you please resolve them @dariusc93? 🙏 |
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.
Minor comments. This is good to go from my end. Thank you for the work @dariusc93!
core/src/transport.rs
Outdated
@@ -54,6 +55,8 @@ pub use self::memory::MemoryTransport; | |||
pub use self::optional::OptionalTransport; | |||
pub use self::upgrade::Upgrade; | |||
|
|||
static NEXT_LISTENER_ID: AtomicU64 = AtomicU64::new(1); |
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.
Adding to the above the argument of portability.
PowerPC and MIPS platforms with 32-bit pointers do not have AtomicU64 or AtomicI64 types.
https://doc.rust-lang.org/std/sync/atomic/index.html#portability
Thus slight preference for AtomicUsize
from my end. Also consistent with ConnectionId
.
Co-authored-by: Max Inden <[email protected]>
Co-authored-by: Max Inden <[email protected]>
Approvals have been dismissed because the PR was updated after the send-it
label was applied.
Description
Transport::listen_on
is an asynchronous operation. It returns immediately but the actual process of establishing a listening socket happens as part ofTransport::poll
which will return one or moreTransportEvent
s related to a particularlisten_on
call.Currently,
listen_on
returns aListenerId
which allows the user of theTransport
interface to correlate the events with a particularlisten_on
call. This "user" is theSwarm
runtime. Currently, a user of libp2p establishes a new listening socket by talking to theSwarm::listen_on
interface and it is not possible to do the same thing via theNetworkBehaviour
trait.Within the
NetworkBehaviour
trait, we emit commands to theSwarm
likeToSwarm::Dial
. These commands don't have a "return value" like a synchronous function does and thus, if we were to add aToSwarm::ListenOn
command, it could not receive theListenerId
from theTransport
.To fix this and to be consistent with our coding guidelines we change the interface of
Transport::listen_on
to require the user to pass in aListenerId
. This will allow us to construct a command in aNetworkBehaviour
that remembers this ID which enables precise tracking of which events containing aListenerId
correlate which a particularlisten_on
command.This is especially important in the context of listening on wildcard addresses like
0.0.0.0
because we end up binding to multiple network interfaces and thus emit multiple events for a singlelisten_on
call.Notes
Links to any relevant issues
Open Questions
Transport::listen_on
return aListenerId
? This PR doesnt have it return it since its redundant now, but not sure if anybody else feel the same way.Change checklist