WebTransport support

[dsidirop]

(clarification: I'm referring to nats-client for C)

I'm aware of this thread for WebSocket:

#371

The issue got closed stating that adding WebSocket support was controversial back then.

Things have moved on and now we have WebTransport which is posed to appear in NATS in 2022-Q2 according to NATS' official roadmap. I believe the time will soon come to introduce support for WebTransport in nats-client-libs like this one due to the tremendous benefits WebTransport brings (congestion control etc) to "die-hard" C-fueled edge-nodes like the nodes we have in the projects I'm working on. Is this on your radar and if so what's the timeline you are planning on adopting for introducing WebTransport support?

From a corporate perspective it's also easier to deal with WebTransport firewall rules rather than the :4222 port of "vanilla NATS" connections - I'm aware that in issue #371 there are diverging opinions on this but I respectfully maintain that hassle-free zero-configuration in a corporate environment is indeed a considerable benefit.

[kozlovic]

We did implement Websocket in the Go client (and have nats.ws repo too). We will probably have to port websocket to all supported Synadia client libraries, it's just that it takes time and we are all very busy with even more pressing issues :-)

But that's something I will get to at one point, but unfortunately do not have any ETA. The good thing is that since I implemented in the Go client and C client is close to it, I already went to pain-points on what needs to be refactored in the library to be able to plug websocket, but it will still be a lot of work.

I will keep this issue opened and have marked it as Enhancement.

[dsidirop]

I take it for granted that by WebSocket you also imply 'WebTransport as well later on when the time comes' but I'd be happy to stand corrected on this in case I've missed something obvious.

Off-topic question since you mentioned websocket: Would you be kind enough to clarify for the case of WebSocket if the support will come along with WebSocket-Compression ('permessage-deflate') or whether it will be barebone support without any built-in compression-support ('permessage-deflate')?

(I'm not asking about WebTransport built-in compression at all, because I know that WebTransport by design, unlike WebSocket, won't support built-in compression as a matter of philosophy)

All in all, thanks for running point on this - all the efforts that go into NATS are deeply appreciated!

[kozlovic]

@dsidirop I noticed that you mentioned something about congestion control and should have picked on that. No, what we have currently in NATS Server (and some of the clients) is simply websocket framing. Nothing more.
So I guess I should close this one and instead have a WebSocket ER, not WebTransport, so that people don't wait on something that is not coming (at least in near future).

[dsidirop]

@dsidirop I noticed that you mentioned something about congestion control and should have picked on that. No, what we have currently in NATS Server (and some if the clients) is simply websocket framing. Nothing more. So I guess I should close this one and instead have a WebSocket ER, not WebTransport, so that people don't wait on something that is not coming (at least in near future).

According to the link below WebTransport support ("improved networking QUIC support" I believe refers to WebTransport based on my understanding) in NATS server is scheduled to land on 2022 Q3 which is in 6 to 7 months at the latest from now - that's kinda close and it looks very promising for us:

https://github.com/nats-io/nats-general

[kozlovic]

@dsidirop We probably need to update the roadmap, but what is there is QUIC (not WebTransport, which is different if I am not mistaken). Things have been moving quite a lot and we needed to shift some of the priorities, apologies for that. I am cc'ing @ColinSullivan1 and @derekcollison here to let them know and maybe contact you directly.

[derekcollison]

Also @tbeets as well.

[dsidirop]

@kozlovic

QUIC (not WebTransport, which is different if I am not mistaken).

https://www.w3.org/TR/webtransport/

"A WebTransport session is a session of WebTransport over HTTP/3"

In my mind HTTP/3 and QUIC and interchangeable in the context of NATS roadmap - even though strictly speaking HTTP/3 is the mapping of HTTP which uses IETF QUIC as a transport.

From the discussions I've seen floating around in NATS forums I have the confident impression that the intention is to explicitly support WebTransport (not just vague 'QUIC') with edge-nodes and this is what the roadmap is refering to when it mentions QUIC - I can't fathom what else it can possibly be pointing towards but feel free to correct me if I'm missing something.