-
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
QUIC stream limits #52704
QUIC stream limits #52704
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 DetailsImplements the 3rd option Allowing the caller to perform their own wait from #32079 (comment)
Fixes #32079 Note: working on adding more tests, opening PR to kick off discussion.
|
Why do this? Seems like this would be bad for H3 perf. |
public long GetRemoteAvailableUnidirectionalStreamCount() { throw null; } | ||
public System.Net.Quic.QuicStream OpenBidirectionalStream() { throw null; } | ||
public System.Net.Quic.QuicStream OpenUnidirectionalStream() { throw null; } | ||
public int GetRemoteAvailableBidirectionalStreamCount() { throw null; } |
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.
Why was this changed? Is it limited to int.Max by QUIC itself?
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.
Msquic returns ushort
:
runtime/src/libraries/System.Net.Quic/src/System/Net/Quic/Implementations/MsQuic/MsQuicConnection.cs
Lines 338 to 346 in 51b6188
internal override long GetRemoteAvailableUnidirectionalStreamCount() | |
{ | |
return MsQuicParameterHelpers.GetUShortParam(MsQuicApi.Api, _state.Handle, QUIC_PARAM_LEVEL.CONNECTION, (uint)QUIC_PARAM_CONN.LOCAL_UNIDI_STREAM_COUNT); | |
} | |
internal override long GetRemoteAvailableBidirectionalStreamCount() | |
{ | |
return MsQuicParameterHelpers.GetUShortParam(MsQuicApi.Api, _state.Handle, QUIC_PARAM_LEVEL.CONNECTION, (uint)QUIC_PARAM_CONN.LOCAL_BIDI_STREAM_COUNT); | |
} |
AFAIK, we usually go with signed types for APIs ==>
int
.
I'm aware that QUIC sends long
-range values in MAX_STREAMS frame, but that's cumulative number of streams which msquic hides from us. This is probably the original motivation for the long
type.
Once again, I'm not against keeping it long
. We discussed it briefly in one of our meetings and the consensus was for int
so I went ahead with the change.
...m.Net.Quic/src/System/Net/Quic/Implementations/MsQuic/Internal/ResettableCompletionSource.cs
Outdated
Show resolved
Hide resolved
@@ -53,6 +53,56 @@ public async Task UnidirectionalAndBidirectionalChangeValues() | |||
Assert.Equal(20, serverConnection.GetRemoteAvailableUnidirectionalStreamCount()); | |||
} | |||
|
|||
[Fact] | |||
[ActiveIssue("https://github.com/dotnet/runtime/issues/52048")] |
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 2 new tests pass on their own but if run within the whole suite they cause the crash with stream being finalized after the connection. That should be fixed with #52800, I'll revisit it enabling them afterwards.
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.
We discussed offline that it is caused by not accepted stream getting stuck inside accept queue and not being disposed there. You can try accepting it (after all test checks if it's important for the test) and disposing manually, or you may wait for Tomas' fix, your choice.
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
ff29d76
to
df0d529
Compare
653c080
to
6609348
Compare
544bea4
to
cabc0eb
Compare
src/libraries/System.Net.Http/src/System/Net/Http/SocketsHttpHandler/Http3Connection.cs
Outdated
Show resolved
Hide resolved
cabc0eb
to
719df10
Compare
LGTM, waiting on test cleanup and resolving a question about two locks vs one |
719df10
to
cbdd1df
Compare
I moved the experiments with the failing test into its own branch and disabled it in this PR (with an ActiveIssue). |
src/libraries/System.Net.Quic/src/System/Net/Quic/Implementations/MsQuic/MsQuicConnection.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, but it would be great if @scalablecory or @geoffkizer could also take a look.
9ea99fa
to
7eb7fb1
Compare
Implements the 3rd option Allowing the caller to perform their own wait from #32079 (comment)
WaitForAvailable(Bidi|Uni)rectionalStreamsAsync
:QUIC_CONNECTION_EVENT_TYPE.STREAMS_AVAILABLE
)QuicConnectionAbortedException
which fitted our H3 better than boolean (can be changed)MakesOpen(Bidi|Uni)directionalStreamAsync
:asynchronous, awaiting msquic eventQUIC_STREAM_EVENT_TYPE.START_COMPLETE
throwing if there's no stream capacityQUIC_STREAM_START_FLAGS.FAIL_BLOCKED
immediately notifying the peer about stream being openedQUIC_STREAM_START_FLAGS.IMMEDIATE
int
Fixes #32079
Note: working on adding more tests, opening PR to kick off discussion.