Hacker News Reader

Comment by modeless | Hacker News Reader

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.

View on HN

> 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 runtimes (especially non-browser ones).

https://wintercg.org/

Can you explain further... how does this improve upon websockets and socketIO for node?

Without a middleman you can only use web socket to connect to an http server.

So, for instance if I want to connect to an mqtt server from a webpage I have to use a server that supports websocket endpoint. With direct sockets I could connect to any server using any protocol

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 constraint of JS servers, costly WebRTC server hosting, and lack of listen sockets feature in WebRTC DataChannel.

<self promotion>NAT puncturing is already solved in our lab, even for mobile 4G/5G. This might bring back the cyberpunk dreams of Peer2Peer... In our lab we bought 40+ SIM cards for the big EU 4G/5G networks and got the carrier-grade NAT puncturing working[1]. Demo blends 4G/5G puncturing, TikTok-style streaming, and Bittorrent content backend. Reading the docs, these "isolated" Web Apps can even do SMTP STARTTLS, IMAP STARTTLS and POP STLS. wow!

[0] https://github.com/WICG/direct-sockets/blob/main/docs/explai... [1] https://repository.tudelft.nl/record/uuid:cf27f6d4-ca0b-4e20...

Hello, I wanted to say I've been working on a peer-to-peer library and I'm very much interested in your work on symmetric NAT punching (which as far as I know is novel.) Your work is exactly what I was looking for. Good job on the research. It will have far-reaching applications. I'd be interesting in implementing your algorithms depending on the difficulty some time. Are they patented or is this something anyone can use?

Here's a link to an over-view for my system: https://p2pd.readthedocs.io/en/latest/p2p/connect.html

My system can't handle symmetric --- symmetric. But could in theory handle other types of NATs ---- symmetric. Depending on the exact NAT types and delta types.

