Dealing with bursts of delayed packets from the client to the server

why dont you just dequeue the entire command buffer every server iteration?

why dont you just dequeue the entire command buffer every server iteration?

That would leave the server open for cheating would it not? By sending say 4-6 packets with 2 commands each (on every client step).

i dont know what kind of server architecture you have in place... but if that's what you're worried about, it's pretty easy to keep a "long term" statistics about how many packet you are receiving from a client... say in the last 10 seconds.. if that's way more than you expect, you have a cheater.

[quote name='kunos' timestamp='1315043295' post='4857081']
why dont you just dequeue the entire command buffer every server iteration?

That would leave the server open for cheating would it not? By sending say 4-6 packets with 2 commands each (on every client step).
[/quote]
The server needs to be able to handle "bogus" data from clients regardless, as well as act authoritatively to prevent cheating, so the number of packets or commands per update shouldn't be relevant.

i dont know what kind of server architecture you have in place... but if that's what you're worried about, it's pretty easy to keep a "long term" statistics about how many packet you are receiving from a client... say in the last 10 seconds.. if that's way more than you expect, you have a cheater.

Yeah I suppose that would work (my server architecture would allow this), there's a lot of "but ifs" here, but for example what if the client isn't "doing anything" at the movement (standing still, not rotating, not shooting, etc.) which causes no packets to be sent which would give the client a "buffer of unspent packages" that could be used to send a lot of commands really really fast at the end of those 10 seconds. I suppose there could be some heuristic for solving this also (say only accept max 6 packets per read cycle or something, or start dropping packets of more then X arrives at the same time, etc.).

What are the common ways of dealing with this, the inherent "burstyness" of network connections?

[quote name='fholm' timestamp='1315043765' post='4857085']
[quote name='kunos' timestamp='1315043295' post='4857081']
why dont you just dequeue the entire command buffer every server iteration?

That would leave the server open for cheating would it not? By sending say 4-6 packets with 2 commands each (on every client step).
[/quote]
The server needs to be able to handle "bogus" data from clients regardless, as well as act authoritatively to prevent cheating, so the number of packets or commands per update shouldn't be relevant.
[/quote]

A very good point, I sort of assumed this would be the case/answer.

Unless you have a dedicated network with hardware assisted timing you simply cannot, under any circumstances, rely on something like "every X ms".

Even high precision timing systems do not work, except perhaps for direct device control. They collect data in batches, associate it with timestamps and then send that. Turns out it's a surprisingly difficult problem to solve, since for even modest precisions (microseconds), length of cabling affects delivery times.

by sending commands at a blazing speed to move your character faster for example.[/quote]

Other way round. If you rely on packet sequences, then you open yourself to cheating.

A character can move X m/s or similar. Server and other clients can enforce that. If I receive delayed movement data for last 3 seconds, it doesn't matter how it was generated.

especially when they sometimes miss the current running fixed step update and get delayed another 15ms[/quote]
If you attempt to recover the state, then server moves simulation that far back in time and simulates everything again until present time. Results of such recovery may be seen as "snapping" by other players. Such approach requires keeping history of all actions.

Alternative is to try to bring lagging player up to current time, likely causing them to warp all over the place, at least as far as others can see it.

One UDP server socket

Have a session connect protocol handshake/double handshake and proper timeouts for inactivity on both ends

Let the 15ms server cycle process all that come in on the socket -- all sessions (have some session related data in every packet header to act as a simple cheat garbage filter -- discard those that dont contain the secret number for existing sessions)

If your clients are not supposed to send more frequently than the metered 30/60ms then you now how many to expect over any time interval.
Keep count over a short window (like 5 x 15ms cycles) and report excess (cheating).
Have the connections send Empty packet placeholders if no real data traffic -- need not be every cycle (which can help detect disconnects)


If this is UDP, duplications/out-of-order packets can happen and more frequently lost or delayed packet (on internet or even a lousy OS that runs intrusive background high level processes like Vista did). Use sequence numbers on your packets so the other side can detect missing packets/duplicates and handle them (probably report to the user if too many lost)
Some data lost/delayed can be ignored as out of date (ie current position frequently sent) but if you have events that the client needs to get to display properly or modal input commands sent once, you will need a much more complicated 'reliable' delivery of the data (resend window queues/acks/self throttling to wait for resends/timeouts/etc)

TCP is simplest but you can actually do both TCP for data that needs to be reliable and UDP for the frequent update kind that can be ignored if out of date.

Ive written reliable protocols using UDP but its alot of trouble unless you really need certain customizations.