What other issues would be good for newcomers?

https://www.rfc-editor.org/rfc/rfc8441.html there is an rfc for websocket over http2, and I believe even one for ws over http3

I find the idea that http2 streams would supplant websockets kind of shocking. They are just different things.

The RFC for WS over http2 hasn't really proved popular.

Last I checked, nobody implemented it. Checked again, looks like there's partial support in browsers, but not much from servers and reverse proxies.

Also, I need to update my comment a bit. I had to doubble-check, and realized that browsers don't support streaming over fetch() yet (though there is standardization and experimental work)

But conceptually, WS and H2 steams are really similar, actually.

Websockets in general are not that great (who knew, stateful connections are annoying on mobile devices) but http streams have the same problem there

The request/response nature of HTTP is a bit of a red herring. For infinite streams, thnk of it like the WS handshakes. Once each sides exchange HEADER frames, they can send inifinte DATA frames and do with it what they want

I am aware

For mobile, HTTP/3's QUIC session identifiers would be a big advantage

AFAICT, they allow seamless resumption when you switch networks, like going from wifi to cell

I think if browsers supported a way to use H2/H3 streaming in Js, there wouldn't be any good WS use cases left (other than for legacy purposes). Websockets have slightly less packet overhead, but the lack of multiplexing is a big minus.

re: multiplexing; I am sure it can have significant benefit when loading a complex webpage with dozens (or likely 100s) of elements however, if I am simply serving API-style endpoints, I am not convinced there’s any significant real-world benefit (welcome to be proven wrong with examples - I tried looking but could not find anything)

HTTP/3 with QUIC is quite exciting though; the possibility of having all the benefits of WebSocket-style communication without worrying about stateful connections is potentially awesome (but I have not first-hand experience with it, so my excitement is purely theoretical at the moment 🙂 )

(and that can potentially benefit all kinds of servers: serving complex pages, simple pages, API servers, etc)

Yes, not all usage patterns benefit from multiplexing, but many will. For APIs, consider making a few requests near-simultaneously. If they overlap, you benefit from multiplexing. Browsers are definitely the poster child for benefitting from H2 multiplexing tho.

@U050KSS8M What in H3/QUIC are you most interested in? The QUIC connection ids, per-packet encryption, something else? The WebTransport protocol is the part most like WebSockets

For sure… I just imagine the WebSocket use case… (which I have experience with first hand); it’s effectively a light wrapper on top of TCP; TCP is the ultimate limiter here; Since WebSockets are full-duplex, there’s no blocking/waiting per-se.

In terms of QUIC, I am curious about whether it can truly do > allow seamless resumption when you switch networks like you said; I wonder if that’s a potential benefit in servers as well? Aka, can one completely forget about stateful re-connections? (again my knowledge here is limited to a few conference talks I’ve watched on the subject, so not first-hand…)

With WebSockets that’s definitely the pain point (statefulness, heartbeats, is my connection alive? etc) (but ultimately TCP is the limiting factor there I think)

WebTransport looks cool, yeah

I guess the question is, can WebTransport offer all those supposed benefits of seamless resumption, etc

