QUIC protocol support in tokio

[00imvj00]

Hello, i was thinking it would be great if tokio can provide QUIC(https://www.chromium.org/quic) protocol support inbuilt with tcp and udp.

Any plas for that ?

[Ralith]

I’m working on a QUIC implementation that will eventually include tokio support. Tokio ships with UDP and TCP support because those are built into most kernels; for QUIC, a separate crate makes sense.

[djc]

I’m also working on a QUIC implementation, which I will talk about in my RustFest presentation. This will be based on tokio from the start (the server part is already built around tokio and futures), and should rapidly improve over the next few weeks. I also want to talk to the hyper and h2 folks to see if we can cooperate on integrating the entire HTTP stack.

[Ralith]

I’ve completed the tokio front-end to quicr and published it to crates.io. There’s probably plenty of bugs, but it’s successfully performing all basic functions against every other similarly complete QUIC implementation I can find as a client, and against itself as both client and server. The API is reasonably filled out and ready for experimental use; you can drop in a quicr::Stream anywhere you’re currently using a tokio TcpStream.

Unfortunately, docs.rs is failing to build the docs due to the bleeding-edge OpenSSL dependency, but hopefully we’ll be able to replace that with rustls before too long.

[imp]

Gentlemen,

two competing implementations is nice, but that puts the potential consumer in the inevitable situation of choosing between the two without any guidance. Both crates appear to be active, however, only one of them is published on crates.io (quinn is not there). So, care to share your plans? Perhaps it may be practical to consider merging the projects?

[djc]

We came to the same conclusion. Here’s my branch, in the quinn repository:

Pump test packets through sockets

The plan I’ve been working towards (in discussion with @Ralith) is more or less as follows:

• Keep the Quinn name, which is a little more unique
• Mostly keep the quicr code base, except
• Use rustls as the TLS backend

I now have the quicr-core tests working on my rustls-backed branch and have started work on converting the quicr public API layer.

quinn isn’t on crates.io because the required rustls features were not available on crates.io. This will take more time to sort out given that the current quinn/quicr codebase are based on draft-11, which assumes an older TLS 1.3 draft, and moving it to later drafts will require more changes in rustls (@Ralith has worked on that). We’ll see about putting it up on crates.io as soon as possible, of course, but that may still need a bunch more work.

[djc]

Quinn is now available on crates.io! This is a 0.1.0 version that won’t interoperate with any other version because of the aforementioned protocol disparities, but it can be used for experiments and for talking to itself.

The repo is still at https://github.com/djc/quinn for now.

[newpavlov]

Keep the Quinn name, which is a little more unique

I personally strongly prefer “boring” naming over “unique”. IMHO it will be a significantly nicer to have a single high-quality implementation under the quic name, which will be the first option which new users will try.

I think dyxushuai will be open to providing necessary access (or maybe even transfer ownership?) to quic-rs org if you are interested in it.

[djc]

I think dyxushuai will be open to providing necessary access (or maybe even transfer ownership?) to quic-rs org if you are interested in it.

I would like to explore gaining access to the quic-rs org.

We can bikeshed endlessly about names, so far I think we both like this one. There are plenty of other ways to make sure it will be easy to find on crates.io, and I think crates.io generally also does a good job of highlighting projects which are good first options for new users to try.

[JeffBurdges]

Use TLS 1.3 instead of the QUIC crypto part:

“The QUIC crypto protocol is destined to die. It will be replaced by TLS 1.3 in the future, but QUIC needed a crypto protocol before TLS 1.3 was even started.”

Also: https://groups.google.com/a/chromium.org/forum/#!topic/proto-quic/S5KkNjK4EUQ

[djc]

I’m not sure what you’re trying to convey with your post, but current IETF QUIC drafts do rely on TLS 1.3 cryptographic primitives. The materials you’re linking to are from 2016, and refer to Google’s earlier somewhat-proprietary iterations of the QUIC protocol.

[system]

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.