ideally, your code should handle 250-500ms lag, and thus you'll need to interpolate between the data sent to you from another player
this is a game where lag will affect gameplay, and we don't care about cheating, so, i would just do very simple interpolation in between updates
and not worry so much about the actual amount of latency or updates..
the biggest problem you will face is "invariance," here being desynchs, but since you have a centralized server that makes all the decisions
this problem is already solved =)
i would implement fast interpolation pad_y = (0.9 * pad_y + 0.1 * pad_last_y); pad_last_y = pad_y;
So i should let the Clients kinda estimate where the ball will be on the next update?
Or insert an interpolated point between two of the updates?
yep, you have to. it's not a decision or design choice.. i updated my post and added some context as to why we have to do this and make do
i used 60ms in my example, but i've never had such a low latency on my connection it's usually in the 90's (97ms for example)
what this means is usually only that the response from me to the server will be delayed by 97ms, and that the movement will STILL be fluid
but ANY point in between me and the server could delay data unreliably before sending it
which means that it won't always be fluid, especially if the nodes wait too long to send and just gather your incoming data,
then send it in one bigger package (causing the server to get 10-20 updates in a single read())
Note: i didn't speak about advantages of UDP, such as congestion controls, but i'm sure you can read about it on your own
TCP has delayed ACK (which can be delayed a long time, even 200ms) and nagle algorithm isn't reliably disabled (and you shouldn't want to disable it either)
in short: use UDP for your game if you want the fastest throughput of small updates
but, personally i wouldn't go that far