|
When developing multi-user applications, it’s often useful or even necessary to push some logic to the server rather than the client. There are many good reasons for doing this but here are a few of the most important:
| • | Security – The server is significantly more secure than the client. |
| • | Performance – In most cases, the server will provide much higher performance than the client. |
| • | Manageability – Maintaining code deployed on the server is simpler than maintaining code deployed on many clients. |
| • | Resolving Conflicts – Making important decisions in one central location allows the clients to agree. |
| • | Maintaining State – Keeping track of the application state ensures that new users entering can properly view the state. |
With all these reasons, it seems that most logic should be pushed to the server, but this isn’t the case at all. If you push everything to the server, then it will need to do that same work for each client. Ultimately, while the server might be faster for a few calls, it will get bogged down with many hundreds of thousands of calls. Because of this, it’s critical to know what should and should not be done on the server.
Fortunately, there are some rules of thumb on what should be handled by the server that can be used to make this decision easier:
| • | Anything that affects the game state directly |
| • | Anything that is critical to game-play |
| • | Any area of an application where clients might disagree on the outcome of an action |
| • | Any area of an application where there are concerns for security |
Below are a few examples what should be handled on the server:
| • | In an RPG, determining if the player was hit by the monster and calculating how much damage and remaining health is left to the player |
| • | Picking up an object in the world if the object is important to other players |
| • | Any place where cheating could be done by changing strength, angle, speed or any other variable in the client |
|