Ok, lets put this in perspective:
You write the server software.
The hacker writes the client software.
Make sure he can''t cheat.

You need a central server to maintain and authenticate the state of the game, but I think you may be able let updates propagate via a peer-system. It would be important that such a system had good failure detection and was able to establish alternative routes quickly, with a default back to the main server always available.

What would instantly be nice about such a system, is that you could have master-server replicas in different RL geographical areas that are peer-updated from The One True Master - very similar to NDS (Novell Directory Services).

All the The One True Server must do is store state information, to prevent binary hacking of the data files (which is far too easy, even with encryption, think DVD). All the clients that connect directly to the TOTS are verify that they are reasonable, and the client is kicked, killed, or klined if not. The reasonably successful approach EQ has taken, is not to prevent cheats; but to detect them, and suspend or eradicate offending accounts.*
In order for the peer-distributed, server traffic-cop model to work, you have to trust the information sent by the peers; but we know we can’t trust them – or rather, we can’t trust all of them. For now, we shall assume that we can trust the majority of them. So everything is sent and calculated twice, or even thrice or more, across the peer-network. Every client is also a server, capable of validating player actions like The One True Server.
Your PC is not responsible for delivering authoritative information about your actions to the peer-network – you will send information packets to other clients in the surrounding game region so they may update with less latency. TOTS tells your PC which other client(s) to establish a connection for validation of the authoritative packets, and it changes the validation PCs at-random. The validation PCs propagate your updates up to TOTS after they validate them, and report any discrepancies directly to TOTS. To prevent hacked abuse of the kkk (that’s kick, kill, kline) regulation, before a player is instantly kkk’ed another random client (or two) must also report discrepancies. Long-term statistics are stored to catch the impulse cheater – and the hacked kkk’er, indexed by IP node, installation GUID, and player ID. The assumption is, the majority of the players don’t cheat.

We cannot allow circular validation (even though it would be more efficient), because then we cannot enforce the rule that you never relay your own authoritative packets up the peer-network to TOTS. For this reason, it’s important that the authoritative connections form a tree with no cyclic links. Validation PCs are only allowed to be higher (towards TOTS) than you are, and if you’re at the top, then you validate to TOTS (or one of his replicas, which is close enough). There will be a separate set of peer-connections for rapid informational updating to peers in the game vicinity; these node connections can be further optimized by IP locality and latency**. The authoritative ones must be random (subject to the restrictions above).

Someone could still defeat the system by hacking the validation code of the client, and sending a message between the all the validation nodes to detect that all your validation PCs are hacked clients (perhaps on a separate UDP/TCP port from a separate process). If all the validating PCs are hacked as well as the users, they can freely cheat – until the TOTS randomly switches their validation PC(s) to a non-cheater at least. Still, with enough infected nodes, you could take over the network, and/or cause false kkk hack detections of clients that are in-fact valid! Again, this is why long-term statistics are important. We need to keep statistics on who supposedly detected the discrepancy, and who supposedly caused it. We need to verify the sender as well, to prevent kkk hack spoofing.

The next check, is to have each group of peers, its validation PCs maintain a short circular buffer of original peer’s actions and results. At any time, TOTS can request that buffer be sent to it from those sources – and they had all better synchronize. With a lossy UDP based system you need to allow for holes, but all updates shall be time-stamped, so while the buffer may not all be perfect replicas, they should contain identical redundant information. This check would be triggered by a peer discrepancy detection.



* True, some “cheats” still exist in the form of mappers and spawn-locators. The effects of which can be minimized by building that capability into the game (like AC or AO), or don’t use such a special-spawn-centric game that EQ does (some EQ classes have tracking ability too, so while the mappers are an advantage, it’s generally not huge since NPCs are generally visible anyway.) The biggest problem is in-game exploits, taking advantage of bugs and unintended circumstances.

**For information packets, we can detect machine on the same subnet or LAN, and only send peer updates once across that connection, then let the local machine relay the data on the faster LAN or MAN(e.g. cable network).

I hate to play the role of the nay-sayer because predominantly my perspective is that one can accomplish anything if they set their mind to it, spend enough time, and make enough sacrifices.

Magmai Kai Holmlor:
Your system has potential and you acknowledge that there are some assumptions being made for peer validation. I would like to present some counter point as to why this implementation may make the game "harder" to hack, but is still not as secure as a client/server model.

