[Stevvo]

Whilst an issue like this can occur with any network architecture, going with Peer-to-peer looks like a terrible decision. 'Never trust the client' and all that. The in-game money cost real money, but the client is trusted so anyone can edit their balance in memory as the game is running. Ridiculous.

[kevincox]

It's always a balance between performance and security.

Yes, it is better to have the server parse, validate and reserialize messages from other players to add another layer of defense in front of the client. But the client shouldn't be trusting the server anyways so going peer-to-peer shouldn't be an issue. The fact is that server pricing isn't going to catch everything anyways.

Probably the biggest problem with P2P these days is that it shares your IP which can be used for tracking or DoS attacks.

[mlyle]

> But the client shouldn't be trusting the server anyways so going peer-to-peer shouldn't be an issue.

If there's things like durable money between matches, etc: without someone in the loop to validate what happened you can't really solve this problem peer to peer. (If we define security to encompass "secure game state" and not just "safety from remote code execution")

[kevincox]

This is usually done by logging state to the server which does some validation.

Most validation that the server does can be run on clients just as easily. (The main issue is what information is visible to clients. But if you are doing mostly P2P you usually end up making tradeoff that the client gets most information)