Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Never trust the client

gafferongames.com

Post reply on HN
Print view View original

121–130 of 155 posts

Re: Never trust the client

#121

Post by 746F7475 »

djsumdog wrote: post #54
xenadu02 wrote: post #12

"Never trust the client" is good advice for every kind of application. Clients are filthy liars. Clients have bugs. Old clients don't upgrade. Packets arrive out of order. ACKs never make it to clients, causing clients to repeat what the client believes to be a failed operation. All of this is before even considering an attacker actively trying to subvert you. The server should always be the source of truth. It shoul…

I saw a talk where a guy was showing how to cheat at some games. A lot of games will detect and crash you out if they detect a debugger attached to them. Things like Punk Buster, et. al. are more like anti-virus software: they try to find the signatures of known chat clients. So it's best to write you own...and rename your debugging process to "Google Chrome." He got pretty far with his auto-walker in some MMOs. He h…

I would love to play around with "botting" in some games, but I just don't even know where to begin. I tried to create super naive autoplayer years ago in C# by trying to just send keyboard keys into games, but most games didn't even receive the inputs.

Re: Never trust the client

#122

Post by Ogre »

trjordan wrote: post #78
kcbanner wrote: post #73

Earlier quoted context omitted.

I think you might be misunderstanding the scope of an "input". It's something like "the player pressed the key/button that maps to move forward", not "move to position X". Teleport hacks wouldn't be possible in the former case because the player has to actually move their avatar to the desired position by traversing the game world through a series of inputs. The server would then process the movement inputs, and the…

Is an input always valid? "Firing once" is an input: you have to validate that it's been long enough since last firing that you should act on it (limit the rate). "Moving left" is an input, but by how much? Can I send "Left, 9999999" and replicate a teleport hack by pre-calculating these inputs? You could bound the inputs to a simple stream of enums (FIRE, LEFT, RIGHT, etc.), but it wouldn't be crazy to batch it up a…

"Moving left" is NOT an input. An input is "The controller is pushed to the left" (with perhaps a numeric value of how far it is pushed to the left). "Firing once" is similarly NOT an input. "The fire button is down" and "The fire button is up" are inputs. That is how well implemented first person shooters have worked since the Quake days (I think Quake 2 actually).

The point of the article is actually that the server doesn't validate anything. There's nothing to validate. The only data it gets from the client is the state of the controls. Then it runs the real simulation. The client only ran a prediction of what it thought the server would do. Sometimes, it's wrong and corrects itself when it gets new values from the server.

Re: Never trust the client

#123

Post by iopq »

trjordan wrote: post #78
kcbanner wrote: post #73

Earlier quoted context omitted.

I think you might be misunderstanding the scope of an "input". It's something like "the player pressed the key/button that maps to move forward", not "move to position X". Teleport hacks wouldn't be possible in the former case because the player has to actually move their avatar to the desired position by traversing the game world through a series of inputs. The server would then process the movement inputs, and the…

Is an input always valid? "Firing once" is an input: you have to validate that it's been long enough since last firing that you should act on it (limit the rate). "Moving left" is an input, but by how much? Can I send "Left, 9999999" and replicate a teleport hack by pre-calculating these inputs? You could bound the inputs to a simple stream of enums (FIRE, LEFT, RIGHT, etc.), but it wouldn't be crazy to batch it up a…

No, it's more like "move left" and you move left at your velocity (95, let's say) for that one frame. Next frame you can send any move, but it will only move you 95 spaces in that direction, no more.

It's the same as just holding down a button on your keyboard - the game engine moves you according to the rules. Now you're just transmitting the fact that the player is facing NW and sent a move left command. You're just running the game on the server like you would on the user's machine.

Conceptually it's actually simpler - you're just running the same thing on the server and sometimes backtrack in the client when the connection is laggy.

Re: Never trust the client

#124

Post by clevernickname »

zubspace wrote: post #50
vvanders wrote: post #2

They missed one key bit on CS's network model(which is what made it so great) is that they would actually re-wind the gamestate to do hitchecks so you could have a latency of 200ms+ and have a reasonable experience. Also the common term for resolving these types of things on the client is called "dead-reckoning". You've always got a diverging states from latency so you're continuously trying to reconcile this on the…

There's something I always wondered about the gamestate rewind thing: Is it correct that the gamestate rewind only works for hitscan weapons (instant hit bullet)? What about slow moving projectiles or physically accurate bullets? Can the server spawn the projectile 200ms in the past at the time you pressed the button? But then other clients would receive the information about 400ms later after the initial keypress, w…

