Networking/Packet Design

Question

When using a Client-Server model, it's necessary for those two parts to communicate data back and forth. There is one specific area that I've been thinking about and unsure about. That being putting certain information in a main update packet, that is sent every n milliseconds, or send it once when it happens. An example would be a turn-based strategy game. When one player's turn ends, and the next player's turn starts, you could send one packet to notify the clients of the change, or every n milliseconds, tell the client whose turn it is and it can determine when it changes. These are the pros I see to these approaches:

Inside Update Packet:

• Harder to become desynced if packets are lost, whereas if sent as an individual packet and the client fails to receive it, could create big desync issues.

Individual Packet:

• Sends less data between the server and client since it only sends it once, instead of every n milliseconds.

I'm fairly new to game design, so I'm not sure if there is a general consensus about the proper way to do this. There may also be another solution that I haven't thought of. Any input would be great.

Answer 1

In general, you want to minimize the bandwidth you use and avoid latency spikes. Don't send data you don't have to.

There are pieces of data that will be constantly changing, such as position in a real-time game. These you can and probably should just send at a steady rate. If one of the packets gets lost it's no big deal as the client will just get one of the following ones anyway. This is one of the many reasons games often don't use TCP: it will stall delivery of messages until it successfully delivers what may already be stale data.

Other data infrequently changes, such as the current player's turn in your example. This data need only be delivered once. That may mean that it needs to be sent multiple times to deal with packet loss in a UDP-based protocol. In such a case, you need a way to know when data has been delivered successfully. TCP has that built-in, but UDP requires you to devise your own mechanism.

Requisite reading for beginners: http://gafferongames.com/networking-for-game-programmers/

Answer 2

A lot of this depends on how you're sending the packets: TCP or UDP.

TCP protocol establishes a connection with sequencing and acknowledgement that protects against errors like a lost packet by periodically resending until the receiver successfully sends back an acknowledgement, so you can safely assume one 'send' will get there eventually unless the connection is dropped, which should be an obvious error to catch.

UDP on the other hand has no connection, so no safeguards like this and could easily have lost packets. If you need to use this protocol, you could construct and send back acknowledgements of your own. Even if you send a hundred packets you can't guarantee any has been received without an acknowledgement of some kind, but this is essentially adding TCP-like behavior into UDP. Just use TCP if at all possible.