Second Life does something very similar. Reliable and unreliable messages, binary format, multiple messages in a single datagram.<p>Unreliable messsages are for ones that are superseded by later messages. There's no point in retransmitting; you always want the latest object positions.<p>The big problem is message priority. Games need a low-latency, low-traffic channel for updates and a high-latency, high-traffic channel for assets. It's tough making this work on the open Internet. End to end QoS just isn't widely available. So using much less than the full available bandwidth is needed to keep intermediate FIFO buffers from filling up. This is related to the "bufferbloat" problem - network devices now all have lots of RAM, and if they have FIFO queuing and less output bandwidth than input bandwidth, they will build up huge queues that generate huge latency.<p>For QoS to work in the wild, there has to be some throttling or incentive to discourage too much high priority traffic. You'd like to have under 5% of your traffic at high priority. It's hard to make this work in the public Internet.
I've used ENet for my games which is pretty similar to this project. Unfortunately ENet does not support IPv6, and the pull requests on the ENet repository appear to be ignored. The ENet author refuses to accept any changes that break the ABI, which is highly unfortunate.<p><a href="http://enet.bespin.org/" rel="nofollow">http://enet.bespin.org/</a>
> GameNetworkingSockets is a basic transport layer for games.<p>I understand that this is primarily derived from a gaming platform, but is there anything that makes this useful specifically "for game" and not networked applications in general?
Would be great for TCP to better address the reliable transmission of messages for games, these “reliable UDP” code bases in game engines don’t address all of the other issues such as bandwidth sharing fairness and avoiding saturation of networking links, which ultimately will just make networks slower than faster and more reliable for everyone.
Anyone know how this differs from RTP?<p>I haven’t worked with either but did review the RTP spec, and many of these features appear similar.<p>RTP also has some multicasting features built in for broadcast delivery, which can be useful in certain contexts.<p>Edit: the reason I ask is that RTP is getting wide scale deployment and testing as it’s being used for WebRTC.
Stupid question. How do you solve (de)fragmentation and out of order delivery with unreliable protocol? What are cases and is it possible to make it simple?
The moment you say "reliable messages with UDP" you really are saying "we are implementing TCP on our own", which quickly turns into question "why?".<p>By its own admission, the project says: "The reliability layer is a pretty naive sliding window implementation". A bit scary if you really want to have guarantee message is delivered.<p>Also scary part: "Our use of OpenSSL is extremely limited; basically just AES encryption", "we do not support x509 certificates". OpenSSL is difficult, coming up with your own key exchange is likely problematic.<p>So I'm still searching for the answer as to why we need to do this? What's the market for this?<p>P.S. Yes, Valve being the author certainly brings some "reedeming value" to this!