I read OP's thesis (which focuses on CGNAT), and one of the techniques discussed therein is similar to Tailscale's: https://tailscale.com/blog/how-nat-traversal-works

  ...with the help of the birthday paradox. Rather than open 1 port on the hard side and have the easy side try 65,535 possibilities, let’s open, say, 256 ports on the hard side (by having 256 sockets sending to the easy side's ip:port), and have the easy side probe target ports at random.

this comment section has been the most useful and interesting thing I've seen for my own work in a very long time. And completely random, too. Really not bad. To me this represents the godly nature of this website. Where you have extremely well informed people posting high quality technical comments that would be hard to find anywhere else on the web. +100 to all contributors.

indeed, Tailscale was the first to realise this.

We added specific 4G and 5G mobile features. these carrier-grade boxes have often non-random port allocations. "By relying on provider-aware IPv4 range allocations, provider-aware port prediction heuristics, high bandwidth probing, and the birthday paradox we can successfully bypass even symmetric NATs."

> By leveraging provider-aware (Vodafone,Orange,Telia, etc.) NAT puncturing strategies we create direct UDP-based phone-to-phone connectivity.

> We utilise parallelism by opening at least 500 Internet datagram sockets on two devices. By relying on provider-aware IPv4 range allocations, provider-aware port prediction heuristics, high bandwidth probing, and the birthday paradox we can successfully bypass even symmetric NATs.

U mad. Love it!

I don’t understand the topic deeply. Is this futureproof, or likely to be shutdown in a cat and mouse game if it gets widespread, like it needs to for a social network?

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.

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?

Yes and not in Safari yet either. Someday I hope that all parts of WebRTC can be replaced with smaller and better APIs like this. But for now we're stuck with WebRTC.

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

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

WebRTC depends on some message transport (using http) existing first between peers before the data channel can be established . That's far from equivalent capability to direct sockets.

Not only that, but DTLS is mandated for any UDP connections.

Is that a problem? Again, I'm talking about the scenario where you control both sides of the connection, not where you're trying to use UDP to communicate with a third party service.

I think all three comments including mine are essentially saying the same but in different viewpoints.

Yes, you do need a connection establishment server, but in most cases traffic can flow directly between peers after connection establishment. The reality of the modern internet is even with native sockets many if not most peers will not be able to establish a direct peer-to-peer connection without the involvement of a connection establishment server anyway due to firewalls, NAT, etc. So it's not as big of a downgrade as you might think.

That changed (ahm.. will change) with ipv6. I was surprised to see that I can reach residential ipv6 lan hosts directly from the server. No firewalls, no nat. This remains true even with abusive isps that only give out /64 blocks.

That said, I agree that peer to peer will never be seemless thanks mostly to said abusive isps.

I sure hope not, this will bring in a new era for internet worms.

If some ISPs are not currently firewalling all incoming IPv6 connections, it's a major security risk. I hope some security researcher raises boise about that soon, and the firewalls will go closed by default.

it kinda of already begun

Has there been a big ipv6 worm? I thought that the defense against worms was that scanning the address space was impractical due to the large size.

i don't think they scan the entire space. but even before that there were ones abusing bonjour/upnp which is what chrome will bring back with this feature.

My home router seems to have a stateful firewall and so does my cellphone in tethering mode - I don't know whether that one's implemented on the phone (under my control) or the network.

Firewalling goes back in the control of the user in most cases - the other day we on IRC told someone how to unblock port 80 on their home router.

IPv6 isn't going to happen. Most people's needs are met by NAT for clients and SNI routing for servers. We ran out of IPv4 addresses years ago. If it was actually a problem it would have happened then. It makes me said for the p2p internet but it's true.

> If it was actually a problem

It became a problem precisely the moment AWS starting charging for ipv4 addresses.

"IPv4 will cost our company X dollars in 2026, supporting IPv6 by 2026 will cost Y dollars, a Z% saving"

There's now a tangible motivator for various corporate systems to at least support ipv6 everywhere - which was the real ipv6 impediment.

Residential ISP appear to be very capable of moving to v6, there are lots of examples of that happening in their backends, and they've demonstrated already that they're plenty capable of giving end users boxes the just so happen to do ipv6.

Yes and setting up a single IPv4 VPS as load balancer with SNI routing in front of IPv6-only instances solves that.

Most people are probably using ELB anyway

What do you mean not going to happen? It's already happening. It's about 45% of internet packets.

Not happening for 55%.

Try to connect to github.com over IPv6.

It doesn't work now so it's never going to work?

GitHub might work someday. Wide enough adoption that you can host a service without an IPv4 address will never happen.

Honestly, it could be a feature rather than a bug…

If it doesn't work for a website as large as technically forward as GitHub in 2024, the odds are not looking good.

Yes, that's one of the rare exceptions of a company trying to obsolete itself. It's actually one reason a bunch of people are moving away from Github.

The sun is about 45% of the way through its life.

"We are introducing a new charge for public IPv4 addresses. Effective February 1, 2024 there will be a charge of $0.005 per IP per hour for all public IPv4 addresses"

https://aws.amazon.com/blogs/aws/new-aws-public-ipv4-address...

Yes and setting up a single IPv4 VPS as load balancer with SNI routing in front of IPv6-only instances solves that.

Most people are probably using ELB anyway.

> I was surprised to see that I can reach residential ipv6 lan hosts directly from the server. No firewalls, no nat

No NAT, sure, that's great. But no firewalls? That's not great. Lots of misconfigured networks waiting for the right malware to come by...

This looks to use Web Sockets, not WebRTC, right? I don't see any RTCPeerConnection, and the peerServer variable is unused.

I ask because I've spent multiple days trying to get a viable non-local WebRTC connection going with no luck.

view-source:https://thelongestyard.link/q3a-demo/?server=Seveja

Web sockets are only used for WebRTC connection establishment. The code that creates the RTCPeerConnection is part of the Emscripten-generated JavaScript bundle. I'm using a library called HumbleNet to emulate Berkeley sockets over WebRTC.

The code is here: https://github.com/jdarpinian/ioq3 and here: https://github.com/jdarpinian/HumbleNet. For example, here is the file where the RTCPeerConnection is created: https://github.com/jdarpinian/HumbleNet/blob/master/src/humb...

I feel your pain. WebRTC is extremely difficult to use.

Check out Trystero[1], it makes WebRTC super simple to develop with.

[1] https://github.com/dmotz/trystero

There's also this new WebTransport thingie based on HTTP/3:

https://developer.mozilla.org/en-US/docs/Web/API/WebTranspor...

I haven't tinkered with it yet though.

Yeah, not in Safari yet and no peer-to-peer support. Maybe someday though! It will be great if all of WebRTC's features can be replaced by better, smaller-scoped APIs like this.

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.

Longest Yard is my favorite Q3 map, but for some reason I cannot use my mouse (?) in your version of the Quake 3 demo.

Interesting, what browser and OS?

Brave browser (Chromium via Flatpak) on the Steam Deck (Arch Linux) in Desktop mode with bluetooth connected mouse/keyboard.

Same browser on win10. Mouse works after you click in the window and it goes full screen. However, it hangs after a few seconds of game play.

Stopped hanging... then input locks up somehow.

Switched to chrome on win10, same issue: input locks up after a bit.

Yeah that issue I have seen, but unfortunately haven't been able to debug yet as it isn't very reproducible and usually stops happening under a debugger.

Even with the problems, just the few seconds of playing before the crash+input hang got me hooked. So, off to GOG to get q3a for $15. Also, quake3e with all the quality, widescreen, aspect ratio and FPS tweaks... chatgpt 4o seems to know everything there is to know about quake3e, for some reason.

Talk about getting nerd sniped.

Hmm, I bet the problem is my code expects touch events instead of mouse events when a touchscreen is present. Unfortunately I don't have a computer with both touchscreen and mouse here to test with so I didn't test that case. I did implement both gamepad and touch controls, so you could try them to see if they work.

Works in Firefox, on the same system.

I can't use mouse either, macos/Chrome. Otherwise, cool!

Awesome demo. I’ve really missed that map it’s been too long.

Yeah we use WebRTC for our games built on a fork of Godot 3.

https://gooberdash.winterpixel.io/

tbh the WebRTC performance is basically the same network performance as websockets and was way more complicated to implement. Maybe the webrtc perf is better in other parts of the world or something...

Yeah WebRTC is a bear to implement for sure. Very poorly designed API. It can definitely provide significant performance improvements over web sockets, but only when configured correctly (unordered/unreliable mode) and not in every case (peer-to-peer is an afterthought in the modern internet).

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, or is most of your revenue from the app stores? I wish I better understood the reasons web games (reportedly) struggle to monetize.

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.

That's really interesting, thanks! I agree Goober Dash deserves to be successful.

I would say WebRTC is both a must and only worth it if you need UDP, such as in the case of real-time video.

I mean, the only cases where UDP vs. TCP are going to matter are 1) if you experience packet loss (and maybe you aren't for whatever reason) and 2) if you are willing to actively try to shove other protocols around and not have a congestion controller (and WebRTC definitely has a congestion controller, with the default in most implementations being an algorithm about as good as a low-quality TCP stack).

Out-of-order delivery is another case where UDP provides a benefit.

Runs smoother than the Android home screen. :)

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.

This is neat. A little perverse, but neat.

Reply on news.ycombinator.com