In Source Engine games, there is no lag compensation for projectiles. The lower your ping, the faster the projectile is spawned on the server. You can see this very clearly when playing on high ping: you click mouse1, you hear the rocket fire, but the rocket doesn't appear for a good fraction of a second.

Since TF2 is very heavily based around projectiles (Soldier's rockets, Demo's pills and stickies, etc) many competitive players play with their cl_interp (determines how many ticks worth of game state are delayed before being displayed, interpolated, to the player) set lower than default (which is 2 ticks at 66 ticks per second by default). This results in jerky movement if packets are lost, but it ensures that they see threats as soon as possible so that they can fire their projectiles with minimal (real time) delay. I think it might also have some effect on client side input buffering; not sure, but that would be an even bigger reason for projectile users to want low interp.

Re: Never trust the client

#126

Post by clevernickname »

Thaxll wrote: post #94
MustardTiger wrote: post #85

Earlier quoted context omitted.

No it is not, as I said many games do it correctly. It is a very simple distance check, you can perform millions per second on cheap commodity hardware.

So why do you think most games use p2p?

Most games use P2P because it's a hell of a lot cheaper to run 1 or 2 servers for matchmaking and offload all of the simulation and network cost to the players, rather than hundreds or thousands of dedicated servers, and because their developers were focused on consoles where cheating is much more difficult. If you're already using dedicated servers for whatever reason, though, the computational cost of strictness with player input is not so great in the grand scheme of things.

Re: Never trust the client

#127

Post by bcook »

ultramancool wrote: post #119
smelendez wrote: post #114

Earlier quoted context omitted.

> Yep, gamers are literally accepting rootkits that allow arbitrary remote code execution on their machines. That's certainly risky and rather horrible, but what's the alternative? Multiplayer games are a huge business and a huge culture, and all that goes down the drain if people cheat. Game companies have millions of people around the world competing for prestige and money. They're running game software on their ow…

The solution is simple: do everything server side. Look at World of Tanks for a great example of this. They pretty much let people run free with mods in multiplayer and even the worst of those mods can barely provide an advantage in online play. They do this by managing absolutely everything server side. Ammo, direction of aim, position, enemy players appearing and disappearing etc. Basically your server should be bu…

World of Tanks is exponentially less reliant on latency than an FPS, right?

Honestly, I immediately smell naivete BS when someone says "the solution is simple"...

Re: Never trust the client

#128

Post by chris_wot »

stefs wrote: post #93

another recent example of "never trust the client" is the amazon kindle unlimited debacle. in case you missed it: the client syncs the last page read. so you can buy a book, jump to the last side and amazon marks it as read, without checking for intermediate states. the problem is: amazon pays authors by "pages read". so people publish fake books with 3000 pages, let sweat shops try the book for free and just jump fr…

That could reasonably be considered fraud. If I was Amazon, I'd pursue them, publicly.

Re: Never trust the client

#129

Post by taneq »

ageektrapped wrote: post #30
xenadu02 wrote: post #12

"Never trust the client" is good advice for every kind of application. Clients are filthy liars. Clients have bugs. Old clients don't upgrade. Packets arrive out of order. ACKs never make it to clients, causing clients to repeat what the client believes to be a failed operation. All of this is before even considering an attacker actively trying to subvert you. The server should always be the source of truth. It shoul…

> The server should always be the source of truth. It should always enforce all the consistency rules. Database schemas can be a critical tool here as well. Amen. And I'm a client developer. Clients aren't for data validation, etc. That's the server's job because the server has to store it, use it, ship it off to other things. Clients are for displaying all that data in a way a human can understand. It has people ski…

The server is the model and the controller. The client is the view, and marshals input to the controller. Doing it any other way is bananas.

Re: Never trust the client

#130

Post by oridecon »

stefs wrote: post #86

now that i think about it - doesn't GTA5 suffer from the exact same problem? cheaters spawing tanks above people practically must be a client game state problem.

Yes and that is why I think it's a new business model to make games not last long on the PC. At least the multiplayer part.

They promote the shit out of games before release and expect them to expire a few weeks after. Reducing operational costs. They also don't have to develop and maintain an anti-cheat, a better server-side structure, and they can close down most servers.

I think it was a unexpected consequence of a bad console port to pc that proved to be quite lucrative. And now they know people will keep buying no matter what, hence the new disposable pc game business model.

Basically, if you play on a PC you're screwed. Another reason not to buy a console or support games like the division on the pc.

Post reply on HN