Network jitter, client input to server

Question

I am working on a authoritative client/server game, looking to both Valve and Gaffer to understand the concept.

Currently, the server simulates at 20 ticks a second. The inputs received from the client is buffered and only processed during one of these ticks. However, if a client sends input at a faster rate, say 60 times a second, that client will move about 3x faster than regular clients.

A solution to this would be to have the server combine/unify the inputs in the buffer and process this input once, instead of processing the buffered inputs individually.

Now, given the latter solution, a client with a send rate of 20 could be subject to network jitter, which could cause the server to receive 2 or more inputs at the same time. This would cause the server to combine/unify the inputs, when they should actually be processed individually.

So my question is, how should the server handle inputs to prevent more inputs from being processed than necessary, while not skipping inputs that arrive at the same time?

I hope I make sense, if not just tell me to elaborate :)

Answer 1

A simple solution i found, is to keep track of how many server ticks have gone without processing input from the client. This amount is then decremented for each subsequently processed input.

This allows for multiple inputs to be processed at each server-tick, but no more than the tick-rate.

Im still open for other ideas, but for now, this is what i'll stick with.

Answer 2

I'm not sure why so many people seem to have so much trouble with this. The server simulates 20 ticks per second. End of story.

Clients are expected to roughly send inputs at about that rate, probably slower (since you do not normally generate 20 events every second). But, whatever... the server still simulates 20 ticks.

That means none more and none less than if your client sends 60 inputs per second (or 240 inputs?), they will queue up and when the server processes its next tick, it will ignore all but the last commands received (you can as well only process the first few received, but it usually is more desirable to ignore old commands rather than new ones).

The server will process exactly the number of commands per tick per client that you allow. Not one more.

If a client continuously sends high volumes of updates, not just as a matter of a short burst (this may actually happen sporadically), the server may simply disconnect the client and flag the user as possible cheater...