-
-
Notifications
You must be signed in to change notification settings - Fork 423
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
Support customized Cid generation #851
Conversation
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 the PR! I agree that we should expose something like this, e.g. to support load balancers. Out of curiosity, are you doing something with Quinn that requires this in practice?
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 the updates! Made a deep pass; mostly cosmetic issues.
Co-authored-by: Benjamin Saunders <ben.e.saunders@gmail.com>
Co-authored-by: Benjamin Saunders <ben.e.saunders@gmail.com>
Co-authored-by: Benjamin Saunders <ben.e.saunders@gmail.com>
Co-authored-by: Benjamin Saunders <ben.e.saunders@gmail.com>
Co-authored-by: Benjamin Saunders <ben.e.saunders@gmail.com>
Co-authored-by: Benjamin Saunders <ben.e.saunders@gmail.com>
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 your work!
Appreciate your time @Ralith ! |
Could you squash and merge these commits so I can push a new PR? Thanks |
I'd prefer to get a signoff from @djc first. You can make a new PR based on this branch, and when we merge this to master you should be able to rebase the new PR onto master without issue, and I'll happily review the new parts in the mean time. You could also squash this branch into a single commit yourself first for extra insurance against git getting tangled up. |
…to implement CID generator
Just realize that I need to remove 'crate' from |
Whoops, good catch. |
The error from CI is mysterious. I am using a Mac and all tests pass on my side. |
There's a similar issue on #850; I'm guessing it's on github's end and we should ignore it. |
Please not merge the PR now. I need to update the CID generator trait for proactive cid rotation liwenjieQu#1 where the lifetime/duration of a CID needs to be returned. I think it is better to declare in the very beginning to avoid breaking compatibility |
…t breaks compatibility
Sorry for the inconvenience that the PR has to be reviewed again. |
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.
Good catch. Minor API breakage isn't the end of the world at present, but might as well avoid it when we can.
Co-authored-by: Benjamin Saunders <ben.e.saunders@gmail.com>
Sorry for the delayed review -- thanks for working on this, it looks pretty good! |
@@ -341,7 +345,7 @@ where | |||
if self.is_full() { | |||
return Err(ConnectError::TooManyConnections); | |||
} | |||
let remote_id = ConnectionId::random(&mut self.rng, MAX_CID_SIZE); | |||
let (remote_id, _) = RandomConnectionIdGenerator::new(MAX_CID_SIZE).generate_cid(); |
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.
@liwenjieQu Is there any reason we hardcode the generator here, and don't use the local_cid_generator
? The main difference I see between RandomConnectionIdGenerator
vs local_cid_generator
is the cid_len
.
Here we pass remote_id
to add_connection
. However inside that function, we pass self._local_cid_generator
to Connection::new
which uses its length, instead of the length of remote_id
(which was generated by RandomConnectionIdGenerator
).
Should we change this to be self.local_cid_generator.generate_cid()
for consistency.?
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.
Note the name remote_id
; we're generating a destination connection ID here, not a local one. The client uses a random destination connection ID for its initial flight of packets; see https://quicwg.org/base-drafts/draft-ietf-quic-transport.html#name-negotiating-connection-ids for details.
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.
@Ralith Thanks for the explanation! That clears it up.
Currently Quinn generates cid using random number only. Some use case may require a more sophisticated cid structure. This change mainly add a
ConnectionIdGenerator
trait that allows to use any customized cid generator.