Game networking, limiting amount of movement packets

Question

I have been developing a server/client model for a game project I am working on. Everything works great, client side prediction works, server reconciliation works. Basically, the character can move smoothly without any hiccups.

However, the problem is that I am currently not using frame independent movement, it doesn't rely on the elapsed time between updates. Every time a movement packet is received, it will move the character x amounts of pixels. The packets are gathered on the client with a certain rate.

If someone were to modify the rate so that it would gather it faster, that means it would send more packets and make it move faster. Essentially, they would be speed hacking.

How would I go about preventing this behavior. If I try to add frame independent movement, server reconciliation doesn't work any longer since it doesn't know how much to move it after the server correction was received. Is the best way to just limit how many movement packets that can be received server side per second?

I have been reading the source networking article, but they do not mention anything about this as far as I can see.

By the way, when I send these packets, I do not send them as they are gathered, rather I send them bunched together at another rate, to reduce bandwidth.

Edit: I think I was a little bit unclear about my packets. My packets contain user commands that holds the current state of the keyboard, mouse and whatever else is collected. The server receives the packet, which can hold MORE THAN 1 user command, as it sends the pakcets at a slower rate than the commands are collected. This is exactly what is described in the source networking article. The server receives the packet and handles ALL user commands as soon as it is received, thus if the packet contains a lot of user commands (the client modified the rate of which it collects them, or duplicated them) the server will move it more than intended. Modifying how often it sends the packets doesn't matter, but the gathering of the user commands does.

Let's say the server sends the packets every 100ms, and collects the commands every 50ms. That means every packet will hold 2 user commands. But if someone modifies the collection rate to, say every 10ms. Every packet will contain 10 user commands which would move the character further since the server moves it for every user command.

Answer 1

Your game shouldn't depend on the speed at which the packets are sent as it will vary depending on your internet connection regardless of what rate you attempt to send them.

Instead your server should move the character depending on the user actions (e.g. while they are pressing (sending) W move them forward, or if you are counting mouse clicks then send how many times they clicked since the last packet was sent).

Depending on how many movement packets a client has sent is simply too unreliable.

Answer 2

I would suggest making a separate buffer for each player that is responsible for squashing commands together.

Basically, it should reduce a set of network packets into an approximation of user's input, which is sampled only once per game update that should result in equally significant change for every player.

The question is, what should be sampled from the state and what strategy to use for squashing commands together.

For instance, if the player were to send one of WASD events, you could build up a vector of his movement and sample its direction, resetting the vector back to 0 after that to accept new input. Like, having received DDWSWW the sampler would output pi/4 degrees as a direction of vector (2; 2), and you would move the player in the given direction, same distance for everyone. Of course, this example is primitive and suits hardly any game, but the pattern is quite generic.

You can employ more sophisticated strategies with squashing commands, like leaving a tiny fraction of the previous input sample to apply further incoming commands on top of it, much like smoothing the movement. There's a lot to play with there.