Is peer to peer really lacking security for a game?

[Son Of Sparda]

Let's exchange some thoughts on the topic if you want, each time i read topics about mmog or online gaming in general people come with the evidence that "peer to peer is less secure cuz you can hoax".

I believe it's more a matter of lack of knowledge in terms of security rather than an actual issue, it's like people relying on compiled code as a security when pointing out open source... Hem but that's not a hate thread so here is my humble opinion on the topic:

The main argument is that the players will hack the client to allow themeselves to do whatever they want according that there's no server to verify information... well it seems to me that it's the opposite there's plenty of servers to do that in a p2p architecture. So if you split authentication/validation accross the network, in order to exploit the game the client(or clients) validating your inputs would have to also be hacked, which seems unlikely to happen in an "over 100 players" scenario. I have no idea however in the network load involved and no plans about how would the world be splitted accross clients, but while that sounds tricky(therefore totally cool would say the masoshits) to setup the benefits might be incredible, there would be little if any limitations regarding the size of the world as the computational power goes up with the number of users.

Excuse me in advance if poor english, i'd like to have your opinions/ideas on this topic though.

PS:a transaction/banking system called [URL="http://en.wikipedia.org/wiki/Bitcoin"]Bitcoin[/URL] made me change my mind on the topic and come with this idea.

[Catdaemon]

You want an authoritative server for any kind of real-time competitive game, simply because it allows you to centrally decide when shots hit, how much health a person has etc. There might be lag, but you blame your ping not the game's netcode having to hop over 8 people before you.

A few RTS games such as supreme commander pull off the p2p architecture pretty well, but if you've ever actually played that game online you'd appreciate why a dedicated server would be far better - it's laggy as fuck and everyone is bound to the speed of the slowest client.

Your use of bitcoins as an example of a secure p2p system is bad, as that is incredibly computationally expensive and would never work for a real time game. Peer to peer games [i]can[/i] reach this level of security, but at the expensive of lots of time and efficiency. Writing a client->server model is trivial, writing a p2p system of the same speed and security is a long and quite possibly futile job.

[Son Of Sparda]

@Catdaemon

I understand your view but i think it's more about a particular flaw in the implementation of the peer to peer within the game. Like there are several ways to connect computers, "everyone is bound to the speed of the slowest client." is particulary releavant about that, makes me think about token ring(but that's enough comparison since i seem to be bad at picking them :downs:) what i mean is that making all the players involved in the action know everything about the ongoing game and agreeing on every single part of it may be an unnecessary hassle. As we have a lot of computers we might as well use them the best we can. But the lag issue you pointed out is interesting maybe we can make "security rainchecks" delay a verification to later so the ongoing transactions keep going, and maybe lesser the involvment of the laggy one in the architecture. Also the properties of the connections is a variable and we start to see vaporware things for their time become reality: cloud computing, video game streaming, browser play and so on... we can maybe imagine that new game architecture will become available.

Although i acknowledge that while i am talking about that i am mainly thinking of games with quite large number of players and with some fault margin, not a FPS thing.

[ROBO_DONUT]

I don't think it's an issue of security.
The issue is that for you to have any sort of determinism with a P2P archtecture, AFAIK, you'd need to have the entire gamestate synchronized for every peer. Which is why RTS games with P2P architectures completely break when you have one player with a slow internet connection.
The advantage of a client-server architecture is that the server has sole and absolute authority on what is occurring in the game world. You don't have to synchronize with clients/peers or resolve the order in which events have occured. It doesn't matter if there's network congestion or player/packet drops, because the server can operate in complete isolation. It just plows through the computations and updates like an unstoppable freight train, lobs some packets at clients with it's UDP trebuchets, and if they happen to get the packets, great. If not, it's still not a problem because the server is going to be ready to lob another set of updates in about 5ms, and the client isn't going to know the difference.