compio-rs and quic using native tls on Windows or use msquic?

[simplejackcoder]

Can compio-rs use native tls when in quic? I guess it maybe quinn question, but you use quinn proto so i assume it can be all plugged and changed.

Also, have you thought about using msquic crate?

there is a need for quic server on windows, but worry is quinn on windows may not be amazing?

any how please comment and let me know.

amazing project, needs more marketing.

[Berrysoft]

1. native-tls is not enough. QUIC is a protocol that also involves TLS. native-tls doesn't expose the required APIs. openssl might be OK, but it needs a relatively high version of openssl.
2. Yes, we have thought about msquic crate. However, as a binding crate in Rust, msquic is awful. It is just a placeholder but not a convenient one. Furthermore, msquic is not easy to be integrated into IOCP.
3. Any implementation of QUIC on Windows is amazing. It is a new tech, and anyone who adopt it is honorable.

[simplejackcoder]

this is what i'm looking for integrating msquic with iocp in rust. does seem painful. but msquic has a feature I need, ability to use different alpn only and same port for different windows processes.

[Berrysoft]

The alpn of compio-quic is set with rustls, I think. If you need that, feel free to create a PR.

[OpenTritium]

Was gm-quic ever considered as well?

[umbrageodotus]

@Berrysoft what about using s2n-quic from Amazon? As fast as quiche while having around the same test coverage as quinn.

[umbrageodotus]

qm-quic also sounds nice. Thanks @OpenTritium

[George-Miao]

We actually evaluated all the quic libraries available at the time, including s2n. I don't recall the exact reason why we didn't use it but I'm definitely sure about one thing, the codebase of s2n quic is unlike ANY other library you would find from a rust library. It's super tedious, bloated with java-like abstraction (factory and provider trait for EVERY config etc), relies heavily on macros and was really hard for me to get started on.

[umbrageodotus]

@George-Miao What about gm_quic?

[George-Miao]

Yea that one was missed. Maybe we can try? I don't know, haven't looked at the document yet.

[umbrageodotus]

I think it looks good enough to try.

[AsakuraMizu]

I'm the one who developed compio-quic. Let me explain.

• Why quinn: It's popular and widely used. (I've heard that quiche is only used internally at Cloudflare) Most importantly, it's easy to integrate.
• Why not native-tls/xxx: Quinn does not support it. Even if you want to add support, it is best to do it upstream. There was actually an attempt to support boringssl (quinn-boring), but it seems to be no longer maintained.
• Why not s2n-quic: It's split into a hundred sub-crates, and all of them just say "This is an internal crate used by s2n-quic. The API is not currently stable and should not be used directly." Well, I don't have time to care about what it does internally.
• Why not gm-quic: It hadn't even released 0.0.1 when I started working on compio-quic. I didn't even know about it until yesterday. That's it.

[umbrageodotus]

@AsakuraMizu So would it be good too port to gm-quic now it's semi-stable?

[AsakuraMizu]

Yeah, maybe you can give it a try. The bad news is that it depends heavily on Tokio, so porting might be a bit tricky... Anyway, contributions are welcome!

[umbrageodotus]

Okie! Are there any benefits to that over quinn except performance and maybe compatibility though?

[AsakuraMizu]

idk I haven't dived into it yet.