   Client-Side Prediction
  I'm trying to make as simple an example as I can so that I can later expand on it when I start my real game. To avoid cheating I want to control all movements on the server, so I'll be sending data from the user when they move to the server, which will then send back the position that they are now at and move them (or in this case correct their on-screen position if it was predicted incorrectly). However, I am still having issues with some of the concepts involved in just handling the movement on the server. If I understand it correctly, I'll be sending updates to the server every 100ms (for example), and I want to tell the server what I did during that 100ms so that it can move me accordingly. It obviously wouldn't make sense to just tell the server how far I moved since that defeats the purpose, so what am I actually sending the server? Do I tell it what buttons I pressed and how long I held those buttons down?   
  You would send your keypress to the server. For example, if you want to move forward, every 100ms, you tell the server that you are holding the move forward button (W?). The server should then push you forward until the next loop.This is a terrible way to do things, especially for fast-paced games (which I'm guessing a 100ms update loop would indicate). With a ping of 100ms, the player will have a 200ms visual lag between when they move on their screen and when they pressed the button.It's much better to run a physics simulation on the client and the server (or at least the client). When the player hits W, he/she can immediately begin to move forward. Then, every 100ms, send an update to the server of the new position. If the distance between the old position and new position is something that would be impossibly fast, throw it out and force the player to their old position.   ;  Yes I realize that the lag would be terrible like this, but that is why I would be doing the client-side prediction (just running the physics simulation on the client as you said).  However, what if they aren't holding down the button the whole time?  It wouldn't make a big difference, but over time the inconsistencies could add up to be an issue.   ;  If they aren't holding the button down, I wouldn't really worry about it. However, if you really wanted to, you could send a byte or less (0-255, 255 is a full 100ms of button-pressing, 0 is the smallest amount of time possible) that indicates the length of button press. Take this length value, turn it into a decimal server-side (1.0 is a full 100ms button press, 0.0 is barely ever pressed etc), and multiply the movement vector towards this.Example: Players move 1 meter per cycle (100ms).W is pressed for 0.5 cycles (50ms). Client tells server this.Server reads this, and moves player forward 0.5m this cycle.In the end, given the latency, players would tap a button expecting a slight change, and probably hold the button down until the change occurred, making the slight change become a large one and very frustrating.Not only that, but players could get a very slight advantage over other players by spoofing the length packet into always being 1.0, allowing them to react faster than other players. You really are better off just sending and comparing positions (or even an offset vector).   ;  Or you can discretize your input sampling to, say, 30hz and send 3 (possibly delta compressed) input data on every network update. If you run your server at the same frequency you can easily fit what input goes with what server update.   