The architecture and difference of the service side of the hand tour and the end tour

Transferred from: http://www.gameres.com/336666.html

The service side of the hand tour and the end tour is essentially no different, the difference is the game type .

Type 1: Weak interactive server with cards, parkour, etc.

Card Parkour class because of the weak interaction, players and players do not need real-time face PK, hit each other's offline data, calculate the leaderboard, buy and sell props can, so the implementation often use a simple HTTP server:

Asymmetric encryption (RSA, DH) can be used when logging on, and the server calculates the hash-obtained encryption key and sends it to the client based on the client UID, the current timestamp, and the service-side private key. Both sides then use HTTP to communicate, and use that key for RC4 encryption. After the client receives the key and the timestamp is saved in memory, used for subsequent communication, the server does not need to save the key, because each time can be based on the client's UID and timestamp and the service side of its own private key calculation. The behavior that mimics TLS is used to guarantee the client identity between multiple HTTP requests, and the time stamp ensures that the same person has a different two-time login key.

At the beginning of each inning, visit, request the level data, finished and submit, check whether it is legal, what reward, database with a single MySQL or MongoDB, the back-end of the Redis cache (optional). If you want to implement the notification, then let the client polling the server 15 seconds, if there is a message to take down, if no message can be gradually put a long polling time, such as 30 seconds, if there is a message, shorten the polling time to 10 seconds, 5 seconds, even if two people chatting, delay can be adaptive.

This kind of server used to implement a three-way strategy or card and parkour game is more than enough, this kind of game because the logic is simple, the interaction between players is not strong, using HTTP to develop, the development speed, debugging only need a browser can be debugging logic clear.

　Type 2: First-generation Game server 1978

In 1978, University of Essex, a student of Britain's famous financial school, Roy Trubshaw, wrote the world's first mud program MUD1, which was accessed in University of Essex in 1980. Arpanet later joined a number of external players, including even foreign players. The source code of the "MUD1" program has been widely adapted after the arpanet sharing, so mud is popular all over the world. Constantly improve the MUD1 on the basis of the emergence of Open source MudOS (1991), become the originator of many online games:

MudOS uses C language development, because players and players have a relatively strong interaction (chat, trading, PK), MudOS use single-threaded non-blocking sockets to serve all players, all players requests are sent to the same thread to deal with, the main thread every 1 seconds update all objects (Network transceiver, Update object state machine, process timeout, refresh map, refresh NPC).

The game world is organized in the form of a room, each room has four directions can move to the next room, because the first online games in Europe and the United States are the Dungeon Maze form, so the basic unit of the scene is a "room." MudOS uses a scripting language called LPC to describe the entire world (including room topologies, configurations, NPCs, and various plots). In-Game advanced Players (Wizards), can constantly modify the script to add room for the game and increase the plot. Early MUD1 on-line only 17 rooms, Roy Trubshaw after graduation to his brother Richard Battle, in Richard Battle hand, constantly add all kinds of play to more than 100 rooms, finally let mud flourish.

The user uses a client such as telnet to connect to the MudOS with the TCP protocol, using plain text for the game, and each instruction is split with a carriage return. For example, 1995 domestic first mud game "Knight Line", you type: "Go East", the game will prompt you: "Back garden-here is the back garden of Yunzhun, planted with flowers, a few Zhongdin are watering flowers." Here is the place where Mimosa grows. The only exit here is north. Here are: Flowers to dading (a mu), there are two Zhongdin (Zhuang Ding), and then you continue to use the text operation, see the dading information: "Look A mu", the system prompts: "Flowers to Dading (a mu) he is a disciple of the wind, he was ordered to take care of Mimosa. He looked more than 30 years old, born eyed, upright, handsome. His martial arts look "not very high", the shot seems "very light". Then you can choose to beat him to get mimosa, but you eat the mimosa but may be poisoned to death. In the early days of online resource scarcity, such a game has a strong sense of generation.

