Liberi Developer Guide: Network Architecture
From EQUIS Lab Wiki
Contents |
Overview
The Liberi network architecture was designed for scalable multiplayer scenarios, with dynamic server instancing. Liberi could be run for a single player, but setting up and running all the different components of the network for a single player can be quite a hassle. Developing a single-player client could be a worthwhile future project.
The following diagram summarizes the network architecture:
World Server
At the very center of the network is the world server, to which every other peer connects. Among its many tasks are:
- Storing persistent data
- Authenticating players
- Tracking peers
- Processing player search requests
- Processing server search and spawn requests
- Processing player and world data requests
Because the world server contains all the persistent data of a Liberi game world (including player profiles, map settings, store prices, etc.), it can be thought of as the embodiment of the game world.
During the course of a multiplayer field trial, the world server is left running continuously. It has very low memory and CPU usage.
World IDs
World servers are not identified by their IP addresses, but rather by a unique name. After setting up a world server on a machine, you can create a file with the desired name for the world (e.g., liberi_test_world, liberi_ccs_spring_2014), put the IP and the port of the world server inside of it, then put the file under the public_html/servers folder on the EQUIS website (Ask your supervisor for FTP access). Your world server will now be accessible from all Liberi peers by the name you designated. This makes it easy for human beings to configure peers, and to quickly discern which world server is being used. Also, it means you can move the world server to a different machine without having to reconfigure all the peers.
Alternatively, it is possible to use an exact IP Address as a WorldID, or the keyword localhost (which is simply an alias for 127.0.0.1).
Server Pool
Server pools are responsible for spawning and managing a group (or "pool") of server instances. Servers spawned by a server pool run on the same machine as the server pool. Server pools that connect to the same world server can be run on different machines, effectively dividing the workload.
When a server instance is requested, the server pool with the least number of servers spawned is chosen to spawn the requested server. Improvements can be made to this load-balancing algorithm, such as taking into consideration CPU load and network traffic.
Server limits can be specified per server pool. For example, you can designate one server pool to be solely responsible for spawning all your player towns, while designating three other pools to be available for spawning minigame instances, with a cap of 12 players each. Each server pool can also specify any number of initial server instances to spawn. For example, you can make your town server pool always start off with three town instances spawned, without waiting to be explicitly requested to do so. These can all be edited in each server pool's ServerServerPool.ini file.
Server pools are also the only optional component of the Liberi network architecture. If there are no server pools running, servers can still be started manually - they just can't be spawned dynamically. Servers started manually without a pool are called "unpooled" servers, and are not considered in load-balancing, but are otherwise compatible with all other features, like server searches.
Server
Servers are instanced hosts of multiplayer game spaces. All peers connected to a server will be synchronized in a little "sub-network", or a "session network". While the world server is the authority on everything persistent (long-term) in the game world, servers are the authorities within their own little sub-network on everyting that happens in realtime (short-term).
Each server that is started with a specific "map". These can be zones (e.g. sunny_town) or minigames (e.g. gekku_race, biri_brawl). Once a server starts, it immediately registers itself with the world server, effectively making it "visible" to all other peers in the game world. The server also reports which server pool spawned it, if any. This information is used for load-balancing.
Client
Clients are player machines. When a client starts up, it logs in to the world server. Then, it proceeds to ask the world server for available zone servers to join. As of today, clients by default look for any available town server to join upon first logging in. Once in the town, the client send minigame server search requests to the world server.
Each client identifies itself to the world using a "player ID". These will be used to load up the appropriate player profile on the world server, which is then made available to the player and to servers for use in affecting game logic and presentation (e.g., player abilities, inventories, costumes, etc.).
