Online Game Server Structure Design

Loginserver <-----> gameserver
Server subjects are divided into loginserver and gameserver. loginserver performs account authentication and gameserver implements the game master logic,
You can also add a charserver in the middle to manage the characters, create and delete characters, or go to gameserver 1.
Loginserver and charserver are relatively simple, skipped.
After being verified by loginserver, A sessionid is assigned to the client and then communicates with gameserver or charserver,
All use this sessionid as the authentication code. The client can establish a connection with gameserver only by sending the correct sessionid.

2. gameserver hierarchy
Gameserver is divided into three layers, the network layer <---> logic processing layer <---> database layer
Each layer has a message processing queue that stores the messages to be processed. The message queue can either be in the first-in-first-out queue or
The heap or priority queue method is used to sort and process messages by priority. Hey, is it a bit similar to QoS?
Idea.
Each layer uses the thread pool technology to create a certain number of Idle threads in advance. When not enough, a new thread is created. when too many threads are used, the thread is destroyed,
Ensure that there are a specified number of Idle threads (min/max) in the thread pool. The main thread constantly checks whether the queue is waiting to process messages. If
If yes, an idle thread is allocated from the thread pool for processing.
In Linux, the thread pool is implemented using pthread_cond_wait and pthread_cond_signal.

2. 1. Network Layer
This layer can be implemented based on different operating systems. The main function is to establish a TCP connection with the client and divide the TCP stream into packets,
Decrypt the data if encrypted, decompress the data if compressed, add the data to the processing queue at the Transaction layer, and send the messages to be sent in the processing queue.
If you want to encrypt it, it will be encrypted. If you want to compress it, it will be compressed.
The iocp model is used in windows, and select/poll (epoll)/kqueue can be used in Unix-like systems.
Even though the select method is adopted on the server, the number of connections on a single port in Linux is limited. Therefore, multiple threads are occasionally enabled to listen to a group of ports,
Loginserver performs load balancing to ensure that there is no excessive number of connections on a port. When a new client is logged on,
Loginserver determines the number of connections on each port and selects the minimum number to be sent to the client. It can also be used as a dynamic method,
When the average number of connections on each port exceeds XXXX, a new thread is enabled to listen to the new port and notify loginserver.

2. Logic Processing Layer
This layer is the core of gameserver.
Distribute messages to each sub-module based on the opcode. The simplest method is to use the continuous opcode from 0 to create
An array of processing functions corresponding to opcode. opcode is used as the subscript of the array, so that only the time of O (1) can be called to the required function.
Even Hash is saved, simple and efficient.
For more information about sub-modules, see section 7th.

2. 3. Database Layer
This layer is used for data storage. In essence, the data in the memory is stored on the hard disk. If you have enough data, you do not need to use the existing database,
You can write algorithms to store text files by yourself. However, it is better to use databases to improve efficiency for convenience.
Use MSSQL in Windows or MySQL,
The Unix-like system can be used more, and it is best to be compatible with several databases.
MySQL has excellent performance and slightly inferior functions. If you do not need to use stored procedures, MySQL is the first choice.
The database layer is generally enough to use a single thread, so it does not need to be mutually exclusive. programming is a little simpler, but it should be noted that,
Database Operations must use transaction to effectively prevent replication. For example, if an error occurs during a transaction
Before the transaction, rollback won't happen if the money has been handed over, but the thing has not been obtained.

3. Message format definition
3. 1. network layer <--> logic layer Message format (network packet format)
3. 2. logic layer <--> database layer Message format

4. Game object definition)
Object
| -------> Item
| ----> Container (container objects, such as warehouses and backpacks)
|
| -------> Unit
| -----> Player
| -----> Monster
| -----> NPC
| -----> Corpse (corpse object)
|
| -------> Gameobj
| -----> Dynamicobj (for example, a temporary object generated by a skill)

5. Map Scenario Management
6. Script System
7. logic layer modular design

 

This method is intended for map Scenario Management.
On the server, the scenario is divided into small areas (field of view size ). Each region corresponds to a list, and all objects in the scenario are added to the list of the corresponding region according to their location. Therefore, each walk only needs to send messages to several adjacent regions of the player.

One suggestion:
The gameserver network layer can be stripped out to form an application-level gateway, because this part consumes a large amount of resources despite its simple logic. Making a separate one can make your system more scalable. gameserver and gate can be 1: N.

There are many issues to consider for a distributed server architecture:
First, we must have a well-designed Application Server framework and communication middleware. The application server is an important infrastructure for upper-layer applications, communication middleware is used to implement functions such as service locating, name registration, load balancing, service clusters, failover, time service, and log service, if socket communication is manually written between servers, you will soon be troubled by protocol processing, various subtle timing, synchronization, and other issues. It can be said that your server architecture can achieve high complexity and stack height. The key lies in how robust and durable these two implementations are.
Second, object state serialization is very important, which is related to object synchronization, object persistent, State migration, fault recovery, and many other issues. The problem is far from being as simple as writing the object state to a stream. Doing this is equivalent to solving half of the server logic problems.
Then let's talk about the distribution. There are basically two ideas: one is to divide computing resources by logical function, and the other is to divide computing resources by capacity. Dividing by logical functions is easy to think of. Simply put, different functional modules are implemented in different processes. This solution seems good, but there are many problems. First, interaction between modules is inevitable, which will lead to a lot of fine-grained Remote Process Communication, resulting in performance loss. Second, the implementation difficulty is increased. Second, the load of each module is not balanced, it is easy to produce performance bottlenecks, and it is difficult to achieve load balancing. In addition, such server program tuning will be a nightmare. Of course, everything is not absolute. All designs must be determined based on the actual situation. Sometimes the division by function is still based on the function, for example, it is highly recommended that you divide an application-level gateway to be effective in some cases. The basic idea of the existing distributed implementation of super-large seamless connection to the world is to divide the world into a series of connected blocks, allocate computing resources to each block for parallel distribution. The key issue lies in the synchronization between adjacent block boundaries. If not, synchronization imbalance, item replication, and other bugs may occur. This requires a well-designed synchronization algorithm. We can also have two options for allocating computing resources. One is to use a strong multi-CPU server and use multi-thread parallel computing in a single process, the so-called SMP architecture, this advantage is simple and efficient. The disadvantage is that the cost is high and the scalability is not high. The other is the server cluster architecture, which is more complicated to implement, and the bottleneck of the server is mostly in I/O rather than computing. After using the cluster, the communication between servers is increased, poor design results in performance loss, but it also has obvious advantages, reducing costs and improving scalability, good design can also achieve fault recovery (that is, any server in the cluster will not affect the running of the game ).
Finally, let's talk about the processing of game logic. One design is to make the server passive, and then perform logic processing and refresh the object State only when the customer requests arrive, which can reduce some computing workload, however, because the server does not simulate the object state and lacks necessary information, it will limit the implementation of some functions (especially the true 3D World Movement. I am now more inclined to traditional game practices, so that the server can run a logical loop of the game and regularly simulate the object status.