diff options
author | Eugenio Favalli <elvenprogrammer@gmail.com> | 2005-02-18 18:45:17 +0000 |
---|---|---|
committer | Eugenio Favalli <elvenprogrammer@gmail.com> | 2005-02-18 18:45:17 +0000 |
commit | b814d15b1796e20696659b171182a135ba9efce5 (patch) | |
tree | 5be862ef2039580d9e042a0b9afaa003974e6be7 /docs | |
parent | b7d7883ff0f662836b69e132759c78142d1488c4 (diff) | |
download | mana-b814d15b1796e20696659b171182a135ba9efce5.tar.gz mana-b814d15b1796e20696659b171182a135ba9efce5.tar.bz2 mana-b814d15b1796e20696659b171182a135ba9efce5.tar.xz mana-b814d15b1796e20696659b171182a135ba9efce5.zip |
Basic server architecture
Diffstat (limited to 'docs')
-rw-r--r-- | docs/architecture.txt | 103 |
1 files changed, 103 insertions, 0 deletions
diff --git a/docs/architecture.txt b/docs/architecture.txt new file mode 100644 index 00000000..14e77401 --- /dev/null +++ b/docs/architecture.txt @@ -0,0 +1,103 @@ +------------------- +SERVER ARCHITECTURE +------------------- + +1. INTRODUCTION +2. RO REVIEW +3. EATHENA MODEL +4. TMW SERVER +5. TCP - UDP +6. SECURITY +7. DATABASE +8. REGISTRATION + +1. INTRODUCTION + +One of the most important thing in a online game is the architecture of +the server system, which reflects in permormances (lag and denial of +service), scalability, fault tolerance. In this article we will examine +the pre-existing model and we will evaluate a way to improve it and to +add custom fetures. + +2. RO REVIEW + +Let's start by taking as reference the current server system used to play +Ragnarok Online on the euRO server. (www.euro-ro.com) +RO works by using 4 kinds of server: + + - Login Server (L): takes care of verifying accounts with + username-password system, allows also encrypted login. + - Char Server (C): saves every player status (stats, items, equipment, + skills and so on. + - Map Server (M): the real game server, work as interconnection between + clients, manage chat, monster AI, damage calculations and everything + you can see in game. + - Inter Server (I): probably manages the messages between the other type + of servers. + +In euRO there are 1 login server, 1 char server, 1 inter server and 14 map +servers. + +3. EATHENA MODEL + +The eAthena system mirrors the way used by official RO servers. eAthena +implements 3 servers: login, char and map. It is allowed to have more than one +map server at a time. Every server communicates with all the others. + +4. TMW SERVER + +The basic idea of TMW server architecture mainly is the same as the one used by +eAthena. Since the login and char server don't have heavy traffic they could be +melt togheter. + + C M + \ / + C - L - M + / \ + C M + +The login server manages new connections and stores all the informations about +the player. The map server is pretty the same as the eAthena one. The login +server manages also connections to a new map server when changing map. + +5. TCP - UDP + +RO is TCP based, mainly because you use the mouse to move the player. When you +want to reach a point on the map, you click on it and the client send a packet +to the server with destination coordinates. The server replies with an +agreement if there's a path to that way. Using this way you don't need high +speed nor a lot of packets, so TCP it's pretty enough. +With our custom server we want to achieve pixel movements, by that we mean that +the player is not always positioned in the center of the tile, but will have +fine coordinates. +Asking the server if every destination coordinates is walkable means a lot of +traffic from and to the server and probably will result in lag. Using UDP will +probably help avoiding this problem. +An idea could be using the system used for racing games where speed is +fundamental. When you press a key to move, the client sends a packet with +starting coordinates, direction and client time. When you release the key (or +change direction) the client sends another packet with current coordinates and +client time. According to the player speed the server check if the coordinates +are right, if not reply with a packet with the correct position. + +6. SECURITY + +Solutions to keep the server working and avoid unfair players. + + - DoS attack: + * Account activation. + * Limit number of accounts to 1 per email address. + + - Cheating/Botting: + * First of all just keep every calculation done by the server. + +7. DATABASE + +Player data should be stored using databases, probably MySQL. This way player +infos could be easily accessed trough web. + +8. REGISTRATION + +Still to decide if we want to use a dialog (client registration) or to use a web +based interface (web registration). +
\ No newline at end of file |