Live data from Hacker News

Direct Sockets API in Chrome 131

chromestatus.com

161–170 of 171 posts

Re: Direct Sockets API in Chrome 131

#161

I think a lot of people don't realize it's possible to use UDP in browsers today with WebRTC DataChannel. I have a demo of multiplayer Quake III using peer-to-peer UDP here: https://thelongestyard.link/ Direct sockets will have their uses for compatibility with existing applications, but it's possible to do almost any kind of networking you want on the web if you control both sides of the connection.

Not really peer to peer though, is it? The q3 server is just running in the browser session that shares a URL with everyone else?

Yes, it is. The first peer to visit a multiplayer URL hosts the Quake 3 server in their browser. Subsequent visitors to the same multiplayer URL send UDP traffic directly to that peer. The packets travel directly between peers, not bouncing off any third server (after connection establishment). If your clients are on the same LAN, your UDP traffic will be entirely local, not going to the Internet at all (assuming your browser's WebRTC implementation provides the right ICE candidates).

It won't work completely offline unfortunately, as the server is required for the connection establishment step in WebRTC. A peer-to-peer protocol for connection establishment on offline LANs would be awesome, but understandably low priority for browsers. The feature set of WebRTC is basically "whatever Google Meet needs" and then maybe a couple other things if you're lucky.

Re: Direct Sockets API in Chrome 131

#162

Earlier quoted context omitted.

We got it in unreliable/unordered and it still barely moves the needle on network perf over websockets from what we see in north america connecting to another server in north america

I wouldn't expect a big improvement in average performance but the long tail of high latency cases should be improved by avoiding head-of-line blocking. Also peer-to-peer should be an improvement over client-server-client in some situations. Not for battle royale though I guess. Edit: Very cool game! I love instant loading web games and yours seems very polished and fun to play. Has the web version been profitable, o…

Thanks! The web versions of both of our mobile/web games do about the same as the IAP versions. We dont have ads in the mobile versions, so the ad revenue is reasonble. We're actually leaning more into smaller web games as a result of that. Profit on this game specifically I think it deserves better. I think Goober Dash is a great game, but it's not crushing it like I'd hoped.

Re: Direct Sockets API in Chrome 131

#163

Earlier quoted context omitted.

Not really peer to peer though, is it? The q3 server is just running in the browser session that shares a URL with everyone else?

Yes, it is. The first peer to visit a multiplayer URL hosts the Quake 3 server in their browser. Subsequent visitors to the same multiplayer URL send UDP traffic directly to that peer. The packets travel directly between peers, not bouncing off any third server (after connection establishment). If your clients are on the same LAN, your UDP traffic will be entirely local, not going to the Internet at all (assuming you…

This is neat. A little perverse, but neat.

Re: Direct Sockets API in Chrome 131

#164
post #66

Earlier quoted context omitted.

You can also use WebTransport with streams for tcp and datagramms for udp https://developer.mozilla.org/en-US/docs/Web/API/WebTranspor...

Not peer to peer though presumably?

This a very early draft I'm following: https://wicg.github.io/local-peer-to-peer/

Re: Direct Sockets API in Chrome 131

#165

I think a lot of people don't realize it's possible to use UDP in browsers today with WebRTC DataChannel. I have a demo of multiplayer Quake III using peer-to-peer UDP here: https://thelongestyard.link/ Direct sockets will have their uses for compatibility with existing applications, but it's possible to do almost any kind of networking you want on the web if you control both sides of the connection.

Doesn't WebRTC still require an secure server somewhere?

Direct sockets will be amazing for IoT, because it will let you talk directly to devices.

With service workers you can make stuff that works 100% offline other than the initial setup.

Assuming anyone uses it and we don't just all forget it exists, because FF and Safari probably won't support it.

Re: Direct Sockets API in Chrome 131

#166

Earlier quoted context omitted.

> Direct sockets will have their uses for compatibility with existing applications... In fact runtimes like Node, Deno, Cloudflare Workers, Fastly Compute, Bun et al run JS on servers, and will benefit from standardization of such features. [WICG] aims to provide a space for JavaScript runtimes to collaborate on API interoperability. We focus on documenting and improving interoperability of web platform APIs across r…

This slowly alters the essence of The Internet, due to the permissionless nature of running any self-organising system like Bittorrent and Bitcoin. This is NOT in Android, just isolated Web Apps at desktops at this stage[0]. The "direct socket access" creep moves forward again. First, IoT without any security standards. Now Web Apps. With direct socket access to TCP/UDP you can build anything! You loose the constrain…

What if someone finds your IP address and sends you a bunch of crap? It would be very easy to use someone's entire monthly data allowance.

Plus, it only works if you can afford and have access to cell service, and in those cases you or have access to normal Internet stuff.

Unless cell towers are able to route between two phones when their fiber backend goes down. That would make this actually pretty useful in emergencies if a rower could work like a ham repeater, assuming it wasn't too clogged with traffic to have a chance.

Re: Direct Sockets API in Chrome 131

#167

Earlier quoted context omitted.

Not peer to peer though presumably?

There was some traction & interest in https://github.com/w3c/p2p-webtransport but haven't seen any activity in a while now. I'm pretty cocksure certain a whole industry of p2p enthusiasts would spring up building cool new protocols and systems on the web in rapid time if this ever showed up.

Perfect timing with realtime AGI happening. Need lots of focus on realtime streaming protocols

Re: Direct Sockets API in Chrome 131

#168
post #46

Earlier quoted context omitted.

Unfortunately this is the future. Handing the world wide webs future to Google was a mistake, and the only remedy is likely to come from an (unlikely) antitrust breakup or divestment.

> Handing the world wide webs future to Google Nobody handed anything to anyone. They go with the flow. The flow is driven by people who use their products. The browser is how Google delivers their products so it’s kinda difficult to blame them for trying to push the envelope but there are alternatives to Chrome.

And some developers shipping Chrome alongside their apps, instead of learning proper Web development.

Re: Direct Sockets API in Chrome 131

#169
post #95

Earlier quoted context omitted.

Which part of "is not a w3c standard and not any standards track" do you not understand? Do you understand that for something to become a standard, it needs two independent implementations? And a consensus on API? Do you understand that "not on any standards track" means it's Chrome and only Chrome pushing this? That Firefox isn't interested in this either? Do you understand that blaming Apple for everything is borde…

What part of "cry me a river" you didn't understand? Don't go crazy because at least one of the browsers propose things that move the web forward. Geez, you should take a break from the internet. So many "?"

A generation lost in Internet Explorer....
Post reply on HN