Firefly framework reference

On the game server side, you often need to deal with a large number of various tasks, and the system resources required for each task may be different. However, it is difficult to support and manage these complex tasks with only one server process. Therefore, game server developers often need to spend a lot of time and energy on division of server types, distribution of processes, maintenance of these processes, and inter-process communication, request Routing and so on. Firefly can completely complete these repetitive and tedious tasks, freeing upper-layer game developers and putting more energy on the Implementation of game logic.
I. Firefly features
1. The single-thread multi-process architecture supports a custom distributed architecture.
2. Convenient server Expansion Mechanism to quickly expand the server type and quantity
3. Use TCP persistent connection with the client, so you do not need to consider sticking packets.
Ii. Firefly ideas
A basic Server is an application that keeps running. In distributed game servers, the required servers have the following functions: Listening to client connections, listening to messages from other service processes, and connecting to other service processes, some require database connection and cache services.




Net Connect is used for client connection. Root listens to messages from other service processes, and node connects to other service processes, DB databases, and cache. Whether to listen to client connections, whether to listen to messages from other service processes, etc. This can be configured in config. JSON. Including the name of each server and the connection relationship between each server. In this way, you can customize your own distributed architecture.
Iii. Firefly Structure
In terms of function responsibilities, the firefly framework structure is shown in:




1. Management, Firefly is a multi-process, distributed game server. Therefore, the management and expansion of various game servers (processes) is an important part of Firefly, and the framework makes server expansion very easy through abstraction.
2. Network, client connection and server process communication constitute the context of the entire game framework. All game processes are built on this context. Communication with the client uses a request/response type. The server will respond to all received client requests, and the server can actively push and broadcast messages to the client. These requests are based on command numbers. (For example, 101 is the LOGIN Command) asynchronous callback is used for communication between processes on the server. This reduces the time consumption in network communication between processes.
3. Data Processing is an important part of online games. A large amount of data needs to be stored and updated during online games, which makes the read/write efficiency of the database the biggest performance bottleneck of the server. Firefly's dB processing can cache data in database tables to memcache and call corresponding object methods to operate data in the form of objects. You can instantiate a cache instance with the same name in different processes to obtain the synchronized data. It can also write the data in the cached object back to the database.

Iv. Firefly Process

1. Read configuration data from config. JSON
2. Start the corresponding service process based on the server architecture defined in the configuration. And establish connections between nodes. If a database is configured, the database connection pool is instantiated. If memcached is configured, create a memcached connection.
3. Configure the corresponding process startup entry module.