Hacker News Reader

Comment by rewq4321 | Hacker News Reader

> Timer precision has been reduced to around 1ms

> threading is also disabled or behind HTTP response headers post-Spectre

It seems like you've written a long-winded complaint that you have to add a http header (like this[0]) to your server's response? Though it's true that the Spectre stuff broke everything for a little while there (and there are still ergonomics-related teething problems with headers that are being worked on).

> Games need UDP style non-guaranteed networking, but we only get this as a tiny part of WebRTC (DataChannels).

WebRTC DataChannels work fine though? Does it matter that it's a small part of the whole WebRTC spec or that server-client use is a bit of a hack? Either way, WebTransport hits origin trial in Chrome in about a week, and it's specifically designed for UDP-like client-server communication, so the WebRTC approach can be swapped out once that is stable.

[0]: https://web.dev/coop-coep/

View on HN

Ruffle developer here. A good chunk of our incoming issue volume used to be "how do we configure the WASM mime type" disguised in various "omg it doesn't work, what does this error mean" type issues. This is because we were using WASM's instantiateStreaming function to load our module, which requires valid HTTP headers on the WASM file which most web servers weren't configured to produce. Adding a fallback to a slower WASM load approach that doesn't require a header made all those complaints go away.

In our experience the average webmaster does not know how to configure proper HTTP headers and should not be expected to for a basic web library. So any web API that will not work with the standard web server configurations of Apache, nginx, or IIS is a non-starter for us. (Not to mention that the site isolation headers have non-trivial implications for sites that use iframes...)

That's a fair point. I hope you're involved in the spec discussions around these topics! There's definitely room for improvement in terms of ease of use.

I noticed this update on the https://web.dev/coop-coep/ article recently:

> We've been exploring ways to deploy Cross-Origin-Resource-Policy at scale, as cross-origin isolation requires all subresources to explicitly opt-in. And we have come up with the idea of going in the opposite direction: a new COEP "credentialless" mode that allows loading resources without the CORP header by stripping all their credentials. We are figuring out the details of how it should work, but we hope this will lighten your burden of making sure the subresources are sending the Cross-Origin-Resource-Policy header.

> It seems like you've written a long-winded complaint that you have to add a http header (like this[0]) to your server's response?

So how does this work on Github Pages or other hosting solutions where the user has no control over the web server configuration?

> WebTransport hits origin trial in Chrome in about a week

How long until this shows up in Firefox, and will Safari ever support this before it's deprecated in Chrome again because another better solution shows up?

> how does this work on Github Pages

Spectre called for some drastic measures, and it'll be up to Github/Netlify to decide how they react. Developers who want simple hosting solutions for their little projects will host elsewhere (e.g. replit.com, glitch.com) if they need to. This isn't exactly a massive obstacle if you've set out to build a complex game in the browser. It's just a couple of headers...

>How long until this shows up in Firefox

WebRTC data channels work fine in the mean time. Have you seen games like krunker.io and dotbigbang.com et al? It's perfectly possible to create real-time games in the browser using WebRTC.

And we’re using WebSockets right now for the networking in dot big bang! Although we’ve talked a lot about moving to WebRTC we’ve not gone as far as doing it yet.

More generally things get a lot simpler if you’re “web first”. It’s a lot easier to just be pragmatic about it and build when you’re not straight jacketed by existing designs reliant on common low level OS APIs.

> This isn't exactly a massive obstacle if you've set out to build a complex game in the browser.

It is an obstacle (at least a massive annoyance) for library authors (like this: https://github.com/floooh/sokol). Those libraries can be used for extremely simple and small WASM snippets embedded in blog posts (like here: https://floooh.github.io/2019/01/05/wasm-embedding.html), or in "proper" games hosted through "proper" hosting services which allow to set the response headers.

Right now the choice is to either support WASM threading, but tell library users that the library will most likely not work on the hosting solution of their choice, or not support WASM threading and work everywhere. At least to me it's clear that "works everywhere" is better than "it's complicated", so I'll ignore WASM threading until the problem is solved somehow (either most hosting services turn on those response headers, or there's another way to enable threading without requiring control over the web server configuration).

> It is an obstacle (at least a massive annoyance) for library authors

Yeah that's a completely fair point. Ruffle dev makes a similar argument up-thread: https://news.ycombinator.com/item?id=27199260

> Netlify

Netlify already allows full control over headers even on their subdomain, including COOP/COEP.

Oh, good to know!

WebRTC is designed for client to client architecture. We want to use it in a dedicated server architecture. WebRTC is not designed to integrate into kubernetes. Ultimately, this has pushed us to stay on websockets and try to handle TCP congestion. We have theorized a network architecture that could use webrtc in our cluster, but it involves routing data out to a TURN/STUN server and back in, which would cost a lot more due to paying double for egress/ingress.

Overall, WebRTC is a poorly designed protocol which will be quickly obsoleted.

What does WebRTC--or any protocol for that matter--have to do with your container solution? When I develop a protocol now, do I have to "design it to integrate into kubernetes"?! FWIW, WebRTC works great for client-to-server deployment, as using it like that means you don't have to worry at all about the oft-cited peer-to-peer NAT incompatibility issues.

The issues that we ran into were related to the port range that WebRTC attempts to use.

If I understand it correctly, WebRTC requires you to open a range of thousands of ports and kubernetes load balancers are designed to forward individual ports to individual services.

https://github.com/pion/webrtc/issues/639

https://github.com/pion/webrtc/wiki/Big-Ideas#single-port-mo...

Reply on news.ycombinator.com