This would depend on your game. If it's a board game like chess you want the server validate or else the client could hack it to bypass the client side rule checks. Let's say they make their king move 6 spaces in a zigzag pattern because they were able to bypass the client side rules check. Locally they can do that all they want, but the server would validate that move and realize it's not valid and not update the server board or the opponents client board. So that cheating client is only cheating themselves because now they are out of sync with the server and other client.

Ideally the server would send back to the cheating client a 'no no' msg and move the piece back but chances are if they hacked their client they'll intercept that 'no no' msg and not let it get to the application.

You will want the server to do some kind of validation. It could just be sanity checks like making sure the King in chess only moves 1 tile.

This would depend on your game. If it's a board game like chess you want the server validate or else the client could hack it to bypass the client side rule checks. Let's say they make their king move 6 spaces in a zigzag pattern because they were able to bypass the client side rules check. Locally they can do that all they want, but the server would validate that move and realize it's not valid and not update the server board or the opponents client board. So that cheating client is only cheating themselves because now they are out of sync with the server and other client.

Ideally the server would send back to the cheating client a 'no no' msg and move the piece back but chances are if they hacked their client they'll intercept that 'no no' msg and not let it get to the application.

You will want the server to do some kind of validation. It could just be sanity checks like making sure the King in chess only moves 1 tile.

Do you have to worry about cheating in your chat application? If not, then I wouldn't fret about it too much. Have the pathing be done on the client side. When the client updates the server, the server will check to see if the client is in a valid location. If he is not in a valid location, send back a response that tells them where they should be. The simplest way for the server to do this would be to just send back the player's last known valid position. When the client receives this information it should either: Calculate a new path from the position the server responded with, or simply stop moving altogether. This will get the job done.

It could allow the player to cheat, though. Consider a situation like this:


W: Wall
".": Valid position
@: Player
X: Destination

WWWWWWWWWWW
W....W.....W
W....W.....W
W..@.W..X..W
W....W.....W
W....W.....W
WWWWWWWWWWWW


There is no valid path for the player to the destination X. They're each blocked by walls on both sides. With only validating positions and not paths, the player could send the server a packet with its position inside that unreachable room, and the server would allow it. You can somewhat mitigate this by setting a maximum distance the player can travel between server updates, but that won't work all the time and can cause the client to seem laggy if it can't get updates to the server that often. Another potential solution is to, on the server, draw a line from the player's last known position and the new position and ensure that all positions along the line are valid positions. You could also prevent another kind of cheating using this method by making sure that this line is no longer than the distance the player could actually move in the time between now and when the player was at the last known position.

I'm confused because it sounds like we are saying the same thing. Have the server do validations/sanity checks.

I'm confused because it sounds like we are saying the same thing. Have the server do validations/sanity checks.

We are. That's the only sane way to do it. I guess we're all just giving ways he could do it on the server