Let's say you want to make a real-time game, perhaps a 2D topdown game.

Things you would do in the game to keep it simple are:

- Connect to the server

- Move the player with the keys

- Possibly press space bar to attack

- Send a chat message

But what would happen if a datagram from any of these situations get lost?

What would you do?

1. Connecting to the server .

If you send a UDP datagram to the server, the server would take your IP and port and then create a player

based on an ID it gives you, this it how it identifies you every time it receives a datagram from you.

But what if upon "connection" (not actually a connection, just a udp datagram that says 'make me a part of your server'), this initial datagram gets lost. Is it right to say that you would just resend it if after a certain period of time you did not receive a reply back from the server?

2. Moving the player/attacking

If at any time we move the player/press a movement key/attack key, we would send a keystroke

to the server telling it what key we pressed/released.

The server would then relay this to all the other clients.

But what if this keystroke datagram gets lost? Either upon client->server or server->clients.

Because keystrokes are happening all the time, is it efficient to just resend it all the time?

Or would we just ignore the fact that it got lost along the way because there's a chance that if you press a key again it will most likely make it the next time?

3. Sending a chat message

This would be something that MUST reach the server.

If it got lost along the way, after a certain period of time if we did not receive a reply from the other side/receiving end, do we re-send it?

Is it okay to just keep resending datagrams if we know after a certain period of time it did not reach?

And also, what about confirming if a datagram got successfully sent?

If client sends a chat message to the server, and the server receives it, should the server send a reply back to the client to confirm that it received it? What would happen if that reply got lost, what then?

Lots of such solutions exist, but you will build a good solution more quickly if you realize that it is really more a matter of latency than lost data.

Ideally, every update is absolute and not one in a string of dependent delta's. This way, if 1/2 of your packets are lost, the game continues to work fine but updates are roughly half as fast.

For player movement, this is often sufficient.

But what if you lose unique events like shots fired or attacks made?

These require some sort of ACK and possible re-send, or perhaps even duplication. But even in this case, if your server receive a message essentially saying "I shot Joe seven seconds ago," what should you do with it? You should ignore it. Game-play is better served by a spurious "miss" than by a seemingly random "hit."

Many architectures exist for handling these, but lets say you have just these two things to consider: movement and "events" (shots, attacks, etc.).

You can perhaps send movements (actual absolution position, rotation, etc.) on some regular schedule (NOT just when they change in the client, but every 1/30th of a second, for e.g.). If you are worried about a chatty protocol, add an ACK mechanism and stop sending once an [un-changing] position is acked.

Then, you can send "events" as soon as they happen and then every [n] ms thereafter until ACKED by the recipient. [n] would be something you could compute from your percieved latency on the connection.

So, for example:

* Every 1/30 second you sent a position update, and you just rely on the receiver to get them

* You monitor acks on acked communication and determine the round-trip-time (rtt) is 20ms

* An event (such as a shot) occurs, so you send E + {data about E}, and you starta timer to go off in [rtt] ms (20 ms)

When the timer goes off, you check to see if you got an ACK for E, and if not, you send it again.

If other events occur, you append them to the list of events to be sent when the timer goes off.

Eventually the events will all be acked and your event list will be empty, or you will decide it is too late (perhaps 1-2 seconds).

In general, a good test is to write yourself a proxy that randomly discards 1/2 of your packets and make your game play well using that. In practice, the internet is very reliable where UDP is concerned, since most routers will prioritize UDP over TCP packets, yet most packet loss is due to congestion and that congestion is almost always TCP traffic.