(browsing through https://developer.mozilla.org/en-US/docs/Web/API/WebTransport …)

> Since WebSockets are full-duplex, there’s no blocking/waiting per-se > that’s definitely the pain point (statefulness, heartbeats, is my connection alive? etc) I mean, H2 streams are full-duplex, too, and a lot of its state mgmt is already handled for you. I think the request/response nature of HTTP really misleads people about what H2/3 can do. At the protocol level, treating the body like an infinite stream of bytes just like Websockets is easy. The only catch is browsers don't support HTTP responses like that very well (though there are still things like Server-Sent Events, which fit many simple use cases). But if you're a server, or using a non-browser client, H2/3 is fine for a lot of WS uses

That's where WebTransports seem to come in, though I haven't done much reading up on them yet. Still wrapping up H2 in Aleph.

I guess I am generally non-excited about HTTP/2 variants since they are all TCP based. Until we can go to UDP (with seamless reconnections), I am not sold on the benefits, at least for the use cases I’m involved in (which admittedly, does not involve serving facebook or CNN-sizes pages…)

(and I am guessing that’s where the majority of benefit lies)

> Aka, can one completely forget about stateful re-connections? It should definitely minimize reconns, especially across network switches. But eventually you'll get an error, or if the conn lives long enough, run out H2 stream identifiers.

> can WebTransport offer all those supposed benefits of seamless resumption I think resumption is built into the QUIC layer, so tentatively I'd expect the asnwer to be yes

Hmm yeah… I’ve experienced for example how flaky gRPC (HTTP/2) based connections/patterns can be (on at least 2 occasions over the years); Non-aleph based.

Yeah that would be the holy grail of connecting 🙂 Just connect and forget!

Would be nice.

(aka it’s all handled seamlessly at the protocol layer under the hood…)

Don't quote me on HTTP/3 resumption, there might still be required support at the application layer. I need to take a closer look

For sure.

What's your API use pattern?

FWIW, currently using Aleph with old-school HTTT/1.1 🙂

(serving JSON api)

Works great.

I’ve used Aleph with websockets and raw TCP over the years (also great, minus the re-connection hassle - but that’s not really Aleph’s fault/problem in general)

Because I'd think any time the same client makes multiple (near-)simultaneous requests, you'd benefit from H2's multiplexing. Pipelining never took off, so otherwise, you're forced to wait for responses to come in, and with Websockets, you have to write your own multiplexing, when otherwise you could cheaply fire up a new stream

If reconns are your thing, yeah, you need nothing short of QUIC.

(https://github.com/raspasov/neversleep/blob/master/src/neversleep_db/aleph_netty.clj)

Oh wow, gloss. I wrote a bunch of that a couple years ago for a speech-to-text project

“any time the same client makes multiple (near-)simultaneous requests” yeah the question is how many requests really does it get to see the benefits though it would have to be 10+ at the same time… even with HTTP/1.1 (and most of our current patterns are one request at the time, more or less, so truly not much benefit)

Yeah, with a light usage pattern, it won't help much. Obviously, the more simultaneous requests, the better H2 will be over H1

Need not be 10+ tho, even 2-3 should be faster. Nobody likes waiting 😄

Yeah, it’s more efficient, I understand;

Opening 1 socket vs many, etc;

Btw, I'd like to hear about your experience with gRPC issues; I've never used it

I hate to be a conspiracy theorist 😂 but I’ve encountered the opinion that RFC/et al HTTP standards have been sorta taken over by big companies where this kind of efficiency does make sense … but at a smaller scale it’s hard to quantify those benefits and the cost is often much more complexity in protocol, implementation, etc; I am not a “big companies = bad” type of person – I don’t have an ax to grind in this debase but I kinda soft agree with the above… it all depends on the use-case, and often the “best practices/newest thing” is not what one truly needs;

True, there's definitely a bunch of cargo-culting of what unicorns do. I guess for me, I view protocols as needing to support the widest range of use cases, since they're shared by everyone

re: gRPC basically re-connection troubles, and protobuf is its own weird thing (non-human readable; schema-out-of-band)

> a bunch of cargo-culting of what unicorns do 💯

Protobuf is goog's widely-used binary framing lib, right?

(not even unicorns, but like Facebook & Google)

Yeah…

what issues with reconnecting did you run into?

Well, at some point your stream or connection dies 🙂 (basically, all the issues you’d have with WebSockets)

re: protocol buffers and formats, old but great Rich Hickey talk (at timestamp) https://youtu.be/ROor6_NGIWU?t=736

widest range of use cases, since they’re shared by everyoneTotally understand your point, as a maintainer 👍

> Well, at some point your stream or connection dies :thinking_face: Was it around 1 billion calls? That's when I'd expect to run out of H2/3 stream ids, and need to make a new conn

If not, well, network errors are inevitable

Was it around 1 billion calls?I am not exactly sure… I doubt it… But that’s good food for thought…

Good thing RAM/CPU isn't as flaky as network 😂

> If not, well, network errors are inevitable Right.. that’s why I have so much hope about QUIC and WebTransport if that can be automagically abstracted away 😁

🤞

> Good thing RAM/CPU isn’t as flaky as network Haha, oh yeah…

I'm going to have to bow out of this one. It is clearly a much more complicated issue that I first assumed. 😲

@jwhitlark Thanks for taking a look, though. Think I should remove the "good first issue" tag? In my head, I thought it wouldn't require much code-writing, but I guess it involves a TON of code-reading.