The user data is saved in the file, each user log in, from the text file to load the user's data, all the operation in memory, do not need to immediately brush back to the disk. The user exits, or if the data changes are checked every 5 minutes, the disk will be saved. Such a system at that time each server carrying a 4000 people at the same time game, not particularly big problem. Since the release of the MudOS in 1991, the world has been improving, expanding, and exiting the new version, with the enhancements of Windows graphics. 1997 Game "UO" on the basis of MudOS for the role of the x, y coordinates, added a map for each room, and added animation for each character, forming the first generation of graphics network game.

Because the game content is basically customizable through LPC scripts, MudOS also becomes the first server-side engine that can be developed at once, and then make different game content. The follow-up domestic "King of Kings" and other games, many are with the "UO" like, directly on the MudOS on the development of two times, add the room map also has the role of the coordinates and other elements, the architecture has been the first generation of domestic MMORPG provides a solid support, until 2003, there are games based on MudOS development.

Although there is a lot to add to the graphics behind it, the nature of these MMORPG back ends is MudOS. With the game content becoming more and more complex, the architecture becomes more and more unbearable, various load problems slowly floating on the surface, so there is our second-generation game server.

Type 3: Second generation Game Server 2003

2000 years later, the online game has been divorced from the original text mud, into the full graphical era. The first to withstand the fact is a lot of small files, users on the offline, frequent read write user data, resulting in more and more heavy load. As online numbers increase and game data increases, servers become overwhelmed. At the same time, early ext disk partition is fragile, a little power outage, prone to large area data loss. So the first step is to split the file into the database.

At this time the game server has been out of the old MudOS system, companies in the reference to the MudOS structure of the case, began to use their own C in the re-development of their game server. And the script also discards LPC, replacing it with more extensible Python or LUA. As the main logic uses a single-threaded model, the structure of the traditional single server becomes a bottleneck as the game content increases. Then someone began to split the game world into the following model:

Game server pressure split after complacent mitigation, but the two game server access to the database at the same time, a large number of repeated access, a large number of data exchange, making the database become the next bottleneck. Thus formed the database front-end agent (DB proxy), the game server does not directly access the database but access the proxy, and then have the proxy access to the database, while providing memory-level cache. Early MySQL4 did not provide a stored procedure before, this front-end agent and MySQL run on the same platform, it transforms the game server sent high-level data operation instructions, split into specific database operations, to a certain extent replaced the stored procedures:

However, such a structure does not last too long, because the player switches the scene often to switch connections, the middle of the state is prone to confusion. And the game server after more, the interaction between the data will become more troublesome, so people split the network function, independent out of a gateway service Gate (some places called Session, some places called Linksvr, the name is different):

The network function is extracted separately, let the user unify to connect a gateway server, then have the gateway server forwards the data to the back-end game server. And the data exchange between game servers is also connected to the network management for Exchange. Such a type of server basically stable for gamers to provide game services, a gateway service 120,000 people, behind the game server each service 5k-1w, depending on the game type and complexity is different, the figure hides a lot of unimportant servers, such as login and management. This is the most widely used model, and today many new projects will be built with such a structure.

People have inertia, according to the previous experience, it seems that the MudOS split the more open performance the better. So we continue to think that the gateway can be split ah, basic services such as chat transactions, you can split Ah, can also provide a Web interface, the database can be split, so the following model:

Is this model useful? There are indeed successful games that use architectures like this, and have played its performance advantages, such as some large MMORPG. But there are two challenges: with each additional server, the complexity of the state machine may double, resulting in higher costs for research and development and bugs, and a larger challenge for the development team, which can be easily linked once the project time is tight and the developer is inexperienced.

For example, I have seen a certain Shanghai first-line game company's RPG up to this kind of architecture, I looked at their team members experience, asked their online date, advised them to use a slightly simpler front of the model. People are confident that there is a successful project to do so, they also want to do so, they want to achieve a set. So they started coding, the project for more than a year, then, there is no then.

Now that the game has a low success rate, the first set of more complex architecture needs to consider ROI, such as your game online six months to how many PCU? If a APRG game, each group of servers 5,000 people can not reach, then choose a more realistic structure more economical. Even after your project is really more than 5,000 people towards the goal of 10,000 people, believe that time your project has made a lot of money, you count the cost of the class to gradually iterate, split it again and again, I believe the heart is also happy flowering.

