It's not just about cost. Theoretically yes, you shouldn't send information that you don't want users to get and abuse. However, in the context of games, this is not always possible because most games are realtime and need to tolerate network latency. There is no perfect solution - there will always be tradeoffs.
Ideally player A shouldn't be networked player B if there is a wall between them but what happens when they're at the edge of the wall? You don't want them to pop in so you need some tolerance. But having that tolerance would also allow cheaters to see players through walls near edges. Or your game design might require you to hear sounds on the other side of the wall (footsteps, gunshots, etc.) which allows cheats to infer what what may be behind the wall better than a person would.
> Or your game design might require you to hear sounds on the other side of the wall (footsteps, gunshots, etc.) which allows cheats to infer what what may be behind the wall better than a person would.
Yes, and you cannot prevent this except in in-person tournament.
Any output send toward the player, even a faint audio queue could be analyzed, and use to trigger an action or display an overlay to the screen, and no amount of kernel-level stuff will prevent that, as you can do this outside of the computer running the game.
Ideally player A shouldn't be networked player B if there is a wall between them but what happens when they're at the edge of the wall? You don't want them to pop in so you need some tolerance. But having that tolerance would also allow cheaters to see players through walls near edges. Or your game design might require you to hear sounds on the other side of the wall (footsteps, gunshots, etc.) which allows cheats to infer what what may be behind the wall better than a person would.