Mastodawn

Who’s using #webtransport in production, in any language?

I’m designing a server api for the trillium ( #rust / #rustlang ) protocol implementation and can’t figure out what sort of higher level abstraction people would want in addition to the protocol-defined interfaces like inbound/outbound x bidi/uni/datagram. Would you want a socket-io-like interface?

Show thread

Josh Triplett Mar 10

I'm hoping to switch to WebTransport, and have been looking at the Rust wtransport crate and at raw QUIC. Roughly speaking, I'd love for it to look like a thing from which I can spawn channels, in either direction. The biggest reason I want to use it is "WebSocket, but the server can create new connections to the client without a complicated painful callback-like protocol".

Show thread

jbr

@josh Well I've got it working in trillium over h3 now, it's just very low level (AsyncRead/AsyncWrite streams and datagrams). Out of curiosity, what's the motivation for WebTransport instead of QUIC? AFAICT the primary advantage of WebTransport is browser use and/or http-based auth that gates the CONNECT and establishes state?

Show thread

jbr Mar 10

@josh In particular, I'm trying to figure out if anyone actually uses the notion of multiple WT "sessions" over a single QUIC Connection. The spec supports it, but no browser client I've tested coalesces QUIC connections over WT sessions, so it's always session 0. I'm doing a bunch of awkward demuxing in order to surface just the streams and datagrams associated with a given CONNECT, but I can't actually exercise that code

Show thread

Josh Triplett Mar 10

As far as I can tell, maintaining *one* QUIC connection to any given server seems like a useful QUIC methodology, even if *browsers* aren't doing that. You pay connection establishment overhead only once, it has a full view of congestion control, less state, theoretically cross-session compression...

Show thread

jbr Mar 10

@josh Yeah that's what I had imagined. Not sure if other clients support that though. I haven't built out a client yet, although it wouldn't be a lot of work to do so once trillium-client speaks h3 (it's really just an embarrassingly thin layer on top of QUIC; one or two varints at the start of each stream and then hand it off to user code)

Show thread

Josh Triplett Mar 10

The rest of the API is over HTTP already, and does need authentication, and I'd like to avoid recreating concepts like HTTP headers and paths. Not much other than that; it's possible that low-level QUIC may make sense.

Show thread

Josh Triplett Mar 10

AsyncRead/AsyncWrite streams sound like a delightful API, honestly.

Show thread

jbr Mar 10

@josh https://github.com/trillium-rs/trillium/blob/webtransport/webtransport/examples/webtransport.rs is the current sketch, and by sketch I mean fully functional example

trillium/webtransport/examples/webtransport.rs at webtransport · trillium-rs/trillium

Trillium is a composable toolkit for building internet applications with async rust - trillium-rs/trillium

GitHub