-
Notifications
You must be signed in to change notification settings - Fork 964
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
swarm: Split off "keep alive" functionality from DummyConnectionHandler
#2859
Conversation
() is the default associated type when creating implementations of traits with IDEs like IntelliJ Rust or rust-analyzer. Providing a `ConnectionHandler` implementation for those should make it easier for users to get started.
NetworkBehaviour
and ConnectionHandler
for ()
NetworkBehaviour
and ConnectionHandler
for ()
I have to give this more thought. I agree that it makes it harder to discover. Also I don't find the fact that
I think this is a good idea. |
I'll progress in this direction then! |
NetworkBehaviour
and ConnectionHandler
for ()
DummyConnectionHandler
This is ready for another review @mxinden ! |
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 for cleaning this up. Small suggestions on the naming of the two NetworkBehaviour
implementations.
Can you update the pull request description? |
Updated. Also added new questions. |
It is better for these to be grouped together rather than by what interface they are implementing.
I ended up introducing top-level |
Changelog and PR description are up to date. This is ready to be merged from my end. |
@thomaseizinger can you take a look at the clippy failure?
|
Ah yes, I expected that one to happen eventually. I originally got the warning because #2932 wasn't yet fixed! |
…2p into unit-connection-handler
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.
Ready to merge from my end otherwise.
swarm/src/dummy.rs
Outdated
use std::task::{Context, Poll}; | ||
use void::Void; | ||
|
||
/// Implementation of [`NetworkBehaviour`] that doesn't do anything other than keep all connections alive. |
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.
It does not keep connections alive, right?
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.
Absolutely correct. Thanks for spotting the typo!
Description
Previously, the
DummyConnectionHandler
offered a "keep alive" functionality, i.e. it allowed users to set the value of what is returned fromConnectionHandler::keep_alive
. This handler is primarily used in tests orNetworkBehaviour
s that don't open any connections (like mDNS). In all of these cases, it is statically known whether we want to keep connections alive. As such, this functionality is better represented by a staticKeepAliveConnectionHandler
that always returnsKeepAlive::Yes
and aDummyConnectionHandler
that always returnsKeepAlive::No
.To follow the naming conventions described in #2217, we introduce a top-level
keep_alive
anddummy
behaviour inlibp2p-swarm
that contains both theNetworkBehaviour
andConnectionHandler
implementation for either case.Links to any relevant issues
FromFn
ConnectionHandler
#2852: To actually replace "Ping"'sConnectionHandler
with aFromFn
ConnectionHandler
, we need to decouple the "Keep Alive" functionality from the Ping protocol. If this PR is accepted, I'd send a follow-up to remove the keep-alive functionality from ping in favor of using theKeepAliveBehaviour
.Open Questions
Implementations on()
are not as easy to discover. Should we retainDummyBehaviour
andDummyConnectionHandler
but strip the keep-alive logic from them?Should we rename theKeepAlive
toKeepAlivePolicy
(or something else) to avoid ambiguity withbehaviour::KeepAlive
?Should we strip the keep alive functionality fromlibp2p-ping
as part of this PR or in a follow-up?Change checklist
- [ ] I have added tests that prove my fix is effective or that my feature works