webtransport VS ggpo

WebTransport is now enabled by default and will be going to release with 114. As the original Explainer notes, it enables multiple use-cases that are hard or impossible to handle without it, especially for Gaming and live streaming. It covers cases that are problematic for alternative mechanisms, such as WebSockets. Built on top of HTTP3 (HTTP2 support will be coming later). The current implementation in Firefox is passing 505 out of 565 Web-Platform Tests.

WebTransport is still an emerging technology. As of November 2022, WebTransport is a draft specification with W3C, and there’s always a chance that aspects related to how it works may change.

Sort of. The browser will re-use the connection if you have a bunch of resources in the HTML. When rendering it sees that it needs 2 images and 3 javascript files from the same server, so it pipelines all of those. But for requests initiated from javascript, you're going to get a new connection for each one unless you're using a library that implements the long-polling hack. SocketIO can use the long-polling hack as a fallback if websockets is not supported. HTTP/2 (formerly SPDY) gets part of the way to replacing websockets, but it's not a synchronous link. Only the client can send messages to the server and the server can only respond to those message (with websockets, either side can send messages once the connection is open). FWIW, less than 50% of websites use HTTP/2. HTTP/3's webtransport looks like it could replace websockets, but it also looks like it'll live along side websockets.

If it's streaming data like dashboard statistics the new WebTransport API might be a much better base: https://github.com/w3c/webtransport/blob/main/explainer.md

Are you guys looking into the Web Transport protocol for the future? Right now you have to tunnel the websocket connections over http2 and it will probably be the same for http3 afaik.

I know there is this work in progress (https://w3c.github.io/webtransport/) and websockets are probably fine for a long time but sooner or later (unless there is an update to websockets) it will probably be faster to just do normal http requests and listen on server sent events.

What are your thoughts for Liveview for the future? Will it forever stay on websockets or would you be open to change the underlying technology if / when new stuff becomes available?

The W3C draft is here: https://github.com/w3c/webtransport

It's taken nearly 10 years for QUIC to be refined and adopted in the wild and we're basically there. There's even a new browser API in the works called WebTransport.

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. I am extremely excited about it and its potential for real-time browser-based multiplayer games (which I'm working on).

https://github.com/w3c/webtransport

As mentioned in the top comment, rollback and client side prediction is key. One of the more robust and popular libraries that do this specifically for fighting games is GGPO. When it was opened sourced a few years ago it was a fairly big deal as games that used it felt great. Larger studios have their own libraries but the concept is the same. Its worth a look through if you want to implement something on your own.

I just did a quick Google so I don't know the exact details, but I think Max said Idol Shodown is running GGPO which, as far as I can tell, is open source.

will reply here also in case anyone else wanted an answer. You could use the original C++ library with C++ or any language that interops with C++ (e.g. C#), so that's there for ya if you need

Sure thing bud. I guess we'll just keep pretending like Code Mystics, the same people that did the KI netcode, haven't partnered with SNK because SNK realized their shit sucks and they needed external assistance. We'll pretend like the source code for GGPO is hidden away in the recesses of Tony Cannon's mind or that it isn't open and free for anyone to use or that it doesn't have Japanese documentation. We'll pretend like MikeZ didn't implement a version of GGPO in Skullgirls in 2012.

GGPO is a common implementation and it's all open source if anyone wants to get into the nitty-gritty: https://github.com/pond3r/ggpo

Backroll-rs is a brand new networking library based on GGPO dedicated to peer-to-peer Rollback Netcode, for use in fighting games, platform fighters, and other games with less than 8 players that require low latency. We are looking for programmers familiar with Rust to help finish this project. We are 80% of the way completed with this project, but we need more unit tests and debugging to fully finish it.

This doesn't work in the comparison to shooters. Shooters operate through a server, while fighting games are peer-to-peer. They only require a server for matchmaking purposes. Doing the peer-to-peer part actually puts fighting game devs at an advantage compared to other genres, as there's libraries and documentation for those libraries to either plug and play a rollback solution or build one buy looking at existing source code complete with solid documentation.

GGPO doesn't really solve the biggest problem with SFV's netcode, which is client timesync. It does have code in there to handle it by slowing down the client that's ahead and allowing the client that's behind to catch up, but that doesn't fix the fact that one client consistently gets ahead in the first place, and also means the faster client will see more stuttering or slowdown.