diff options
Diffstat (limited to 'docs')
| -rw-r--r-- | docs/ServerData.txt | 17 | ||||
| -rw-r--r-- | docs/architecture.txt | 222 | ||||
| -rw-r--r-- | docs/messages.txt | 105 | ||||
| -rw-r--r-- | docs/server.txt | 172 |
4 files changed, 0 insertions, 516 deletions
diff --git a/docs/ServerData.txt b/docs/ServerData.txt deleted file mode 100644 index 2074835c..00000000 --- a/docs/ServerData.txt +++ /dev/null @@ -1,17 +0,0 @@ -As per Elven's request, I'm making this document to contain the information relevant to -server development as far as my understanding goes. This file contains the following: - - Information that will be stored in Player Account - - - -1. Information stored in a Player Account - - Inventory - an array of 110 item IDs (the last 10 slots or so are current equipment) - - Position - the place where the player is in worldspace (3 ints, x, y, map) - - Estate - stored as an array of Tiled maps, the same way any map is. - - Skills - an array of 100 Skill structures - - Quest Info - an array of X short integers, specifying the player's position - in or accomplishment of the game quests. (X is the number of quests) - - Pet Status - pets are stored as an array of skills and some general information - (age, type of monster, loyalty, equipment, etc.) You can have up to - 3 pets at once. - diff --git a/docs/architecture.txt b/docs/architecture.txt deleted file mode 100644 index 7cd54d53..00000000 --- a/docs/architecture.txt +++ /dev/null @@ -1,222 +0,0 @@ -------------------- -SERVER ARCHITECTURE -------------------- - -1. INTRODUCTION -2. RO REVIEW -3. EATHENA MODEL -4. TMW SERVER -5. TCP - UDP -6. SECURITY -7. DATABASE -8. REGISTRATION -9. SERVER CONTROL -10. OPERATING SYSTEM -11. ADVANCED DATA TRANSMISSION - - -1. INTRODUCTION - -One of the most important thing in a online game is the architecture of the -server system, which reflects in performances (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 features. - - -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.net) -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. Having -only one server (L) to manage all the connections between clients and map -servers is a bad point: if the login server crashes players won't be able to -play anymore. In fact new connecting players won't be able to connect to login -server, while map server will disconnect every player, since they can't save -their infos. -The solutions are: - - - implementing a distributed login server which can manage crashes and - redirect new connections to another login server. This way means a more - complex implementation and probably the need to other computers since we - want the login servers to be independent from each other crashes at all. - (Remember this is a free project so we should limit the number of - computers to act as servers) - - - RALS (Redundant Array of Login Servers): we can have two login servers, - only one of them is active at a time and they share the same database - where to store infos about players. If one of the map servers loose the - connection with the login server enables the other, while the crashed one - restarts. Even if it restarted is it now considered disabled. The new - active login server will send messages to every map server to inform them. - Every time a client connects check both of the login server and connect to - the active one. The bad points of this system are that will imply a lot of - data consistency checks: map servers should resend last data since it - was lost when the login server crashed, the new login server should check - if some of the data was already stored before the crash, what if both of - them crash? - - - waiting it's the only solution! Let's design the login server as much - simple and stable as possible and create a smart restarting system. - This way we will have less frequent crashes and a very low restarting - time. Obiouvlsy this is the easiest and less expensive solution. - - -5. Network protocol: TCP - -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 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, but having a reliable protocol such as TCP -will make things easier and more stable. We just need to design an efficient -prediction system (probably also a linear one will suffice). - -An idea could be using the system I used for a racing game where speed was -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 and the difference of client times -the server check if the coordinates sent by the client are right, if not reply -with a packet with the correct position. The server also check if the time -interval sent by the client is right: if not it means that the values have been -hacked or the lag corrupted them. We can set a tolerance value: if the time -interval exceeds the tolerance then the whole movement is discarded and the -server send a packet to tell the client to place the player at starting coords. - - -6. SECURITY - -To certificate authenticity of the player we can use a system based on digital -signature and hash (encrypted login). - -Better security can be provided by encrypting payload of packets using RSA -algorytm. When logging in the client generates both its public and private key -and will send the public one to the server. The server acts the same: when it -starts it creates both the key and replies to login with its public key. -Using encryption will reduce client/server performances because this will need -a lot more calculations. -Furthermore if using digital signature will introduce a lot of overhead. -So there's still the need to discuss if we need to use encryption not only in -the login part. - -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. - -Also we need the possibility to warn/kick/ban players/accounts/ip addresses. - - -7. DATABASE - -Player data should be stored using databases, probably MySQL. This way player -infos could be easily accessed trough web and used to show stats or required -infos on the website/forum. - - -8. REGISTRATION - -Still to decide if we want to use a dialog (client registration) or to use a -web based interface (web registration). -Registration should ask for less details as possible. This way it will be less -annoying. Required infos will be: - - - username - - password - - email (to limit account number and to be used to activate account) - -More infos could be added later for security problem (such as activation codes -and so on). -In RO you also have to choose the sex of your player. It will be better to let -the user choose the sex when creating the player: this way he can delete is male -player and create a female one. - - -9. SERVER CONTROL - -The server can be controlled in two ways: - - - In game control: server admins or GMs sending particular commands or a - trough a GUI (the way it is used in Ultima Online). - - - A graphical interface which connects to the server trough an open port. - -The prefferred way is the first one. - - -10. OPERATING SYSTEM - -We have two choices about this: the former is to follow as for the client the -cross-compatibility philosophy. This means that the server will compile on every -windows, unix, macos based system. The latter is to choose the best performance -system (probably linux) and implement a unique os server. -Just remember that the current game server run on linux. - - -11. ADVANCED DATA TRANSMISSION - -Other ways to reduce bandwidth can be considered such as: - - - Using bitstreams instead of bytestreams: this way if you need to send a - boolean values only 1 bit will be required instead of 1 byte (compression - 8:1), item types (4 different types) can be represented sending 2 bits - instead of 1 byte (compression 8:2), player coordinates can be represented - using 20 bits instead of 4 bytes (compression 24:20) - - - Compressing data following packet id could help reducing bandwidth usage - as well. RLE compression or more advanced statistical techniques can be - used. Compression can be disabled in very slow systems (If using - compression is declared to the server when the client connects to map - server.
\ No newline at end of file diff --git a/docs/messages.txt b/docs/messages.txt deleted file mode 100644 index dddda233..00000000 --- a/docs/messages.txt +++ /dev/null @@ -1,105 +0,0 @@ -------------------------- -MESSAGE PASSING MECHANISM -------------------------- - -1. INTRODUCTION -2. MESSAGE -3. ROUTING -4. SERIALIZING PRIMITIVES -5. SERIALIZING CUSTOM DATA TYPES - - -1. INTRODUCTION - -In server.txt we describe the datatypes involved at both client and server, and -the related messages that are passed from client to server and back. In this -file we will describe how the actual messages are composed and how they are -routed from where they come from to where they are taken care of. - - PLEASE NOTE: Everything in this file is open for discussion. This file is - meant to get ideas acros, find flaws in the reasoning and generally get - comments on the system before somebody sets out to implement it. - - -2. MESSAGE - -The protocol is described in terms of messages. Each message has a certain -type, a length, and a certain number of values in primitive data types: - - { C msgId, S length, ... } - -The length stores the length of the remaining data. We need this so that the -message can be cut off from the incoming stream of bytes and be encapsulated -on its own to be further processed. - -The primitive data types are the same as those described in server.txt. The -first thing that is done to the incoming message in to put it in an instance -of the Message class. Below we outline the Message interface: - - class Message - { - public: - Message(int length, void* data); - ~Message(); - - int getChar(); - int getShort(); - int getLong(); - std::string getString(); - - private: - int length, readPointer; - void* data; - } - - -3. ROUTING - -After the Message instance has been constructed, it is routed to the message -handler that has registered itself to handle this message type. If no handler -has been registered a warning should probably be issued. A message handler -implements the following interface: - - class MessageHandler - { - public: - void receiveMessage(int msgId, Message *msg) = 0; - } - -A mapping is made from message types to message handlers. One handler could -be registered to handle a group of message types. This mapping can be stored -in a std::map as follows: - - std::map<int, MessageHandler*> messageHandlers; - -This will be a member of the class that processes the incoming byte stream, -which will implement an interface to allow registration of message handlers, -for example: - - void registerHandler(int msgId, MessageHandler *handler); - - -4. SERIALIZING PRIMITIVES - -Here we will describe for each primitive data type how it is serialized in -bytes. - - char: 1 byte (direct copy) - short: 2 bytes (now need to keep in mind endian order) - long: 4 bytes (see short) - string: 2 bytes for length (short) + X bytes (characters) - - -5. SERIALIZING CUSTOM DATA TYPES - -Custom data types will be serialized using a composition of the primitive data -types, or other custom data types. They will need to implement the following -interface: - - class Serializable - { - public: - void serialize(Message *msg); - static Serializable *unserialize(Message *msg); - } - diff --git a/docs/server.txt b/docs/server.txt deleted file mode 100644 index e2d506af..00000000 --- a/docs/server.txt +++ /dev/null @@ -1,172 +0,0 @@ ------------------------------ -THE MANA WORLD SERVER PROJECT ------------------------------ - -1. INTRODUCTION -2. MAP -3. OBJECT -4. BEING -5. ITEM -6. CHAT -7. AUTHENTICATION - - -1. INTRODUCTION - -First let me show you a screen shot of TMW. From left to right it shows a -player, an enemy, a tree and an apple. In this document the player and enemy -will go as beings, and the tree and apple will go as objects. Finally, the -thing they're on is a map. - - o O - O : A Player <> : A monster | : A tree o : An Apple. - - ----------------- Fig. 1) screen shot of TMW showing three kind of objects - | | - | o O | MAP - | O <> |o | OBJECT - | | BEING - ----------------- - -Each of these types has its own set of properties and things it can do in the -game. A number of messages in the protocol can be grouped on these types. We'll -go through each of them separately. Objects can be picked up and change into -items, we'll mention those too. - -The effects of using objects or items, talking to beings and attacking enemies -are all calculated server side. It is interesting to think about approaches -that allow a scripting language to be used in these areas. - -In the messages described the following data types are being used: - - A - char array (null terminated) - C - char (1 byte) - S - short (2 bytes) - L - long (4 bytes) - - -2. MAP - -- Stored as XML file (.tmx) -- Refers to tile set images and potentially to music file(s) and objects -- Beings can change from one map to another (probably using warp and spawn - points) - - -3. OBJECT - -- Most properties specified in XML file -- Mostly static (at least doesn't move, but can change) -- Has collision properties, which can change -- Can be an item (allowing picking it up) -- Can be animated and change animation (max 256 animations) -- Can potentially be activated/used (door, chest, portal) - - Server to client: - - MSG_NEW_OBJECT { L objectTypeId, L objectId, L x, L y } - MSG_REMOVE_OBJECT { L objectId } - MSG_CHANGE_OBJECT { L objectId, L x, L y, C currAnim, S flags } - - Client to server: - - MSG_PICKUP { L beingId, L objectId } - MSG_USE_OBJECT { L beingId, L objectId } - - -4. BEING - -- Most properties specified in XML file. -- Dynamic (can walk around) -- Character animation, but could still show arbitrary animations. -- Can equip stuff, which could change appearance (max 256 equipment slots) -- Has inventory -- Connects to questing system -- Can fight other beings -- Dispositions: friendly, neutral, enemy -- Can be shop -- Can be talked to, potentially to gain quests -- Controlled either by player or AI, AI could be either server or client side. -- Carries money -- Can be associated with a client - - Server to client: - - MSG_NEW_BEING { L beingTypeId, L beingId, L clientId, L x, L y } - MSG_REMOVE_BEING { L beingId } - MSG_INVENTORY_UPD { L beingId, L itemTypeId, L amount } - MSG_EQUIPMENT_UPD { L beingId, L itemTypeId, C slot } - MSG_ATTACK { L beingId, L targetId, L damage, C damType } - MSG_PATH { L beingId, A path } - - Client to server: - - MSG_TARGET { L beingId, L targetId } - MSG_WALK { L beingId, L x, L y } - MSG_START_TRADE { L beingId, L shopBeingId } - MSG_START_TALK { L beingId, L talkBeingId } - MSG_REQ_TRADE { L beingId, L playerBeingId } - -More messages are needed for the talking with NPCs and trading with shops and -other players. - - -5. ITEM - -- Properties specified in XML file -- Beings can carry them around -- Can be traded between beings -- Can potentially be equipped (in a certain slot) -- Can potentially be used - - Client to server: - - MSG_USE_ITEM { L beingId, L itemTypeId } - MSG_EQUIP { L beingId, L itemTypeId, C slot } - - -6. CHAT - -There are several channels in the chat system: - - Area - To players around you (default) - Region - To players on the same map (default) - Global - To all players in the game (default) - Team - To players in the same team (when in team) - Guild - To players in the same guild (when in guild) - -In addition to these there are also system messages, and announcements made -by moderators / administrators. - - Server to client: - - MSG_CHAT { L beingId, A name, A message, S channel } - MSG_SYSTEM { A message } - MSG_ANNOUNCEMENT { A message } - - Client to server: - - MSG_SAY { L beingId, A message, S channel } - MSG_ANNOUNCE { A message } - - -7. AUTHENTICATION - -Of course before the client can send/receive any of this, he needs to login to -the server. The idea is that the client will send login info to the server, -and that the server either denies the request (giving a reason) or sends the -client a client id. The client later uses the client id to determine which -being(s) are to be controlled. - - Server to client: - - MSG_ACCEPT_GAME { L clientId } // Accepted into the game - MSG_ACCEPT_CREATE { } // Accepted into character creation - MSG_DENY { A reason } - - Client to server: - - MSG_LOGIN { A name, A password } - MSG_CHAR_CREATE { ... } - -The character creation process will need to be thought out. |