Description of the MMO component in the game engine "Tornado"
Long sought an open and free MMO engine on the Internet. Either it was a frank nonsense, or a paid project. In general, these engines among the companies that make MMO RPGs are complete, but each company writes its own engine. There is no uniform standard. I had to write it myself - and I did it. I thought over the library interface for a long time. Then he also implemented it for a long time. Then I finished the security (AES and RSA based on OpenSSL, the problem "Man-in-the-middle" was eliminated). The engine turned out to be cross-platform (work with the network thanks to boost). You can exchange packets using both TCP and UDP.
As a result, according to my calculations, the server may well hold up to a million clients (it all depends on hardware, the more, the better). This is possible thanks to the cluster organization of the server.
So, for the client side, the Client interface is presented. With it, you can log in and then exchange data with the server.
')
With the server, things are more complicated. It consists of three layers. The first layer is Slave. The client after authorization works with it. The second layer is Master. Through it passes the authorization of the client. When the client is authorized, the IP master is used. Next, the wizard directs the client connection to the least loaded in the Slave cluster. The master is the head of the cluster and usually some amount of slave is associated with it. Using the wizard, you can combine clients into groups (for example, to conduct a fight in the same room, so that it is physically one computer). Then the master redistributes clients so that they have a network connection with one Slave. There is a transfer of clients (re-switching).
If the number of clusters is more than one and between them you need to exchange data, then SuperServer (third layer) is used. The superserver links clusters into agglomeration. The superserver owns information about all clients of the agglomeration and controls the authorization process (for example, a ban on authorization on two clusters using the same client authorization data).
Features of implementation.
At the core lies the idea of scripting. There is a script (pure logic) and context of the script.
A script is a sequence of actions (sending packets and receiving reactions) that are performed on the context.
A session (network connection) is associated with a set of contexts, each of which is intended for its own scenario (for example, data exchange and authorization).
But when one of them is being worked out, the rest should be blocked. That is, the work on the session is always carried out only in one scenario.
For example, the Master has many sessions with downstream Slave. For each session fulfills its own script.
The script is just slipped into the package and it looks for the context that is associated with it (either by ID_Session or by the key that is transmitted inside the package).
Further, some actions are performed according to the scenario.
Engine source code: github.com/RamilGauss/MMO-Framework
Video demo: www.youtube.com/watch?v=g8IlYRepclE
As a result, according to my calculations, the server may well hold up to a million clients (it all depends on hardware, the more, the better). This is possible thanks to the cluster organization of the server.
So, for the client side, the Client interface is presented. With it, you can log in and then exchange data with the server.
')
With the server, things are more complicated. It consists of three layers. The first layer is Slave. The client after authorization works with it. The second layer is Master. Through it passes the authorization of the client. When the client is authorized, the IP master is used. Next, the wizard directs the client connection to the least loaded in the Slave cluster. The master is the head of the cluster and usually some amount of slave is associated with it. Using the wizard, you can combine clients into groups (for example, to conduct a fight in the same room, so that it is physically one computer). Then the master redistributes clients so that they have a network connection with one Slave. There is a transfer of clients (re-switching).
If the number of clusters is more than one and between them you need to exchange data, then SuperServer (third layer) is used. The superserver links clusters into agglomeration. The superserver owns information about all clients of the agglomeration and controls the authorization process (for example, a ban on authorization on two clusters using the same client authorization data).
Features of implementation.
At the core lies the idea of scripting. There is a script (pure logic) and context of the script.
A script is a sequence of actions (sending packets and receiving reactions) that are performed on the context.
A session (network connection) is associated with a set of contexts, each of which is intended for its own scenario (for example, data exchange and authorization).
But when one of them is being worked out, the rest should be blocked. That is, the work on the session is always carried out only in one scenario.
For example, the Master has many sessions with downstream Slave. For each session fulfills its own script.
The script is just slipped into the package and it looks for the context that is associated with it (either by ID_Session or by the key that is transmitted inside the package).
Further, some actions are performed according to the scenario.
Links
Engine source code: github.com/RamilGauss/MMO-Framework
Video demo: www.youtube.com/watch?v=g8IlYRepclE
Source: https://habr.com/ru/post/233915/
All Articles