-
Notifications
You must be signed in to change notification settings - Fork 4.7k
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
[QUIC] Rewrite Open(Uni|Bidi)rectionalStream to leverage async stream opening #67302
Comments
Tagging subscribers to this area: @dotnet/ncl Issue DetailsOur current API for opening a QuicStream is synchronous and will throw if stream limit is reached. Waiting for available streams was intended to be a loop of checking for available stream count: runtime/src/libraries/System.Net.Http/src/System/Net/Http/SocketsHttpHandler/Http3Connection.cs Lines 183 to 200 in c9f7f73
This proved to be highly inefficient - adding this loop around the opening eats up 80% of perf even when there's no actual need to wait. MsQuic has it's own waiting logic implemented, and opening a stream can be asynchronous. As soon as stream is available, START_COMPLETE event will come to the stream. This can be done by passing ASYNC flag instead of FAIL_BLOCKED to StreamStart. We need to:
Some thoughts:
Note: since msquic 2.0 I believe there will be no ASYNC flag anymore because async behavior is the default. (NONE flag)
|
I'm disabling 2 tests against this issue, because Open...directionalStream doesn't throw at the moment (the result gets returned in the callback). |
We've just merged an API change for quic stream opening ( I believe you would need changes in opening control streams in Kestrel (I guess here https://github.com/dotnet/aspnetcore/blob/main/src/Servers/Kestrel/Transport.Quic/src/Internal/QuicConnectionContext.cs#L192-L207). The change should be super easy, but let us know if you need our help |
Our current API for opening a QuicStream is synchronous and will throw if stream limit is reached. Waiting for available streams was intended to be a loop of checking for available stream count:
runtime/src/libraries/System.Net.Http/src/System/Net/Http/SocketsHttpHandler/Http3Connection.cs
Lines 183 to 200 in c9f7f73
This proved to be highly inefficient - adding this loop around the opening eats up 80% of perf even when there's no actual need to wait.
MsQuic has it's own waiting logic implemented, and opening a stream can be asynchronous. As soon as stream is available, START_COMPLETE event will come to the stream. This can be done by passing ASYNC flag instead of FAIL_BLOCKED to StreamStart.
We need to:
Some thoughts:
Note: since msquic 2.0 I believe there will be no ASYNC flag anymore because async behavior is the default. (NONE flag)
Note 2: this is only for outbound streams. Inbound streams are already started when accepted.
The text was updated successfully, but these errors were encountered: