UDP Pong - Recap
This was the largest tutorial to date. It took me three weeks to write and cleanup (where as it normally takes me one). As always, there are some good things, and some bad. Let's take a look at what we could fix and possible problem areas:
- This game Server really isn't the most optimal thing out there. In practicality, we should be pre-allocating a lot of the dynamic objects and reusing things. For example, maybe discarding the
Arenas instead of resetting them is a bad idea. But I want to keep things as simple as possible for this tutorial series. I'll leave the ricing to you readers.
- Should the
Arenacode manage the connection with the clients? I don't think it should in retrospect. That should more be a responsibility of the
PongServer. This includes setting up the connection, handling
Heartbeats, and disconnects. All the
Arenashould do is manage the game data and make communication requests.
- I'm wondering if the
HeartbeatAckwas a good idea since it requires the Server to respond to a
Heartbeat. If the Client sends one, but it drops during transmission, there will be no Ack created. And even if the
Heartbeatreaches the server, what's there to guarantee that the Ack will reach back to the Client? Nothing really.
When I was testing this earlier with a friend somewhere else in the USA, I had the
Heartbeats send once every second, and it would time out if for 15 seconds no
Heartbeat(or Ack) was recorded. It would usually time out after a few minutes (we were both on crappy connections). This means that 15
Heartbeats and their Acks were dropped in a row (not unlikely), which is pretty bad. So in this final version it now sends 5 Heartbeats per second and has a timeout of 20 seconds. This means that it would need to miss 400 consecutive
Heartbeats to time out, which is a lot less likely.
Maybe a better solution would be to have both the Client & Server send
Heartbeats & Acks, or just
Byeshould probably have its own Ack. In the Client code we waited one second to make sure the message was sent. This is a little bad. Maybe instead waiting a second or hearing an Ack first would be a better idea. This also better models a TCP connection termination.
- Possibly counting an integer instead of a Timestamp might be better for managing
Packetorder. Time really is meta-data instead of an actual
There's a bit of a problem with trusting data sent by the Client to the Server. Take a look in the code for
PongClientthat has to deal with the
It's very possible (and easy) for a player to lie about their Paddle movement. As of right now, the Server doesn't have any code to verify the Paddle's movements have been under 100 pixels/sec. It might be a fun exercise for you to make a Client that will match the Ball's Y position with that of your Paddle's.