Announcement

Collapse
No announcement yet.

Valve To Open-Source Their Steam Networking Sockets Library

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Valve To Open-Source Their Steam Networking Sockets Library

    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?pag...rk-Sockets-Lib

  • #2
    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.

    Comment


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

      Comment


      • #4
        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.

        Comment


        • #5
          Originally posted by smotad View Post
          Will the developers of Star Citizen take a look at this code?
          Why them specifically?

          Comment


          • #6
            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.

            Comment


            • #7
              Originally posted by cybertraveler View Post
              They're a very good company to have on our side.
              "steam drm kokoko" crowd does not approve

              Comment


              • #8
                Originally posted by discordian View Post
                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.

                Comment


                • #9
                  Originally posted by pal666 View Post
                  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.

                  Comment


                  • #10
                    Originally posted by discordian View Post
                    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.

                    Comment

                    Working...
                    X