-
Notifications
You must be signed in to change notification settings - Fork 56
ts_tunnel: give up on handshake initiation after enough retries #381
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
Merged
Merged
Changes from all commits
Commits
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 hidden or 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 hidden or 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
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.
this only happens if we're fighting with the peer for the initiator role, right (assuming no bugs in the state machine)? e.g. we initiate, the peer sends us back an initiation packet, so we become the receiver, but the timeout event isn't canceled, so it fires even though we're not initiator anymore.
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.
Hmm. I was going to say that it could happen either if the endpoint transitions from the initiator to the responder role, or if the handshake completion races with the timeout firing.
However, I think both of those cases should be covered by cancellation, because SentHandshake holds the handle for the timeout event. So, any transition to another handshake state would cancel the timeout event.
This makes me tempted to turn that defensive error into a hard assert that it never happens, but I'm not sure if I'm confident enough that we'll never go through the timeout codepath in a surprising state.
I'll merge this as-is on the basis that defensively doing nothing here is also correct, just maybe unnecessary. And I'll ponder things further and see if I can convince myself that it can be a hard invariant assertion 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.
The only other pathway to this case I see is if it were possible for two threads to run simultaneously, one handling recv and changing the handshake state, and the other doing dispatch_events and trying to act on the timeout event. The way the locking happens within Endpoint, the handling of the event and the handshake state change could interleave and lead to trying to handle a timeout for the wrong handshake state.
However, currently that is prevented by all those external methods taking &mut self. In the longer term if we want multiple parallel dataplanes, Endpoint will have to acquire more interior mutability and then we'll have to worry more about that scenario... But right now I think rust's borrowing rules guarantee that the existence of the timeout event is mutually exclusive with the handshake being in a different state.