-
-
Notifications
You must be signed in to change notification settings - Fork 396
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
Variable length connection IDs #1879
base: main
Are you sure you want to change the base?
Conversation
@@ -561,22 +558,6 @@ impl Endpoint { | |||
.. | |||
} = incoming.packet.header; | |||
|
|||
if self.cids_exhausted() { |
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.
One option is, changing return type of the ConnectionIdGenerator.generate_cid
to Result<ConnectionId, SomeError>
, so that if the implementation of ConnectionIdGenerator
is willing to perform exhausted check, it could return an Err(CidExhausted)
. But since it must be a breaking change, I'm not sure if it's worth to do it in this way.
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.
These changes are breaking regardless, so we might as well take the cleanest approach. However:
- The generator would need to know the total number of live CIDs, requiring additional complexity
- Large deployments might have a difficult time tracking the number of CIDs in use in a shared space across multiple endpoints
- It's not clear if this check is all that useful to begin with
I'm presently leaning towards a simpler approach that just gives up if it can't generate a unique CID after some number of tries, to at least handle the case where someone is using an extremely small CID space for some reason.
7479835
to
2757df1
Compare
077fa06
to
5ceba42
Compare
Allows generators to be shared with connections, and removes an obstacle to parallelizing endpoint work in the future.
Now that CID generators can have shared ownership, there's no need to indirect through a factory function in the config.
We can't track this if the size of the CID space isn't readily known, and we already implicitly rely on `new_cid` being infallible.
5ceba42
to
615a1ed
Compare
This is a breaking change with no pressing demand.