All of these types are basically starting with split MudOS, and each part of the MudOS is split from a single machine into a distributed one step-by-step. Although today many new projects are using one of the similar structures above, or they have done other hot module split. Because they are essentially the decomposition of mudos, they are summed up as a second-generation game server.

　　Type 4: Third-generation Game Server 2007

From the World of Warcraft, the seamless map has been popular, compared to the previous game players to walk a few steps also need to switch the scene, each switch will wait loading dozens of seconds is a very destructive game experience things. As a result, the seamless map has become a standard configuration for large MMORPG after 2005. Compared to the past, according to the map to cut the game, the seamless world does not exist a map above the people have and only a single server processing:

Each node server is used to manage a single area of the map, and Nodemaster (NM) provides them with overall management. A higher level of world provides management services at the continental level. Here omit a number of details server, such as traditional database front end, login server, log and monitor, all with admin summary. Under such a structure, a player moving from one area to another requires a simple process:

Player 1 is completely controlled by node A, and player 3 is completely controlled by Node B. At the edge of two nodes, the number 2nd player is also serviced by A and B. Player 2 in the process of moving from A to B, the same time to a request to the left of the situation, and to B request to the right. But at this point player 2 still belongs to a management. It was not until player 2 completely left the AB boundary that it was completely managed by B. This logic divides the world map into a piece of area, which is managed by different node.

For a node to be responsible for the area, there is no need to connect together geographically, such as the surrounding edge of the mainland and the high mountain section of the block people are relatively small, can be unified to a node to manage, and these chunks are not geographically linked to the necessity. A node in the end to manage which blocks, according to the real-time operation of the game load situation, the timing of maintenance changes Nodemaster above configuration.

So the first problem is that many node servers need to communicate with the player, you need to ask the Management Server specific UID for the number of players on which gate, the previous scene-cutting server This problem is not big, asked once can be cached, but now the server kind of increased a lot, Players will float to float, according to the UID to find players more trouble; On the other hand, the gate needs to dynamically calculate the coordinates and which node communication, resulting in more and more thick logic, so that: "User objects" from the gate in charge of the management of the cutting out of the necessity of the following model:

The gateway server is returned to the streamlined network forwarding function, while the user logic is assumed by the obj server according to the UID, the gate is distributed according to the load of the network access, and obj is distributed according to the number of the resource (UID), so that with a user communication directly according to the UID calculation Obj server number to send data. The new independent obj provides more high-level services:

• Object movement: Manages the movement of specific players between different node-governed areas and communicates with the desired node.
• Data broadcast: node can set several tags for each user, and then notifies Object Master to broadcast by tag.
• Object message: Generic message push, send data to a user, tell OBJ directly, do not need to deal directly with gate.
• Friends Chat: Chat between characters go directly obj/obj MASTER.

After the entire server body is divided into three tiers, node focuses on the scene, obj focuses on the player object, and gate focuses on the network. Such models are widely used in the seamless scene server. However, as time goes on, the load problem is becoming more and more obvious, to do an activity, far to inactive areas become very active, rely on weekly maintenance to adjust or relatively cumbersome, so there is dynamic load balancing.

There are two methods of dynamic load balancing, the first one is to modify the boundary of each node dynamically by node Master, and the different player objects move from node to node in the previous way:

Figure 11 Dynamic load Balancing

This way, Node master periodically looks for hot spots on the map, calculates new scene cuts, and then tells other servers to start adjusting in the same way that the above objects move across boundaries.

But the above approach is relatively complex, so people have devised a new approach that is simpler and more straightforward:

Figure 12 Dynamic load balancing based on the grid

The

still cuts the map to a static grid by a standard size, each of which is responsible for a specific node, but can be migrated to other node in real time, depending on the load situation. The migration is divided into three stages: prepare, switch, and finish. The three states are maintained by Node Master. In the preparation phase, the new node begins synchronizing the data on the grid above the old node and tells Nm;nm to notify the old node when it is done. After the switch is complete, if the obj server is still communicating with the old node, the old node will correct it, and the corrected obj will fix its state and communicate with the new node.