Firstly, in a peer-to-peer model the bandwidth requirements are actually greater per client. Instead of just communicating with one other machine on the network, like client/server. Any action a client takes must be sent (as a general rule) to all the other peers in the peer-to-peer session. So say your client initiates attack on a monster in the game, he must send that attack initiation packet to all the other peers. So say there are 20 clients in the peer-to-peer session, the bandwidth requirements are 20x more then just sending that packet to a server and having the server re-broadcast it to other clients.

This limits the size of your peer to peer sessions to about 20-25 (Table 4-1 in "Networked Virtual Environments") members (if you want to support dialup) There may be other ways to group these peer to peer groups. But typically you''d group them according to proximity in the game world. In this circumstance it''s very likely that a group of 10-20 players could go out in the middle of a desert or some other place with low player density and be in control of an entire peer to peer session. In this case they could bypass validation. Even if your server checks binaries, clients could fake the response. Also checking binaries doesn''t stop clients from hacking code execution in memory to skip the validation code.

There are solutions... I thought of a few, like the server would randomly join various peer-to-peer sessions and become the validation for that session. But this isn''t really a solution, because clients need to synch up with the peer to peer group when they join; it would be pretty easy to detect when the server was entering and leaving your session. Also, the purpose of using a peer-to-peer model was to avoid the server having to participate in the gamestate, if it''s roving around joining peer to peer sessions, the game might as well have been client server to begin with.

In traditional MMORPG''s the server actually does alot of calculations, it decides which packets need to be sent to which clients. It also validates all the client actions to see if they fall in a reasonable scope. It is also responsible for collision detection. For instance if there was a locked door and a client was trying to move through it, if the client was responsible for the lock or the collision detection on the door, then it could be hacked and the locked door wouldn''t be useful. Thus the server must validate the locked door, and even if a client says it''s moved through the door, if it was locked the server must move the client back to the last known valid position. The server does alot of work.

We could continue this process for quite some time. People could suggest more and more elaborate plans on how to make something secure that can never truly be secured. I can continue to point out flaws with these plans. Someone might even come up with one that I would have a hard time figuring out how to hack. The point is, after all these elaborate security mechanisms are in place, your still not really going to be secure. Even if you were able to implement some elaborate security measure that was almost as secure as the client server model... you''d still have to implement it. Why not just start with a simple well understood architecture that has some inherent security built in?

Securing a client server architecture is no easy thing to do either. One must religiously follow the golden rule of client server security. Trust nothing that comes from a client, and never trust the client with any critical information.

For example, in UO, there was hiding skill that made players be invisible while they were standing still. Unfortunately the server still sent the player data to the clients if a hidden player was somewhere on the screen, it just set a little bit flag so that the client wouldn''t draw the player. Hackers soon found out this little slip up (trusting the client not to render hidden players) and ran a hack that would make all players visible. All of a sudden the hiding skill was useless because players could see hidden players if they were using the hack.

That just one example of a small slip up in a client server model that almost seriously destabilized the game. Just think of how hard it will be to secure games when you have to trust the interactions between un-trusted clients?

Basically collision detection is done on both the client and the server, but the server has the final say. The client won’t let you run through walls if your seriously lagged from the server (typically). This is because the client is programmed to respond in a reasonable fashion to simulate a continuous stream of data from the server, even though it might only be receiving data every other second. The client is responsible for rendering this data in a continuous way that makes sense to the player. Thus a wall in the game world cannot be walked through.

However you could write a hack that would move your position in the world forward 5 paces instantly. You could walk up to a wall and run the hack, and boom you''d be on the other side of the wall.. the client would likely render the environment there for a second. However, when this movement packet reached the server the server would check and see if that was a valid move, realize it wasn''t, and move you back to the other side of the wall. If it doesn''t, then the server has violated one of the primary laws of the client server model. Trusting the client with data. I know AC does all their physics server side, they had a very accurate physics system early on, but they had to ease off and make a more general (read: less realistic) so that their servers could scale to handle more players.

What about movement of the mobs? (the monsters) It would seem that they would have to do some collision detection on the server for the monsters as well but thats a lot of collision checks as some zones in EQ have well over 400 monsters.


-=[ Megahertz ]=-