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.
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
Implement full-duplex secret connection #938
Implement full-duplex secret connection #938
Changes from 7 commits
02a94f6
31b8cad
94c43c0
8e7f694
1409f91
b161ba5
b48fb23
0a90dc3
3c45316
1d2f658
4c60492
929eeb5
465d627
34a7de5
b220c8f
ba3b16c
e65aeee
1f6a706
8627925
6571b59
042b3f4
c5be1b4
9da6097
2c9aafe
4f32c17
b8913c0
68ad278
a9c9b98
2d5ef8b
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
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 return error result here instead of panicking? Same for the other uses of
.expect()
.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.
How would we (and should we be able to) recover from such an error?
My understanding is that, when
Mutex::lock
fails, it's due to a panic while the lock is held by another thread.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.
Sounds reasonable. Perhaps we can add a comment here that we are panicking because a poisoned mutex is unrecoverable. This is mainly to distinguish it from the other uses of
.expect
in the same file, which IMO should be refactored to returnResult::Err
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.
Fortunately in the new iteration there's no need for mutexes any more 😁
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 have higher level abstraction to guarantee that the nonce is always incremented after being acquired? Or should it never be incremented at all if there is error? Would the state be inconsistent if the line above or below returns error prematurely?
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.
@tony-iqlusion, what's your take on this?
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.
Preventing nonce reuse is the most important thing as it fails catastrophically with ChaCha20Poly1305, but also if it's ever incremented without being used it will be out-of-sync with the peer and abort the connection that way.
So it's best to have a sort of simple state machine that aborts the whole connection on errors, and if that can wipe the nonce somehow that's best, but so long as you can prevent repeat nonce reuse that's probably the most important thing.
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.
What is the advantage of using this trait as compared to holding an
Arc<IoHandler>
andClone
?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.
See #938 (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.
Would it be simpler if we just use
TcpStream::try_clone(self)
here and not having to explain in the 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.
It wasn't obvious to me whether the
TcpStream
'stry_clone
method was going to be called here or theTryClone
trait'stry_clone
, so I thought I'd leave a comment here for posterity to explain 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.
Oh, also, I tried explicitly calling
TcpStream::try_clone(self)
here and clippy complains that the better approach is to useSelf::try_clone(self)
, which, to me, isn't nearly as clear asTcpStream::try_clone(self)
.