-
Notifications
You must be signed in to change notification settings - Fork 14
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
Align Slic connection dispose behavior with Quic #2225
Comments
And presumably, transportConnection.DisposeAsync does not wait for an outstanding CloseAsync to complete: it aborts it. Is this the correct semantics for multiplexed connection? See also dotnet/runtime#78641 (comment) Originally posted by @bernardnormier in #2289 (comment) |
Microsoft does not describe what they want to do when DisposeAsync is called while CloseAsync is in progress. Presumably it could be: We should ask Manicka on this issue 78641. And once we know, we do the same in Slic. |
The protocol connection disposal is now abortive like Slic. If we allow the transport Or should we push for a silent close implementation of I'm moving to 0.2 for now. |
See dotnet/runtime#96807 that fixes the issue I reported. We need to review how these changes are relevant with this issue. For instance, |
See #2183.
In general, I think Slic should behave like Quic whenever doable even if we think the Quic behavior is not the best. We can change Slic and keep in in sync with Quic over time; we have little control over .NET's Quic implementation.
In this particular case, SlicConnection.DisposeAsync should send a Close frame like Quic (or Quic will soon). The application error code would be a "default error code" set in the Slic options.
The text was updated successfully, but these errors were encountered: