Valve to open source 'GameNetworkingSockets' for developers, Steam not required | Hacker News Reader

Valve to open source 'GameNetworkingSockets' for developers, Steam not required

gamingonlinux.com

152 pointspferde17 comments

This is lovely. But if you're developing something on the web:, here's a quick comparison with what you get in WebRTC in your browser: SCTP over DTLS:

  > Connection-oriented protocol (like TCP)  -- yup
  > ... but message-oriented instead of stream-oriented.  -- yup
  > Mix of reliable and unreliable messages  -- yup
  > Messages can be larger than underlying MTU, the protocol performs fragmentation and reassembly, and retransmission for reliable -- yup
  > Bandwidth estimation based on TFP-friendly rate control (RFC 5348) -- I don't think so?
  > Encryption.  -- yup
  > Tools for simulating loss and detailed stats measurement  -- you can use linux's netem on containers to simulate loss; not but you have to collect your own stats.

A bit of background: I wanted to do some interesting stuff with actors interacting with some centralized arch - I believed (and still do) that some smarts around actors could be used for some interesting hard real-time applications. I decided that WebRTC data channels might be the best fit (as WebSockets are above TCP). The idea was to layer a server model over P2P (potentially branching out to hybrid for accessing actors in other clients directly).

You either have to use a subset of Google's blessed languages (C/++ or Java according to a quick search I did today) for the backend, or you're stuck in serverless land. Building the native library requires a 10GB download and many steps. Implementing WebRTC is no small effort and not appropriate for quick weekend experiments.

It's fantastic tech, but there is a serious lack of library support.

I recently found a Unity plugin for WebRTC that seems to work pretty well so far (no affiliation):

https://assetstore.unity.com/packages/tools/network/webrtc-n...

But I agree, the options for implementing WebRTC outside of the browser are still very limited and/or painful at the moment. Having options also helps de-risk what is a rather core feature of games/apps that need it, so this is really cool of Valve!

Wow, today I learned about netem. Thanks! :)

Check out https://github.com/urbenlegend/netimpair which is a much nicer wrapper around netem.

Indenting a line with 4 spaces on HN disables word wrap, making your comment very difficult to read on mobile.

We run into this problem all the time. HN really needs some markup for quotes.

It also clips the text about 2/3rds of the way across the screen horizontally, so you have to scroll back and forth in this tiny box to read it.

> HN really needs some markup for quotes.

Italics work fine.

Except when you want to keep the italics that are already inside the quote.

It's also clear that people expect some kind of markup, which is why they often mistake fixed-width markup for quote markup.

> Except when you want to keep the italics that are already inside the quote.

If you're sure it actually matters you can turn off the italics around the portion that was originally italicized, which isn't typographically correct but it gets the point across. Italics are the happy medium between something perfect which hasn't been implemented (or described) yet and the visual diarrhea people sometimes post.

Yes, there are workarounds.

My entire point is that people choose code formatting as a workaround, and that isn't viable. We really ought to fix the problem, rather than complain every time someone uses the wrong workaround. The latter isn't a scalable or effective solution.

HN has a wonderfully succinct amount of markup, but it's really lacking in this one particular area.

> Bandwidth estimation based on TFP-friendly rate control (RFC 5348) -- I don't think so?

SCTP does have (TCP friendly) congestion control

This looks potentially delicious. There's some other options out there, but they either felt a little aging (RakNet) or did too much (libuv) the last time I used\evaluated them. Interested to see what this one is like.

Yes, if it's any good, it can save game developers (and not only them) a lot of time.

Probably the most equivalent existing open source thing out there is ENet, which doesn't do encryption or detailed stats. If you've signed the steam NDA (which is free of charge iirc) you can check out the existing docs for the closed source version, which has extra features on top of this.

I'll believe it when I see it; the authors are well-known for arbitrarily-long delays on upcoming releases as well as bare-bones git repositories with nothing inside.

Unfortunately, I expect that this reference implementation will be a pile of C++, but hopefully the protocol itself will be sufficiently-well-documented to permit implementation in other languages.

Seems like this would have a use well beyond gaming, particularly in the realms of real-time monitoring.

Reply on news.ycombinator.com