This topic looks very interesting. If I was to use a network engine such as Lidgren 3 (C#) which supports Ordered/Unordered RUDP, would the above be necessary ? I get that sequencing would be useful especially when following the Tribes model for adding priority on what data should be sent 1st. Sorry just trying to wrap my head around all these topics. I wish there was a simple way to discuss prediction, extrapolation (lerping/smoothing) and lag all at the same time… Let us already assume the internet sucks as always.

Another thing that concerns me is dealing with collisions or how to apply deal with creating simple colliders before diving right into adding network physics. I find lots of libs out there that discuss physics integrated with a specific engine: OpenGL, DirectX, Ogre, SDL, XNA, Unity whatever. They all have their own way of dealing with geometry. I wish to a simple universal view prior to choosing graphics. As the server will be headless in most cases anyway.

Good luck!

Thanks for tutorials, they have been very helpful for me.

I intend to start working with a team of friends on our first multiplayer online game. I read all the articles of the series networking for game programmers and my only question is how do i change the code in the last example to make the server handle multiple clients each with his own IP address, sequence, ack, and ack_bits?

Also, you mentioned in the commentaries that, for security reasons, a PC programmer should use RackNet or OpenNTL. Does OpenNTL use UDP? And, does it provide reliability and flow control?

For example, if you know the IP of another player (you always will in P2P games…) you could spoof a packet sent to another computer so it looks like it comes from that players IP but with a really high sequence number. This would cause all packets from that machine to be considered old and that player would time out. Now consider how can you fix this? OK lets add a random guid session id instead of IP as session and it’s much harder to spoof packets.

As for books on security, sorry I don’t have any to recommend. I just work this out as I go

The other problem is that the “Virtual Connection over UDP” example used the IP address as the session. Instead you should generate some random guid and use that instead, I think there is a mention of this technique in the Quake 3 Network Model article by Brian Hook. It also help with esoteric NAT issues where the IP/port can get shuffled automatically (mid-connection).

Another standard thing to do which is not done here is to start with a random session id. This again provides a bit better safety against man in the middle attacks / spoofing and is a good practice anyway.

Another problem with the code is the reliability and flow control uses a very inefficient algorithm based around std::list. You can do much better with a sliding window implementation or ringbuffer. It’s got much better cache behavior.

That’s all I can think of. cheers

As countless others have said, much respect re your superb ability to instruct others. (Your articles on timing remain the best around.)

I want to ask: You repeatedly mention that you would not consider this production ready code, and at one point you mention this approach being “non-hardened”. In your professional capacity, do you personally do the security work on the protocols you develop? I’m writing a smaller game and so I’m not too concerned with there being security breaches, so long as I can detect them, log them and fix them later.

What points would you suggest require greater security here, aside from the IP-spoofing you mentioned? Also how did you go about learning the security side — was it mainly through trial and error? And do you think you’ll ever write any articles on this aspect?

Thanks.

Yes the interaction between TCP and UDP is extremely complicated. I just added that to the end of an article as an interesting point to consider. Hopefully people understand that yes, other traffic sent over the network can influence the behavior of your game. I’m not proposing the technique described in this article as a *solution* for that particular problem of UDP vs. TCP flows.

cheers

You can choose to accept this RTT measurement as some sort of “maximal” RTT incorporating frame aliasing, or you could receive packets on a separate thread and timestamp the packets with the actual time of receive. This way you could get the network RTT without frame aliasing.

Both are actually useful, for example the frame aliased RTT is actually the best measurement about how long it takes for a packet to go to the other computer and actually get back to your game code which processes it. Network RTT is the best indicator of the actual quality of the connection.

Note that many people actually write dedicated servers that immediately reply to the packet sent, vs. sending the reply on the next frame to reduce latency even further (if the server updates at 60Hz, then you have another 16.66667 delay added to the RTT…)

cheers