Many of the seamlessly dynamic load-balanced service providers claim to support unlimited numbers, but it doesn't mean that the maximum number of MMORPG games can really be extended, because such systems are subject to network bandwidth and client performance. Bandwidth determines the maximum broadcast limit for the same region, and client performance determines how many characters can be plotted on the same screen. The

began with the introduction of a distributed object model from a seamless map, and has completely detached itself from the MudOS system and became a new service-side model. And thanks to the introduction of dynamic load balancing, the seamless server was able to accommodate the number of people over the previous generation of game servers and provide a better gaming experience, which we call a third-generation Game server architecture. Online games with large multiplayer role-playing as the beginning, RPG online games in a long time to occupy more than 90%, making the service-side architecture based on MMORPG has been flourishing development, however, with the players tired of the RPG, a variety of non-MMORPG games springing up in the eyes of the people, by the market welcome.　　




Classic Battle Network Service side and RPG game there are two differences: RPG is differentiated services, Beijing and Guangzhou users laosi. While the war network, although each game is generally 8 people, but only a set of servers in the country, all players can play together, and players and players using peer-to connect together, form a game:  

Players use the Match Making server: Create, join, auto-match, invite and so on to form a game. The server chooses a person to be the Host, and the other person is connected to the master player. Stun is to help players establish a peer-to-peer traction server, and because of the peer to the situation is about 75%, it is not connected players will be forwarded through the forward.

A lot of connections to battle, sports games using a similar structure. The peer has a mesh model (all players connect to each other), and a star-shaped model (all players connect to a master player). Complex game states are difficult to form in a mesh model, so the star-to-peer model has withstood the test of history. In addition to the game data, the voice-enabled network system will also send everyone's voice data to the master player's machine, by mixing to re-encode the way back to all users.

Battle Network game, to athletics, sports, action and other types of game-based, slower-paced RPG (including ARPG) has an essential difference, and the intense game process will inevitably bring to more than the RPG complex synchronization strategy, such synchronization mechanism often brings a lot of game results directly calculated by the client, That is everywhere is cracked today, how to ensure the game results of justice?

The main method is the voting method, and all clients are evaluated independently and then passed to the server. If the results are the same, the records are updated, and if the results are inconsistent, a similar vote is taken to determine the final result. At the same time record all the input of the play game, where possible, find another idle game client to check whether the whole game is the result. And records are often suspected of cheating users, for operators to seal the reference.

　　Type 7: Casual game server

Casual games similar to the War network server, are all the region-wide architecture, the difference is that there are room servers, there are specific game servers, the game body is no longer in the player to peer, but connected to a dedicated game server processing:

As with the network-wide architecture, user data cannot be load into memory as a partitioned RPG, and then modified directly in memory. In a region-wide architecture, in order to respond to a user playing several games simultaneously, the user data needs to distinguish between the basic data and the different game data, and the game data needs to differentiate the integration data and the document data. Points such as win level negative can be directly submitted incremental changes, and more common document class data need to provide read and write tokens, write tokens only one, read tokens have a lot of blocks. With the same account in the same game while playing on both computers, the first game to get a write token, you can manipulate arbitrary user data. Then started the game in addition to be able to submit wins flat negative integral incremental change, the user data using a read-only way to ensure that the game can run, but will prompt users, game data lock.

Type 8: Modern action games

Starting with the early Korean action game, traditional Battle Network action games and RPG games begin to fuse. The simple action game player is easy to be tired, the retention is not so high as the RPG, but the simple RPG battle but slow rhythm tedious, unable to satisfy many players fierce confrontation expectation, therefore both began to merge to become the new generation: the Movement + the town pattern. The player gathers in the town, then opens the copy the way several people go out to play the action game to complete various RPG tasks. The essence is a set of RPG server + replica service side. Because the characters can be controlled within 8 people per copy, a more real-time gaming experience is available, allowing players to play more readily.

Say so many game server type, actually also almost, the rest of the types of people piece together is actually this look. The game server has undergone so many structural changes, is the internal development model still unchanged? Is the continuation of the traditional way of development? Or is there more ground-breaking methods? Is there any common logic behind the architectural changes that have been going through so many times? What are the difficulties of future development? How does the game server development reach the end of the shore?

The architecture and difference of the service side of the hand tour and the end tour