-
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
API review for QUIC APIs #48686
Comments
Tagging subscribers to this area: @dotnet/ncl Issue DetailsPlaceholder for API review of QUIC APIs. @ManickaP @CarnaViire @karelz we should try to get all the APIs designed soon. The API review will take some time (probably 4-8hr). Also mindful of any time @halter73 @jkotalik need to prove the APIs out in Kestrel.
|
I created #44786 a while back to try to capture the existing open issues. It may be missing some issues. That said, we need to do a review of the entire API surface. |
I wish there's a way to use the underlying QUIC connection of HTTP/3 to send/receive custom datagrams, such that unreliable data may be multiplexed along the same SignalR connection. See also wegylexy#1 |
@wegylexy I really like the idea of adding datagram support and hope this gets in! Would it be possible to use an async method instead of an event for the datagram receive? I think this would be more in line with the async socket apis. |
Looking through some of the existing QUIC implementation in Kestrel, and the work @scalablecory has done to support msquic 1.0, it would be great if the hooks were available to support a 3rd party WebTransport/QuicTransport implementation in Kestrel. I think it would just require exposing the Kestrel QUIC classes and letting someone write a thin layer to set the correct apln. |
Since msquic doesn't transfer ownership of the received datagram buffer, it must be consumed synchronously (e.g. through a |
@wegylexy please create a new issue with proposed API. Note the datagram RFC has not been finished yet, so we will likely not support this in .NET 6. |
msquic has changed a lot too? |
We have a dependency on a certain msquic revision, see the git submodule here: https://github.com/dotnet/runtimelab/tree/feature/System.Net.Experimental.MsQuic/src |
Significant changes since microsoft/msquic#777 but this is the first stable supported release version. |
@wegylexy @scalablecory has done some work here (https://github.com/scalablecory/runtime/tree/msquic-update) on updating |
Great, it works. And I put back support for certificate file for OpenSSL, hoping it to work on Linux but haven't got the time to test yet. scalablecory#1 |
Played around with msquic 1.3.0 openssl on Linux and Windows, and it works. Datagram API in my fork also works. The only thing is that it always wastes time to verify the chain, even for self-signed certs without a chain, even when the validation callback is simply |
@mclayton7 async receipt of datagrams would hurt performance, see microsoft/msquic#1654 |
The datagram spec is still not RFCed. We'll likely be ready to consider a datagram API for .NET 7. I'm aware you've prototyped it, and would be really happy to see you involved in API discussion and a PR from you once we're ready for it. If you can create a new issue with the proposed datagram APIs, that's where we'll want to start. |
created #53533 for datagram API suggestion just now |
oh, I see. it's still |
Triage: We will create new issues for formal API reviews based on work in #44786. Closing |
Placeholder for API review of QUIC APIs.
@ManickaP @CarnaViire @karelz we should try to get all the APIs designed soon. The API review will take some time (probably 4-8hr). Also mindful of any time @halter73 @jkotalik need to prove the APIs out in Kestrel.
Tracking API changes:
The text was updated successfully, but these errors were encountered: