How are website servers and game servers connected together?
1. There are many types of games, let’s take a look at MMORPG first.
No matter how simple the RPG server is, it is inevitable to deal with multi-person interactions. In the same scenario, hundreds of people need to receive operation information from everyone else.
Secondly, users' operations are very frequent, and general servers tend to hold long connections. Moreover, these links interact frequently and do not have obvious persistent partitioning strategies, so they restrict the horizontal scaling of the server. The same scenario can often only be run on one physical machine.
Again, PC games usually dare not put logic operations on the client. Users crack it for you in minutes, change gold coins, and brush two pieces of equipment. Therefore, this map server must verify the operations of all players in the map and calculate a series of business logic such as monster AI and drop rate.
We can see that traditional game servers are obviously different from web servers, with unique business needs such as long connections, multiple broadcasts, complex business logic, and restricted partitioning strategies.
2. Let’s take a look at the benefits of concurrency to the game server.
Concurrency is actually a program logical process, and it does not require multi-core physical support. The general meaning is to make multiple independent logic streams look like they are running at the same time. Operating system-level concurrency is a multi-process multi-threaded model. Let the OS handle clock interrupts, i\o blocking and other issues.
For servers, if most of the task is spent on i\o, a concurrency mechanism can prevent the entire map service from being blocked by i\o access. When a task is blocked, allocate the spare computing resources to other tasks. In this case, concurrency is beneficial to server operation efficiency and response time.
For programmers, independent logical flow means that they can complete their tasks in a reliable, simple, loosely coupled context.
Because the logic switch between OS handlers has to be repeatedly stuck in the kernel, some people think this is too slow, so they do some threads in user space, and control multiple logical flows themselves in the process. Due to the limitations of language description capabilities, it is too troublesome to write and use such things on C/C++. So the coroutine syntax sugar in erlang, go, lua is generated.
In essence, it also controls multiple logical flows by itself, but this logical flow is distributed based on the i\o state and has priority. In actual implementation, it tries to use non-blocking asynchronous i\o as much as possible. When a single task calls i\o, I stop it and wait until the signal of i\o is sent up, I restart it.
Note this, every time I run a task, and it won't actively switch to other program streams until it completes or an i\o call occurs. So if this task involves too much computing, the entire map process will be blocked here.
And because it is asynchronous, it is necessary to constantly write callbacks and listen for signals completed by i\o. The logical flow of a single task will be interrupted multiple times. When the task becomes quite complex, the so-called callbak hell will cause great trouble for debugging and development.
3. Because of the above reasons, I do not recommend using it in non-prototype MMORPG server development.
4. The mobile game server that has emerged recently is quite suitable because mobile games are limited to network problems., the server can only perform key data verification, and it cannot handle situations where multiple people interact. The server side has been simplified so much that it is no different from a web server. The business logic is also simple, processing data and then persisting.