-
Notifications
You must be signed in to change notification settings - Fork 4.8k
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
Asynchronous opening of QuicStreams #67859
Conversation
Note regarding the This serves as a reminder for when your PR is modifying a ref *.cs file and adding/modifying public APIs, to please make sure the API implementation in the src *.cs file is documented with triple slash comments, so the PR reviewers can sign off that change. |
Tagging subscribers to this area: @dotnet/ncl Issue DetailsThis PR removes Fixes #67302.
|
src/libraries/System.Net.Http/src/System/Net/Http/SocketsHttpHandler/Http3Connection.cs
Outdated
Show resolved
Hide resolved
src/libraries/System.Net.Quic/src/System/Net/Quic/Implementations/MsQuic/MsQuicStream.cs
Outdated
Show resolved
Hide resolved
/azp run runtime-libraries-coreclr outerloop |
Azure Pipelines successfully started running 1 pipeline(s). |
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.
Apart from the comments, have you also thought about how we could solve the problem with multiple H/3 connections and opening streams on the first connection that has streams available? Without relying on WaitForStreamsAvailable
and GetAvailableStreamCount
since they both are rather expensive operations.
I'm not saying it needs to be solved in this issue, we can postpone it to API discussion for stream.
src/libraries/System.Net.Http/src/System/Net/Http/SocketsHttpHandler/Http3Connection.cs
Outdated
Show resolved
Hide resolved
src/libraries/System.Net.Quic/src/System/Net/Quic/Implementations/MsQuic/MsQuicConnection.cs
Outdated
Show resolved
Hide resolved
src/libraries/System.Net.Quic/src/System/Net/Quic/Implementations/MsQuic/MsQuicStream.cs
Outdated
Show resolved
Hide resolved
src/libraries/System.Net.Quic/src/System/Net/Quic/Implementations/MsQuic/MsQuicStream.cs
Outdated
Show resolved
Hide resolved
Isn't this against the RFC?
Anyway, I thought about it and it seems to me that achieving this would be very complex. Part of the problem could be covere by having a method such as The part where no connection has available streams and we need to wait untile one does is the problematic part. The core part of a solution that occured to me was to use the alternative would be handling all this externally using a |
src/libraries/System.Net.Quic/src/System/Net/Quic/Implementations/MsQuic/MsQuicStream.cs
Outdated
Show resolved
Hide resolved
Yes it is, the same way HTTP/2 multiple connections are. We default to a single connection and it can be turned on via
That's what we had before, more or less, and it was very perf intensive. So we'd like to take advantage of msquic being able to do the stream counting/waiting for us, since that seems much more performant than what we attempted to do. Anyway, this is not a hard requirement for this PR. |
For some reason I cannot reply to your last comment about exception type @rzikm, but you can use |
src/libraries/System.Net.Http/src/System/Net/Http/SocketsHttpHandler/Http3Connection.cs
Outdated
Show resolved
Hide resolved
src/libraries/System.Net.Http/src/System/Net/Http/SocketsHttpHandler/Http3Connection.cs
Outdated
Show resolved
Hide resolved
src/libraries/System.Net.Quic/src/System/Net/Quic/Implementations/MsQuic/MsQuicStream.cs
Show resolved
Hide resolved
src/libraries/System.Net.Quic/tests/FunctionalTests/MsQuicTests.cs
Outdated
Show resolved
Hide resolved
@ManickaP, I don't believe this is the right thing to do. From the user's perspective the code should throw only |
src/libraries/System.Net.Quic/tests/FunctionalTests/QuicConnectionTests.cs
Outdated
Show resolved
Hide resolved
src/libraries/System.Net.Quic/src/System/Net/Quic/Implementations/MsQuic/MsQuicStream.cs
Outdated
Show resolved
Hide resolved
src/libraries/System.Net.Quic/src/System/Net/Quic/Implementations/MsQuic/MsQuicStream.cs
Outdated
Show resolved
Hide resolved
src/libraries/System.Net.Quic/src/System/Net/Quic/Implementations/MsQuic/MsQuicStream.cs
Outdated
Show resolved
Hide resolved
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.
LGTM, I think 😄
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! 🚀
Test failures are unrelated (work item failures in unrelated libraries) |
Perf auto-filing seems to think this PR might have lead to these improvements: not sure though. |
This PR removes
Open(Uni|Bi)directionalStream
methods onQuicConnection
and replaces them with asynchronous variants. If no stream is available, the methods block until the peer's stream limit is increased.Most of the changes outside
MsQuicStream
andMsQuicConnection
are just updating usages.Fixes #67302.