summaryrefslogtreecommitdiff
path: root/docs
diff options
context:
space:
mode:
authorEugenio Favalli <elvenprogrammer@gmail.com>2005-02-18 18:45:17 +0000
committerEugenio Favalli <elvenprogrammer@gmail.com>2005-02-18 18:45:17 +0000
commitb814d15b1796e20696659b171182a135ba9efce5 (patch)
tree5be862ef2039580d9e042a0b9afaa003974e6be7 /docs
parentb7d7883ff0f662836b69e132759c78142d1488c4 (diff)
downloadmana-client-b814d15b1796e20696659b171182a135ba9efce5.tar.gz
mana-client-b814d15b1796e20696659b171182a135ba9efce5.tar.bz2
mana-client-b814d15b1796e20696659b171182a135ba9efce5.tar.xz
mana-client-b814d15b1796e20696659b171182a135ba9efce5.zip
Basic server architecture
Diffstat (limited to 'docs')
-rw-r--r--docs/architecture.txt103
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