-
-
Notifications
You must be signed in to change notification settings - Fork 395
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
Horizontally scalable endpoints #1578
base: main
Are you sure you want to change the base?
Conversation
2262a6f
to
23afc97
Compare
Maybe split off the incidental cleanups/fixes into a separate PR? Easier to get through, and less prone to change (as in your latest insights from #1576, which I assume might affect this PR). (Maybe also the refactoring of mutable state, not sure how much sense that makes on its own?) |
Yep, I'll try to split this up some. I'm indeed wary of committing to the direction explored here prematurely; in particular I don't intend that we merge any major redesigns to how work is distributed/tasks are synchronized without careful benchmarking demonstrating similar or better performance under a broad range of workloads. There's a risk of optimizing for one shiny hypothetical case at the cost of other more immediate ones. |
Regarding the interior mutability, I do like the simpler API and behavior it entails, but that comes at the cost of greater risk of contention under worst-case conditions, which an attacker might deliberately produce. Not sure if it'll pan out. |
Unblocks interior mutability of the index and connections fields.
Allows a single `Endpoint` to be manipulated by multiple threads in parallel, unlocking new possibilities for horizontal scaling.
Locking the whole thing is no longer necessary now that Endpoint uses interior mutability.
Having a proper go at #1576. Reduces the inter-task communication required at the quinn layer by allowing connection tasks to manipulate the endpoint directly. Forms a strong foundation for a more incremental and performant attempt at #1219.
The high-level architecture is largely unchanged for now, but this is already enough for a hypothetical motivated quinn-proto user to implement good horizontal scaling.
This PR is organized into four major sections:
Incidental cleanup/fixesproto::Endpoint
&self
.proto::Connection
to call directly intoproto::Endpoint
rather than relying on the caller (e.g.quinn
) to pass messagesNext steps (probably in future PRs) might be to move ownership of
proto::Connection
s into theproto::Endpoint
, followed by finally attempting to unify the drivers again. We'll need to work out how to get multiple coarse endpoint drivers to play nicely with tokio before this can be completed.