Firefly Frame Reference
Game servers almost always need to handle with numerous varieties of tasks, and system resources required of each task may be different. These complex tasks are difficult to be supported and managed by using standalone server, therefore the game server developers often are obliged to cost a significant amount of time and effort on underlying problems such as server type distinction, processes’ number allocation, maintenance, inter-communication as well as requested routing. However, Firefly is a sufficient tool to cope with all these repetitive and tedious work, it could set game developers free and let them spend more time on game logic realization.
1. Single-threaded multi-process architecture with customized distributed architecture support.
2. Convenient server extension mechanism that can promptly extend server type and quantity.
3. Persistent TCP connections to clients with no need to concern issues like stick pack.
A basic server is a continually running application, and the features we need for a distributed game server include monitoring client connections and other service processes’ message as well as connecting these service processes, and sometimes database connections and caching services is also needed. It’s shown below:
Net connect works as client connection, root monitors other server processes’ message, and node connects other server processes, databases and caches. Whether or not monitoring client connections and other service processes’ message as well as modifying each server’s name and their connection relationship are all can be configured in config.json, thereby, developers could get their own customized distributed architectures.
Firefly frame structure’s functions and responsibilities view:
-
Management: firefly is multi-process distributed game server, and therefore management and extension of all game servers is a crucial part of Firefly, and extending servers will be very easy through framework.
-
Network: game framework’s context is constituted by client connections communications, server inter-process communication and etc. and all game flow is based on this context. Server-side’s communication with clients adopts request-reply mode, it will give corresponding response for all client’s request it’s received that based on directive number (such as defining 101 as login directive), it also active push and broadcast information to client. For reducing the time cost of inter-process communication through networks, inter-server communication adopts asynchronous callback mode.
-
Data: data processing is a significant part of online game in which mass data needs to be stored and updated, thus the database’s read-write rate becomes the biggest performance bottleneck of server. Firefly's db processing is able to cache the dada from data table to memcache, operate data by calling corresponding object method as object, obtain synchronous data by instantiating cache instances with same name in different process and write the cache object's data back to database.
1. Reading configuration data from config.json.
2. Launching corresponding service process on the basis of server-side architecture that defined in configuration, and then establishing connections between nodes. Instantiating database connection pool when it has configured database, establishing memchached connection when it has configured memcached.
3. Starting corresponding entry module according to configured process.