webtransport

Someone correct me if I'm wrong, but I think p2p-webtransport was superseded by "webtransport" (https://github.com/w3c/webtransport). Supposedly, the webtransport design should be flexible enough to support p2p even though focus is the traditional server<>client.

> No. Thanks for your insight. It seems you need to urgently reach out to the people working on WebTransport. You seem to know better and their documentation contradicts and refutes your assertion. https://github.com/w3c/webtransport/blob/main/explainer.md

Yeah, it's part of the problem, but that would normally only give you ~60 - 100 ms lag (at least if you're on a decent connection, close-ish to the server). But we're experiencing another bug where WebTransport doesn't get a chance to send/receive data when the framerate is < 60fps (because the thread is starved), which makes it much worse than that. We're aware of it and working on it. This is the core issue: https://github.com/w3c/webtransport/issues/543

Yes, I'm quite sure this works this way. I was looking into a few implementations and the specs: https://datatracker.ietf.org/doc/html/draft-ietf-webtrans-ov... https://www.w3.org/TR/webtransport/ https://github.com/w3c/webtransport https://github.com/w3c/webtransport/blob/main/explainer.md https://github.com/aiortc/aioquic/blob/main/examples/http3_s... WebTransport just landed in Firefox release versions and is available since some time in Chromium so it's indeed ready for hacking! :-D

If it's streaming data like dashboard statistics then going forward the new WebTransport API might be a much better base: https://github.com/w3c/webtransport/blob/main/explainer.md At this instant it's hot off the assembly line though having just shipped in Chrome 97, Firefox is still working on it.

Turns out though, they're coming up with a way to support basically any TCP based protocol via WebTransport: https://github.com/w3c/webtransport/blob/main/explainer.md

What do you find hard about setting up a WebRTC server? I hear from users they are able to spin up a Pion DataChannel server in 5 mins (including installing Go) WebTransport isn’t going to be here soon though, I would be cautious in investing. Stuff like Congestion Control is still a big unknown [0] and we don’t have Datagrams everywhere. [0] https://github.com/w3c/webtransport/issues/168 [1] https://github.com/quicwg/datagram

tl;dr using WebRTC just for realtime client<->server data sucks, but WebTransport[1] is coming soon to serve that exact usecase with an easy API WebRTC has data channels, which are currently the only way to achieve unreliable and unordered real-time communication (UDP-style) between the browser and other browsers or a server. This is pretty essential for any networked application where latency is critical, like voice and video and fast-paced multiplayer games. As other commenters have noted, it's a royal pain in the ass to set up WebRTC if all you want is UDP-style communication between a server and browser, since you need to wrangle half a dozen other protocols in the process. However! A new API, WebTransport[1], is actively being developed that will offer a WebSockets-like (read: super simple to set up) API for UDP-style communication.

Websocket is definitely a superior abstraction, but the main problem with it is that a lot of corporate firewalls/network proxies don't know how to handle the upgrade request and drop the connection. We took a dependency on Websockets a few years back and while everything worked fine in the US, a lot of our customers in Asia/Europe simply couldn't access some of the core functionality of our site. The Server-sent-events/EventSource API _seems_ like a better fit for GraphQL subscriptions because it's one-directional traffic anyway, but in addition to the issues you mentioned above, you'll also run into the 2000-character limit most browsers have for URLs [1]. The browser's EventSource constructor does not let you specify request bodies so you're forced to put everything in the URL, which is _not_ suited for the graphql queries which tend t

Folks who are interested in the WebTransport API may find it easier to read the "explainer" document. https://github.com/wicg/web-transport/blob/master/explainer.... It addresses a number of the top comments here, e.g. why not just use WebRTC data channels: "While WebRTC data channel has been used for client/server communications (e.g. for cloud gaming applications), this requires that the server endpoint implement several protocols uncommonly found on servers (ICE, DTLS, and SCTP) and that the application use a complex API (RTCPeerConnection) designed for a very different use case."

Hi there, I'm from Chrome, someone on my team pointed me at this thread. My team supports casting features in Chrome. This is a fantastic project and it's great to see energy around this. I get the frustration around the inability to make devices work together for casting. In the standards community, we have been working with other companies and researchers on a protocol [1] that provides the groundwork for interoperability in media streaming and media control on the Web between browsers/apps and devices. We are developing an open source implementation and plan to see it in future products. There's a lot of other work going on in the Web standards community as well, that in the near future will allow Web apps to create their own media codec pipelines and streaming protocols customized to their needs [2] [3]. [1] https://w3c.github.io

There's a proposal that would let video encoding be accelerated without going through the entire WebRTC pipeline: https://github.com/WICG/web-codecs/blob/master/explainer.md Somewhat tangentially related, for cases when P2P connectivity is not needed, there's also a proposal that lets you send data unreliably, but in a client-server setting: https://github.com/WICG/web-transport/blob/master/explainer.... Both are currently being actively prototyped in Chromium (full disclosure: I've been working on the latter).