-
Notifications
You must be signed in to change notification settings - Fork 113
Improve connection management #266
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
Improve connection management #266
Conversation
7b4b7d5 to
5b56a8b
Compare
jkczyz
left a comment
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.
Commits specific to this PR LGTM. Didn't review the commits from based PRs.
Also, in commit message for 5b56a8b:
s/task is responsible/task responsible
tests/integration_tests_rust.rs
Outdated
| let node_id_b = node_b.node_id(); | ||
| let node_addr_b = node_b.listening_addresses().unwrap().first().unwrap().clone(); | ||
|
|
||
| std::thread::sleep(std::time::Duration::from_secs(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.
Could you add a comment on why the sleep is needed? Is there any way to avoid 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.
Added a comment here as well as to do_connection_restart_behavior. The sleep is necessary to allow the listening task of the connected node to spawn and bind successfully before we try connecting to it.
It could be avoidable if we introduced a mechanism to Node::start that would wait for the task to come up. However, I currently don't think it's worth it as on the contrary we try to keep Node::startas quick as possible, i.e., try to push everything possible to background tasks in order to improve startup time.
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 we have an is_listening method, even if only for testing?
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.
5b56a8b to
5c9e930
Compare
5c9e930 to
785543d
Compare
e781c08 to
d60f009
Compare
d60f009 to
c971535
Compare
|
Rebased after #272 was merged to resolve minor conflicts. |
2efc3b9 to
f2f1ab2
Compare
f2f1ab2 to
7d6e260
Compare
|
Rebased on #244. |
eac8e26 to
85a6803
Compare
.. just a minor cleanup to further modularize the codebase. Also, we'll be reusing these methods in `Event::ConnectionNeeded` soon.
.. we should consider dropping `Deref` and instead just commiting to store a `Arc<L>` everwhere, as it gets tedious to maintain. However, this is barely scraping by and the least invasive change here.
.. which is a bit more readable and in-line what we do other places, plus it allows us to drop the `futures` dependency.
... we check that we can successfully issue concurrent connection attempts, which all succeed.
Previously, concurrent calls to `do_connect_peer`/`connect_peer_if_necessary` could result in multiple connections being opened, just to be closed as redundant shortly after. Parallel connection attempt were therefore prone to fail. Here, we introduce a `ConnectionManager` that implements a pub/sub pattern: upon the initial call, the task responsible for polling the connection future to completion registers that a connection is in-flight. Any calls following will check this and register a `oneshot` channel to be notified of the `Result`.
85a6803 to
77c538b
Compare
|
Rebased on main and squashed fixups without further changes. |
Based on #243.
Based on #244.
As a pre-factor to #256, we clean up our connection handling. Namely, we move it to a new
connection.rsfile and clean up the logic a bit, allowing us to drop the dependency on thefuturescrate.Then, we introduce a
ConnectionManagerthat handles pending connection attempts. Previously, concurrent calls todo_connect_peer/connect_peer_if_necessarycould result in multiple connections being opened, just to be closed as redundant shortly after. Here, we fix this behavior by ensuring only one connection attempt is inflight at any given point in time.