Weak interactive mobile game server-side framework Design

Early on, there was an idea to design a stable, efficient, and secure weak interactive mobile network game server-side infrastructure, the first few days to complete a simple preliminary document. The first edition of the design was a reference to some previous experience in the work experience. These experiences have become increasingly vague, but they have benefited a lot from them.

The first draft document is simply a simple record of what is now thought to be more important (perhaps updated), with fewer details involved. Maybe I'll do a little bit in my spare time. The framework described in this article, but the development plan is not expected, after all, energy is limited.

　　

1. Function description

1.1) Weak interactive mobile casual game server-side infrastructure (room-based game units, such as chess games)

1.2) simplified architecture compared to traditional MMORPG server frameworks

2. Frame composition

2.1) Logingate (login Gateway)

Run in the public network environment, used to forward the client and the loginserver between the login interaction and so on. Logingate if attacked, can open a new address (such as in other room) logingate. Of course, you can deploy multiple logingate.

2.2) Loginserver (login server)

Run the network environment, only accept the legitimate logingate connection, itself is also connected to the DBServer, for client login authentication and login status management.

2.3) Gamegate (game gateway)

Running in the public network environment, mainly used to forward the communication between the client and the Gameserver packet, but also can handle such as plug-in, malicious connection, such as the newly connected client if 15 seconds not to send data, or if there is a client at an abnormal speed of the data is directly kicked off or even blacklisted.

Typically, multiple gamegate processes are deployed on the same or different physical machines, and can even be deployed in different rooms.

2.4) Gameserver (game server)

Running in the network environment, the game logic core server, only accept the legitimate gamegate connection, itself is connected to the DBServer, and will send the log information through the UDP protocol to Logserver save.

2.5) DBServer (data server)

Run the network environment, mainly responsible for game data access, login verification (optional) and other logic, only accept loginserver and Gameserver connection.

2.6) Logserver (log server)

Run the in-network environment to hold Gameserver (even DBServer, loginserver, and so on) sent over UDP log messages.

The connections between the servers are shown below.

　　　　

Gameserver, DBServer, Loginserver, and logserver can be placed on the same LAN or even on the same physical machine (if the load is small). The module function divides the frame, each module responsibilities clear, the code structure is clear, for the network attack prevention and alleviates such as gameserver pressure and so on.

3. The client enters the game process

3.1) When the client starts, it initiates an HTTP request to a specified (fixed) address (domain name) to obtain the Logingate address (Ip&port)

3.2) The client connects to Logingate, then enters the account password and submits

3.3) logingate forwarding account password and other information to Loginserver, verified by Loginserver (interacting with DBServer)

3.4) If the validation passes, DBServer prepares the player data, Loginserver returns a gamegate address via the (distributed) load balancing algorithm, and then logingate disconnects and the client's connection

3.5) The client disconnects from the Logingate and connects to the Gamegate

3.6) client connects and enters & starts the game via Gamegate and Gameserver

4. Technology realization

4.1) Development Technology

4.1.1) Golang

In-game background development (at least the core and basic framework), it should be more reasonable to write in a compiled (native) language. Dynamic languages can of course, but they are clearly not their forte (such as code organization, code readability, debugging convenience, deployment complexity, and security and efficiency).

Java and other language technology, of course, but also a lot of resources available, talent is also very much, but it with VMS, deployment trouble, the framework is heavy, relatively not ideal choice.

C + + is too complex (even with only a small subset of it) to have high technical requirements for people (writing robust C + + programs is not easy), and compiling too slowly is not a good choice for small and medium-sized technical teams.

And Delphi, from its quality, the talent is difficult to find and other aspects of consideration, more than the right choice.

As for Rust, which aims to replace C + +, the complexity of the language (which seems to have not yet been formed) and the development of support teams, communities, use cases, and so on, at least in the short term, may look more appropriate.

Native, simple syntax and practical-oriented, standard and tripartite library strong (such as network, etc.), compile quickly, compiler optimization mainstream level (GC improvement has been very large and continuous improvement), cross-platform, said Golang is born back-end development tool is not too.

And already have a lot of web backstage, game back end, KV database and so on (successful) use case.

Typically, Golang can get started quickly, and developers who are familiar with other language technologies will be able to go to Golang quickly.

4.1.2) Lua (optional)

Not only in the game world, business logic is very common in scripting languages (more commonly, Lua, Python, etc.), and the benefits of this approach are:

4.1.2.1) Flexible, business logic changes can be more frequent, and script code modification execution is convenient

4.1.2.2) Division of core and business layers, ordinary developers can not contact the core code, only to get the script interface document to write business logic script

4.1.2.3) script code error, most affect local logic (can escalate script errors to facilitate subsequent resolution of the problem), with a script to make a secure call layer can avoid the entire process crash

4.1.2.4) Hot Update

In conclusion, the combination of Golang + Lua may be an attempt to develop a model.

4.1.3) protobuf (optional)

High-Performance Network Transport protocol format, serialization and deserialization speed even more than JSON, XML, etc., its simple, concise (data description file is very small), independent of the platform, support a variety of programming languages. But in fact, it is not difficult to implement a compact and efficient packet format.

4.1.4) plus Decrypt

PC online games generally use dynamic encryption and decryption mode (write several sets of encryption and decryption algorithm and compile, and then key out each set of encryption and decryption function of the machine code, each time the client on-line, randomly select a set of decryption algorithm sent to the client, and then the client and server communication packets through this algorithm and decryption), but mobile game estimation is not easy

If the packets are small and not dense, we can consider using asymmetric encryption and decryption algorithm to increase the difficulty of packet cracking.

No, should consider tea, AES and other symmetric encryption and decryption algorithm (such as QQ chat information is essentially in tea encryption).

For example, consider using one of several encryption and decryption algorithms at random (each time the client goes online, the server uses the agreed ID to tell which set of encryption and decryption algorithms to use), increasing flexibility and the difficulty of cracking.

4.2) Database Storage

4.2.1) MySQL Community x64

4.2.2) MongoDB (alternative)

4.3) operating Platform

Linux 64bit (centos/red Hat)

5. PostScript

The above ideas, is a single game for the design foothold, more limited.

For example, login, the unified way to go to the login platform more common and reasonable (at this time by the Logingate and platform for interactive authentication). and log processing, and so on, can have a special deal with the background is also a good practice.

This will involve many aspects of the details and practices, in the original intention of the contrary, is the design described in this article, for reference only. But it is clear that, based on the above design, it is easier to improve it even if it needs to be expanded (after all, this server framework is designed for weak interactive mobile games).

6. Some discussions

To discuss the design with a friend, the base friend thinks that there is no need for a three-layer structure (client-->gamegate-->gameserver), but to let the client directly connect Gameserver (Gameserver is responsible for logical processing, can be linearly extended), and add a central server (centerserver), do simple game state recording and logic processing, as well as dominate the gameserver and so on. This is certainly a good design, but in the short term it is not intended to change the first edition of the design, considering such factors as simplicity of the framework and server security.

Weak interactive mobile game server-side framework Design