Valve To Open-Source Their Steam Networking Sockets Library

[phoronix]

Phoronix: Valve To Open-Source Their Steam Networking Sockets Library

Valve is preparing to make another significant open-source code contribution in the very near future...

http://www.phoronix.com/scan.php?page=news_item&px=Valve-Network-Sockets-Lib

[cybertraveler]

Very interesting! Valve are doing lots of great things for gaming, Open Source and GNU/Linux people. They're a very good company to have on our side.

[smotad]

Will the developers of Star Citizen take a look at this code?

[discordian]

such a protocol finally needs to get in the Kernel. I implemented it twice during my career on various microcontrollers, there exist a RFC for such a protocol (https://en.wikipedia.org/wiki/Reliab...agram_Protocol) and many open implementations.
This will be the Nth variant over a plain UDP socket.

[humbug]

Will the developers of Star Citizen take a look at this code?

Why them specifically?

[Danny3]

Valve is amazing.
Thank you very much for all your efforts and making the world a better place!
I'm glad that such companies exist that are worth recommending to my friends.

[pal666]

They're a very good company to have on our side.

"steam drm kokoko" crowd does not approve

[pal666]

I implemented it twice during my career on various microcontrollers, there exist a RFC for such a protocol (https://en.wikipedia.org/wiki/Reliab...agram_Protocol) and many open implementations.

i'm not aware of subj's specs, but i'm aware of needs of game transport in general and those needs can't be satisfied with rudp. you don't have to retransmit all information in case of lost packet in game transport, for example you are only interested in current object position, no need to resend old position to be immediately overwritten by current one.

[discordian]

i'm not aware of subj's specs, but i'm aware of needs of game transport in general and those needs can't be satisfied with rudp. you don't have to retransmit all information in case of lost packet in game transport, for example you are only interested in current object position, no need to resend old position to be immediately overwritten by current one.

You can bet Valves implementation will be close to it in functionality, rUDP allows various configuration for re-transmission, but I am not sure how easy the options could be mixed in one connection. It`s a bit pointless anyway as you would just use different sockets for different usecase's and don't mess with socket states, the various implementation loosely but their own things on top too.

So there's another hit in https://github.com/search?q=rudp, but some common standard supported by the kernel is still missing.

[microcode]

It`s a bit pointless anyway as you would just use different sockets for different usecase's and don't mess with socket states

There's a good reason not to mess around with multiple sockets: state management on the server (and client!) becomes considerably more difficult.