-
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(dcutr): keep connection alive while we are using it #3960
Merged
Merged
Changes from 13 commits
Commits
Show all changes
19 commits
Select commit
Hold shift + click to select a range
1a0521f
keep connection alive while we are using it dcutr
tcoratger 7015af6
add changelog
tcoratger 6f9db5a
remove UpgradeFinishedDontKeepAlive variant in on_behaviour_event
tcoratger 72fc561
Merge branch 'master' into keepalive-dcutr
tcoratger aaf9274
Merge branch 'master' into keepalive-dcutr
tcoratger 26975c6
Fully remove enum variant
thomaseizinger 4081885
Track peer addresses in behaviour instead of sending it back and forth
thomaseizinger 8be8e54
Initialize handler with holepunch candidates
thomaseizinger 5c18d0f
Directly initialize handler with events
thomaseizinger b617f0f
Keep handler alive between attempts
thomaseizinger c01860a
Merge branch 'master' into keepalive-dcutr
tcoratger 1409fd9
Merge branch 'master' of https://github.com/libp2p/rust-libp2p into k…
mxinden fcf8ecc
Merge branch 'master' into keepalive-dcutr
tcoratger f32250e
Merge branch 'master' into keepalive-dcutr
tcoratger c6f8937
adjustments due to remove direct::Handler
tcoratger 5e14dc9
fix wip
tcoratger 89b6a83
fix push to queue in handle_established_outbound_connection
tcoratger 23b0cb0
remote_relayed_addr fix
tcoratger 4114cb3
remove peers_addresses
tcoratger File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Oops, something went wrong.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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.
Why no longer provide the
remote_relayed_addr
with theRemoteInitiatedDirectConnectionUpgrade
event? That would remove the need for explicit state tracking in theNetworkBehaviour
implementation and instead store the state close to its source, namely the connection.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.
Friendly ping. Am I missing something? This should eliminate the necessity for maintaining the state of Behaviour::remote_relayed_addr, correct?
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.
Yes-ish. The original idea was to not pass data back and forth. The behaviour learns about the address first so it is kind of redundant to pass it to the handler only to then pass it to the behaviour again.
On the flipside, not needing the hashmap removes a few error cases and simplifies the behaviour so I think it is a good idea.
@tcoratger Mind taking a look at this?
The idea would be to remove the
peer_addresses
hashmap and instead pass the address in theInboundConnectRequest
enum from the handler to the behaviour.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.
@thomaseizinger @mxinden Done. I hope I have understood everything correctly.
From what I have in mind, the
peers_addresses
hashmap of theBehavior
structure was used to list peer addresses. It was therefore updated when establishing or closing a connection.To replace this and avoid some bug-prone cases, we prefer to simplify the
behavior
and place the logic in thehandler
instead. So I started by completely removingpeers_addresses
which is no longer useful. Then I added theremote_addr
insideInboundConnectRequest
to pass the address information from the handler, closer to the source of the connection.Don't hesitate if there's something tricky that I didn't catch.