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 Arena code 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 Arena should do is manage the game data and make communication requests.
I'm wondering if the HeartbeatAck was 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 Heartbeat reaches 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 Heartbeats only.
Bye should 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 Packet order. Time really is meta-data instead of an actual Packet ordering.
There's a bit of a problem with trusting data sent by the Client to the Server. Take a look in the code for PongClient that has to deal with the Paddle.

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.

UDP Pong - Client

Ping