Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Direct Sockets API in Chrome 131

chromestatus.com

Post reply on HN
Print view View original

31–40 of 171 posts

Re: Direct Sockets API in Chrome 131

#31

Post by modeless »

nightowl_games wrote: post #23
modeless wrote: post #10

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.

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).

Re: Direct Sockets API in Chrome 131

#32

Post by huggingmouth »

modeless wrote: post #30
dboreham wrote: post #25

Earlier quoted context omitted.

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.

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…

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.

Re: Direct Sockets API in Chrome 131

#33

Post by nightowl_games »

modeless wrote: post #31
nightowl_games wrote: post #23

Earlier quoted context omitted.

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

Re: Direct Sockets API in Chrome 131

#34

Post by windows2020 »

modeless wrote: post #31
nightowl_games wrote: post #23

Earlier quoted context omitted.

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).

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.

Re: Direct Sockets API in Chrome 131

#35

Post by modeless »

nightowl_games wrote: post #33
modeless wrote: post #31

Earlier quoted context omitted.

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.

Re: Direct Sockets API in Chrome 131

#36

Post by jeswin »

I prefer web apps to native apps any day. However, web apps are limited by what they can do.

But what they can do is not consistent - for example, it can take your picture and listen to your microphone if you give permissions; but it can't open a socket. Another example: Chrome came out with an File System Access API [2] in August; it's fantastic (I am using it) and it allows a class of native apps to be replaced by Web Apps. As a user, I don't mind having to jump through hoops (as a user) and giant warning screens to accept that permission - but I want this ability on the Web Platform.

For Web Apps to be able to complete with native apps, we need more flexibility Mozilla. [1]

[1]: https://mozilla.github.io/standards-positions/ [2]: https://developer.chrome.com/docs/capabilities/web-apis/file...

Re: Direct Sockets API in Chrome 131

#37

Post by modeless »

lifthrasiir wrote: post #29
dboreham wrote: post #25

Earlier quoted context omitted.

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.

Re: Direct Sockets API in Chrome 131

#38

Post by crote »

chocolatkey wrote: post #3

When reading https://github.com/WICG/direct-sockets/blob/main/docs%2Fexpl... , it's noted this is part of the "isolated web apps" proposal: https://github.com/WICG/isolated-web-apps/blob/main/README.m... , which is important context because the obvious reaction to this is the security nightmare

That doesn't really make it any better, if you ask me.

The entire Isolated Web Apps proposal is a massive breakdown of the well-established boundaries provided by browsers. Every user understands two things about the internet: 1) check the URL before entering any sensitive data, and 2) don't run random stuff you download. The latter is heavily enforced by both Chrome and Windows complaining quite a bit if you're trying to run downloaded executables - especially unsigned ones. If you follow those two basic things, websites cannot hurt your machine.

IWA seems to be turning this upside-down. Chrome is essentially completely bypassing all protections the OS has added, and allowing Magically Flagged Websites to do all sorts of dangerous stuff on your computer. No matter what kind of UX they provide, it is going to be nigh-on impossible to explain to people that websites are now suddenly able to do serious harm to your local network.

Browsers should not be involved in this. They are intended to run untrusted code. No browser should be allowed to randomly start executing third-party code as if it is trustworthy, that's not what browsers are for. It's like the FDA suddenly allowing rat poison into food products - provided you inform consumers by adding it to the ingredients list of course.

Re: Direct Sockets API in Chrome 131

#39

Post by theamk »

huggingmouth wrote: post #32
modeless wrote: post #30

Earlier quoted context omitted.

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…

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.

Re: Direct Sockets API in Chrome 131

#40

Post by apitman »

crote wrote: post #38
chocolatkey wrote: post #3

When reading https://github.com/WICG/direct-sockets/blob/main/docs%2Fexpl... , it's noted this is part of the "isolated web apps" proposal: https://github.com/WICG/isolated-web-apps/blob/main/README.m... , which is important context because the obvious reaction to this is the security nightmare

That doesn't really make it any better, if you ask me. The entire Isolated Web Apps proposal is a massive breakdown of the well-established boundaries provided by browsers. Every user understands two things about the internet: 1) check the URL before entering any sensitive data, and 2) don't run random stuff you download. The latter is heavily enforced by both Chrome and Windows complaining quite a bit if you're tryi…

> Every user understands two things about the internet: 1) check the URL before entering any sensitive data, and 2) don't run random stuff you download

I think you're severely overestimating the things every user knows.

Post reply on HN