Server Architecture Analysis of well-known online games

Http://blog.csdn.net/sodme/archive/2004/12/12/213995.aspx

Similar to QQ games, millions of concurrently online servers are added to favorites
Author: sodimethyl this Article Source: http://blog.csdn.net/sodme
Copyright Disclaimer: This article can be reproduced without the consent of the author. However, it is not necessary to retain the copyright, author, and source information of the first two lines of the article.

In the past few days, QQ games finally broke through the goal of millions of concurrent online users and moved toward a more ambitious goal, which eclipsed many other traditional chess and card casual game platforms, lianzhong does not seem to be a competitor of QQ at all, because QQ has more than 1 million registrations in addition to the 0.3 billion online game users (of course many of them are registered repeatedly) as well as the 9 million simultaneous online rate of QQ chat software, we can refer to the powerful chess and casual game empire built by QQ in the future.
In terms of technology, how can QQ games achieve simultaneous online play for millions of people and maintain high efficiency?
In fact, for any single network server program, the number of simultaneous connections that can be tolerated has a theoretical peak. The tsocket type is defined in C ++: word, we can determine that the theoretical peak value of this connection is 65535. That is to say, your single server program can withstand the simultaneous connection of more than 60 thousand users. However, in practical applications, it is not easy to connect to 10 thousand people at the same time and ensure normal data exchange. Generally, this value is between 2000 and 5000, it is said that the number of connections to a single server of QQ is at the same time.
It is not difficult to achieve a single server of 2000 to 5000 users online simultaneously. In Windows, iocp is used to complete the port. There are a lot of documents related to port completion on the Internet and csdn forums. If you are interested, you can search for them by yourself. As long as it is used properly, a complete port server can reach 2 K to 5 K at the same time. However, the number of 5 k is too different from that of one million. Therefore, the number of simultaneous online users cannot be achieved by a single server.
To achieve simultaneous online for millions of users, we must first implement a complete port server model that requires at least 2 K to 5 K at the same time (of course, if you have more money, you can also only develop servers that allow up to 100 online users ). After the basic port server is built, the architecture of the server group is designed. This is a server group because it is not only a server, but also a type of server.
Simply put, the server model for Achieving simultaneous online access for millions of users should be: Login Server + lobby SERVER + room server. Of course, it can also be other models, but the basic idea is the same. Next, I will introduce the respective functions of these three types of servers one by one.
Login Server: in general, we will open several public login servers to players, just like the QQ game server from which you choose to log on when logging on to QQ, when logging on to QQ, the six server portals that gamers choose are actually login servers. Log on to the server to balance the load. In details, there are n Hall servers behind the login server. The Login server is only used to select which Hall server should be connected to next for the current client connection, after the login server selects a suitable Hall server for the current client connection, the client starts to connect to the corresponding Hall server based on the information provided by the login server, and the client disconnects from the login server, makes socket resources available for other player clients to connect to the login server. When designing login servers, at least the following functions should be provided: Each Hall server of N Hall servers must be connected to all login servers, in addition, the number of concurrent online users of servers in this Hall is notified to login servers in real time, including: information about the number of concurrent online users and the number of concurrent online users who log out is increased. The number of simultaneous online users of servers in each hall is the basis for the login server to select a hall for the client to log on. For example, Player A connects to the login server through Login Server 1. The Login server starts to select a hall for the current gamer among the numerous Hall servers based on the number of servers in the hall, at the same time, the connection IP address and port of this Hall are sent to the client. After receiving the IP address and port information, the client connects to this Hall based on the information. At the same time, the client disconnects from the login server, this is the process of logging on to the server during user login.
Hall server: A hall server that is invisible to ordinary players. Its connection IP address and port information are logged on to the server to notify the client. That is to say, in the local file of the QQ game, the specific Hall server connection IP address and port information are not saved. The main function of the lobby server is to send the game room list information to players, including the type, name, number of online players of each game room, connection address and other information such as the game Help File URL. From the interface, the lobby server is the game room list interface that we enter the user name and password and pass the verification. The lobby server provides the following functions: first, it broadcasts information about the number of online players in each game room to the current player; second, it provides the game version and information; the third is to provide the connection IP address and port information of servers in each game room; the fourth is the URL information that provides game help; and the fifth is to provide other game auxiliary functions. However, among these many features, one of the most core is to provide players with a channel to enter a specific game room, allowing them to smoothly enter the game room they want to enter. Based on the number of online players in each game room, the player determines which room he entered. Then, double-click a game room in the server list and the player starts to enter the game room server.
Game room servers: Game room servers, specifically game rooms such as "Landlords 1" and "Landlords 2. The game room server is the Server responsible for executing the game-related logic. Such game logic is divided into two categories: general game room logic, such as: entering the room, leaving the room, entering the table, leaving the table, and talking in the room; the second category is game table logic, which is the main difference between different types of games, such as the logic of landlords or landlords. Of course, the game table logic also includes the general game logic that exists in each game, such as speaking in the table. In short, the game room server is the server that truly executes the game's specific logic.
The three types of servers mentioned here all adopt the complete port model. Each server can be connected to a maximum of 5000 people. However, I made a logical layer limit on the server in the game room, up to 300 concurrent online users are allowed. The other two servers still allow a maximum of 5000 concurrent online users. If we adopt this structure, we need to achieve simultaneous online for millions of people: first, the hall, 1000000/5000 = 200. That is to say, at least 200 Hall servers are required, but generally, at least 250 Hall server programs should be prepared considering the processing capacity and load of servers in actual use. In addition, the number of servers required for various types of game rooms must be calculated based on the number of players currently playing various types of games. For example, the number of landlords is at most 100,000 online simultaneously, each server allows a maximum of 300 concurrent online users. Therefore, the number of landlords required should be no less than: 100000/300 = 333. To be fully prepared, we need to prepare 350 landlords.
In addition to normal player connections, consider the following:
For login servers, there will be 250 Hall servers connected to each login server, which is always maintained;
For Hall servers, if there is only a server like landlords, more than 350 connections will be maintained with all Hall servers. From this point of view, my structure still needs to be improved in some aspects, but the core idea is to provide the user login speed as soon as possible, make it as easy as possible for players to enter the game.

Http://blog.csdn.net/sodme/archive/2005/06/18/397371.aspx

Reverse Thinking-World of Warcraft packet analysis (1) favorites
Author: sodimethyl
Source: http://blog.csdn.net/sodme
Disclaimer: This article may be reproduced without the consent of the author, but any reference to this article must indicate the author, source and the declaration information. Thank you !!

Note:
I really appreciate blizzard and their games. The reason for writing this article is to let everyone know some common methods of network packet analysis and learn Blizzard game experience in network processing, I think that as a network programmer, mastering the tools and methods of packet analysis should be one of its basic skills. All the packet analysis content listed in this article is available in the normal black box mode, and does not involve reverse engineering of World of Warcraft executable programs. In addition to the content involved in this article, I refuse to disclose more details about World of Warcraft packets to anyone. If you are interested, please perform relevant experiments on your own, in this article, I will try my best to avoid disclosing sensitive contents and related encryption and decryption algorithms. I would like to give this document to the blizzard of zhongai.com!

I. login module process and packet analysis

Let's first look at the logon process. From the encapsulation process, the login process of warcraft is as follows:

1. The client sends the username, password, and other information to the logon/account server. The last part of this data packet is the user name (plaintext, unencrypted). The first byte of the user name represents the length of the user name. The logon/account server returns the information required for successful logon and subsequent connection to the game server to the client. I have not seen the specific functions of the two packets in the middle. In this interaction process, the login/account server sends a list Of all game servers to the client. The server list data packets include: IP, port, the number of roles and other information on the server. Because the server list contains too many contents, the client receives the information twice.

2. after receiving the Server list of the Login server, the client identifies the recently accessed server (this information should be included in the Server LIST packet ), connect to the game server of the nearest game ). After the connection is successful, game server first sends an 8-byte data packet to the client. According to previous knowledge, the content of this data packet may be the encryption key used by the client to communicate with the server in the future.

3. The client sends its account information to the game server again. After two data packets are exchanged between game server and client, game server sends a role data packet to the client. This packet includes all the role information created by the player on the game server. Of course, this information is only partial, not all information about this role.

4. during subsequent communication, the client sends a connection-preserving packet to the game server every 30 seconds. The packet length is 10 bytes, and the last four bytes of the packet are an incremental number, the rules are not found for the first 6 bytes.

5. As long as the client does not click a role to enter the final game server, the client must always be connected to the login server. When the client clicks the role to enter the game server, the client is disconnected from the login server. In the future game process, the Client Always communicates with and only communicates with the game server.

Through the preliminary analysis of the data packets in the login process, we can draw the following conclusions:
1. The first data packet sent by the client to the login server. The user name is in plain text, and the content of the data packet is the same for each login, and does not change due to time. It can be estimated that the encryption algorithm for this data packet is fixed. In other words, the encryption algorithm for the password is easy to be found through reverse engineering. In this case, the server should first send an encryption key to the client, which can be used as the basis for security verification for future communication. But blizzard does not do this. The biggest possible reason is to improve the efficiency of the server. On the login server, if each client has to broadcast a packet to the client once the connection is successful, this amount may be relatively large, which may prolong the waiting time for players to log on, so they are not doing this.

2. The client is logged on to the login server address. The Login Server logon address may be different each time. I did not find these addresses in the client directory, but found the four domain names in the four regions in the Client Directory. I guess, world of Warcraft uses a simple DNS resolution method to achieve simple dynamic balancing of login server. I don't know if this conjecture is correct.

3. "depending on which game the player is playing recently, the client and server automatically choose to enter the game server for the player", this setting fully reflects Blizzard's consistent style: for the sake of players, maximize the comfort of the game. Once again, I agree with Blizzard's attitude!

4. Once a player enters the game world, the communication ports between the client and the server remain unchanged. That is, the design structure of the World of Warcraft game server group uses a server cluster with a gateway.

5. I think that the connection logic between the login server and the client is the biggest question during the entire login process. After the client is connected to the game server, the client is not disconnected from the login server, and the connection is maintained. Later, after further packet capture analysis, the reason why the client needs to maintain such a connection with the login server is that when the client selects the server again, it will not reconnect to the login server. When the client clicks the "Select Server" button, the login server sends a list packet of all servers to the client every 5 seconds. You know, the content of this server list packet is very large. If a player opens this window, it will not be closed, the login server sends a Server LIST packet every five seconds to all players in this situation. This broadcast volume is very large (about 2 K, this is a 2 K user ). I think the logic design here is quite unreasonable. To provide the client with the latest global Server LIST, Login server can maintain the connection, but it is not necessary to send a server list to the client every five seconds, it is also possible to update the list only after the client creates different roles on a server. However, you only need to update the changed content in the list without sending all the complete packages, in this way, the traffic is much smaller. It is said that at the beginning of World of Warcraft, the reason for the shutdown was that the login module was not properly handled, and I do not know whether the current situation has been improved. However, I still think that it is unacceptable to send a 2 k packet to the client every 5 seconds.

The above is only a simple analysis of the World of Warcraft login process. There is not much technical content, and we will discuss it with you to see if there is any reference, and there will be other parts of the packet analysis later. Welcome to continue with my blog: http://blog.csdn.net/sodme.

As mentioned earlier in this article, as a network programmer, it is one of its basic capabilities to skillfully use packet capture software and master basic packet analysis methods, one reason for sending this article is to introduce the use of related tools and common analysis methods to the network programming brothers. The following describes the basic methods and related tools for packet analysis:

1. you need a packet capture tool, which is recommended by commview. It is small but powerful. It supports custom packaging analysis plug-ins to be loaded in DLL format. That is to say, if you want, you can write a DLL to display, record, and decrypt a special type of packages.

2. How to view the real package data. In commview, the packet data of layers above the NIC level is listed in detail, including the Ethernet layer, IP layer, and TCP layer. For packet analysis, we only need to pay attention to the TCP layer. But there is also a lot of content in the TCP layer. For our analysis needs, we need to pay attention to its data field (in the Protocol directory, we can see the "Data Length identifier, click to view the content of the data segment.

3. The role of several TCP states for our analysis. On the TCP layer, there is a flags field, which has the following identifiers: SYN, FIN, ack, Psh, RST, and URG. the preceding five fields are useful for our daily analysis. They mean: SYN indicates a connection, Fin indicates a closed connection, Ack indicates a response, PSH indicates data transmission, and RST indicates a Connection reset. Among them, Ack may be used together with SYN, FIN, etc. For example, SYN and ACK may both be 1, which indicates the response after the connection is established. If it is only a single SYN, it only indicates establishing a connection. The several handshakes of TCP are represented by such ack. However, SYN and fin are not 1 at the same time, because the former indicates a connection, while the latter indicates a disconnection. RST is usually 1 after Fin, indicating that the connection is reset. Generally, when a fin or RST packet occurs, we think that the client is disconnected from the server. When a SYN and SYN + ACK packet appears, we think the client has established a connection with the server. When PSH is 1, it usually only appears in packets whose data content is not 0. That is to say, PSH is 1, indicating that the real TCP packet content is transmitted. Both TCP connection establishment and connection closure are completed in request-response mode.

Http://blog.csdn.net/sodme/archive/2005/07/10/419359.aspx

Reverse Thinking ---- World of Warcraft Packet Analysis (2) favorites
Author: sodimethyl
Source: http://blog.csdn.net/sodme
Disclaimer: This article may be reproduced, reproduced, or disseminated without the consent of the author. However, any reference to this article must indicate the author, source, and information stated by the bank. Thank you!

The packet analysis method is simple and simple, that is: comparison! We need to constantly compare and analyze packets from different perspectives, and make full use of your imagination to constantly intercept the packages you need for comparison. We should not only compare the horizontal (similar), but also compare the vertical (different classes. For the same package, we need to study it repeatedly.

A beginner in packet analysis generally does not know where to start packet analysis. Based on experience, this article will show you which types of packages will be analyzed and how to perform a preliminary analysis on the packets. It should be pointed out that packet analysis is a very interesting but also a test of patience. Usually, half a day of packet analysis, it will keep you in sight, such as "B0 EF 58 02 10 72 .... "and other network data, with headaches, dizziness, so there is not enough psychological preparation, please do not try it easily. Haha.

The basic premise for packet analysis is: you should understand and be familiar with the TCP protocol, and know what the packet "bonding" is. Of course, only a small part of the packets we normally intercept are "bonded" in terms of quantity. However, if you do not understand it, it may mislead and confuse your analysis ideas. For a more detailed explanation of "stick package", please refer to my another article "pack function and network packet Exception Handling (including Code) (http://blog.csdn.net/sodme/archive/2005/07/10/419233.aspx )".

In the previous article about World of Warcraft packet analysis (http://blog.csdn.net/sodme/archive/2005/06/18/397371.aspx), I analyzed the architecture and login logic of warcraft according to the process of connecting the client to the server and disconnecting the event and some data packets in the login process. In this article, I will combine the analysis of chat packets to explain the general structure of World of Warcraft packets.

First, let's explain our goal: the general structure of packets. What content does the general structure of the package contain? Generally, the general structure of a packet includes at least two aspects:
1. How does a packet indicate its length? Which field represents the packet length? (Or how to indicate the start and end of the packet)
2. Which field is used to represent different packet types?

Is there a "field" indicating the "length" of all game packets? The answer is no. Some games do not adopt this method, and their practice sets a special package start and package end sign. However, from the perspective of applications, we recommend the "length" method, because regardless of the processing efficiency at the bottom of the network and the processing convenience of upper-layer applications, it is better to use the "length" field to identify a complete logical package. After determining the general structure of packets, we can analyze the detailed structure of specific types of packets (such as chat and walking.

For data packet analysis, in the black box analysis stage, the selected data packet must be of this nature, that is, when the client does not encrypt the data packet before it is sent, we already know some of the content in this packet. Such a package can be used as a breakthrough in packet analysis. In this case, it is not difficult to understand the "chat packet" as the first analysis object, because we know what we say and what we typed, however, after being processed by the client, what we said may have been encrypted or the verification code added to the network. From the perspective of black box analysis, what we can do is to continuously compare, judge, and summarize various "chat packages.

OK. Open your commview. Let's start with "chat packets.

The prerequisite for analyzing the "chat package" is that we can normally determine which type of data packet is chat. Do not mistakenly treat walking or other data packets as chat data packets. To reduce the difficulty of analysis, we recommend that you analyze packets when there are few or no players in the game. In this way, no one will be disturbed. Second, your network traffic will be much smaller and it is easier to determine packets.

Step 1: Determine the port used by the client to communicate with the server, and then set the server port in the commview's rules-> ports to intercept all data packets that communicate with the port. How to determine the server port: Do not use other network communication tools, open commview, enter the game, capture packets, and observe the communication port. During packet analysis, especially during initial packet analysis, your network communication should be as single as possible, that is, do not open other communication software except games. However, after you confirm the IP address and port of the server, you can use other network software as usual.

Step 2, as described above, find a place where few or no one is in the game and start "talking to yourself. It is recommended that you use letters and numbers instead of Chinese. Because Chinese characters are dual-byte characters, while letters and numbers are single-byte characters, the packet capture software displays single-byte text information, however, for double-byte Chinese characters, the packet capture software may display garbled characters in some Chinese characters due to line breaks and other reasons, and it is not easy to directly see the Chinese content. If you insist on speaking Chinese, even do not block you, I recommend you a tool: String demander (: http://www.cnxhacker.com/Download/show/395.html), this software, you can query the Chinese corresponding encoding.

Step 3: Set the commview rules and make it take effect to start packet capture.

After observing the packets intercepted by the above process, we can find that the chat packets of World of Warcraft are in plain text! There is no need to make a fuss about this. Chat packets themselves do not cause damage to the key logic of the game, so it is not surprising that even the plaintext is displayed. However, we still do not trust our own eyes, so we cut several packets and found that the content in the packet is indeed plain text! However, other fields in the package are "ciphertext" that we cannot understand for a moment ".

It seems that the following thing is to study the "ciphertext" in these packets. Generally, this "ciphertext" encryption method cannot be analyzed through packet analysis. However, we can still infer some problems related to the "ciphertext" generation algorithm through packet analysis. We can make the following comparative analysis:
1. Input "A" three times in a row and observe and save the packet data respectively;
2. Input "AA" three times in a row and observe and save the packet data respectively;
3. Input "AAA" three times in a row, and observe and save the packet data respectively.

For the input package case, we chose the letter "A" and Its ASCII code is 61. The input rule is: Enter three consecutive times in each case, and then increase the number of A letters one by one. So we found this interesting phenomenon:
1. The content in the package is plain text;
2. Even for the same speech content, such as "A", the packages sent by the client are different;
3. When the number of letters in a speech increases by 1, the overall length of the packet increases by 1;
4. Except for the first 6 bytes of each packet and the talking bytes, the contents of other packets are the same each time;
5. The end byte of each chat packet is 0.

Therefore, we can try to draw the following conclusion:
1. The package is not compressed. the encryption algorithm used by the package should be byte. The package length does not change so that it looks like a uniform length;
2. The package ends with 0 (although we don't know what it starts );
3. The key used in the packet encryption algorithm is variable, that is, the ciphertext generated for the same data packet content varies according to the encryption key. After the client data is uploaded to the server, the server needs to decrypt the data. Therefore, the client-side encryption algorithm and the server-side decryption algorithm should share some of the first six bytes, using this as the decryption algorithm's key. If the six bytes do not contain the synchronized data required for packet encryption and decryption, the client and server should synchronize the data in other ways. However, I prefer the former, that is, these 6 bytes should contain the key information required for encryption and decryption.

Looking back at the interesting phenomenon we observed above, we thought about 2nd points. This should be the minimum function. That is to say, even if the client performs the same action, the package content in the package sent by the client is also different. In this way, the plug-in cannot simply resend the same package to achieve its goal.

After analysis, we still failed to determine the general structure of the Warcraft package. As a matter of fact, I feel that the purpose of this article has been achieved, that is, to show you the perspective and way of thinking of packet analysis. As for the specific results, I think it is really not important. It is certain that the packet structure of warcraft has been mastered. I will only publish my analysis results here:
1. The packet length field of warcraft is the first two bytes of each packet. Its representation is: the value of the first two bytes + 2. The reason for adding this 2 is that the packet length field occupies two bytes.
2. The packet type of warcraft is inferred to be the third and fourth bytes, And the type ID of common chat is "95 00 ".

Please do not send a letter to ask me about any content related to Warcraft packet cracking. I have already mentioned what I can say in this article. I did not write this series of articles to crack Warcraft, instead, we want to use such an excellent game as a case to show you what it deserves for us to learn and discuss in terms of packaging design, at the same time, it is only necessary to popularize common sense, tools, and ways of thinking about packet analysis to more friends.

PS: because each packet analysis involves a lot of content, once a conclusion is reached, it is necessary to record and summarize it in time and compare it with the previous summary, update relevant records and documents in a timely manner.

Http://xiaogui9317170.javaeye.com/blog/276133

Analysis on the communication architecture of bubble and QQ games

Author: sodimethyl

Website: http://blog.csdn.net/sodme/archive/2005/08/31/468327.aspx

Before, I analyzed QQ game (especially QQ casual platform, not qqtang, the same below) communication architecture (http://blog.csdn.net/sodme/archive/2005/06/12/393165.aspx), analysis of World of Warcraft communication architecture (http://blog.csdn.net/sodme/archive/2005/06/18/397371.aspx ), it seems that the communication architecture of online games is just like this. Otherwise, in the family of online games, there is another type of games. I think it is necessary to give a special introduction to its communication architecture, this is a casual and competitive game such as bubble bubbles and QQ halls. I have been asked many times by netizens to take time to look at the communication architecture of games such as bubble classes. This time, due to being forced to submit homework, I took some time tonight to cut off the bubble classes, coincidentally, I had some discussions with netizens about the communication architecture of the bubble-class games yesterday. So I summarized the discussions, packet capture and thoughts over the past two days in this article, hope to be helpful to friends who care about or are developing such games, if you want to discuss specific technical details, please go to my blog (http://blog.csdn.net/sodme) and add my MSN discussion ..

In general, the communication architecture of bubble games (hereinafter referred to as bubble games) from the hall to the room is equivalent to that of QQ games, and even easier than QQ games. So, in the room on this layer of communication architecture, I do not want to discuss too much, do not know friends please refer to my analysis of the QQ game communication architecture (http://blog.csdn.net/sodme/archive/2005/06/12/393165.aspx ). In this case, the same room and Hall architecture as QQ games can be used to build a scalable game system that supports millions of online users. That is to say, through Server Load balancer + Hall + game room allocation of game logic, we can achieve a scalable online bubble hall for millions of people.

However, the biggest difference between bubble classes and landlords is that bubble classes have extremely high real-time requirements. So, how does bubble Hall solve the conflict between real-time performance and network latency and large user volumes?

Before reading the following text, make sure that you fully understand the differences between TCP and UDP.

We know that the biggest difference between TCP and UDP is that TCP is a reliable connection, while UDP is connectionless. If both parties use the TCP protocol, they must first establish the communication pipeline of both parties through monitoring + connection. If both parties use UDP communication, the two parties do not need to establish a connection in advance. The sender only needs to send a UDP packet to the destination port on the target address, regardless of whether the other party has received the packet. If you want to talk about the image, you can use the following sentence: TCP is a call, and UDP is a Generate Report. TCP communication, in order to maintain such a reliable connection, has made a lot of effort in reliability, which leads to a much lower communication efficiency than UDP. Therefore, generally, when the local real-time requirements are very high, UDP protocol will be used, such as common action shooting games.

Through packet loading, we found that both TCP and UDP communication protocols are used in the bubble Hall. In addition, it has the following features:
1. When a player does not enter a specific game map, only TCP communication exists, rather than UDP communication;
2. After Entering the game map, the TCP traffic is much less than the UDP traffic
3. The number of UDP communication IP addresses is in a one-to-one correspondence with players in the room (this should be added due to questions from netizens, which has been confirmed previously)

The above are several superficial phenomena. Next we will analyze its nature and inner. ^ & ^

The game logic of bubble hall can be summarized into the following aspects:
1. gamer Movement
2. Players bury mines (if you think this method is more common, you can also call it bubble, haha)
3. A mine explodes a prop or mine explodes to trap another player.
4. players pick up items or eliminate/rescue a trapped player

Like MMORPG, among the above logic, the biggest broadcast volume is actually player movement. In order to keep the player's screen synchronized, every step of the message sent by other players must be sent to other players in real time.

Generally, the logic control of online games is mostly on the server side. Sometimes, in order to ensure the smoothness of the image, we will consciously reduce the logic judgment and broadcasting volume on the server side. Of course, this reduction is based on the premise of "not endangering the safe operation of the game. In the end, how to choose between efficiency, smoothness, and security is often a process of Experience Accumulation and efficiency improvement, which is a process of continuous logical optimization. However, one principle can be said: the "Key logic" must be determined on the server. So what is "key logic?

For example, I think this logic is the key logic: players can bury a mine somewhere, whether or not they can blow up items and what items they have, this information must be provided by the server. So what is "non-key logic?

"Non-critical logic" has different concepts in different games. In the general MMORPG, the judgment of the player's movement logic is counted as the key logic. Otherwise, if the server does not judge the mobile package sent from the client, it can easily cause instant migration and other devastating disasters. In the bubble room, it is worth considering whether the player's mobile logic should be regarded as a key logic. Players in the bubble hall can win. It is usually because they are playing well and won't win because of the instant shift, because if the plug-ins are to be used for the instant shift of the bubble Hall, there are too many factors to consider and the logic of judgment. Due to the rapid development of the game process, the transient point judgment of plug-ins is not necessarily more accurate than the real players, using plug-ins in the logic of player movement usually outweighs the loss in games such as bubble bubbles (except for the exceptionally abnormal and highly intelligent plug-ins ). According to the information I have found, most of the plug-ins in the bubble Hall are some key-pushing genie scripts. The essence of this plug-in is not completely a game robot. It is not a plug-in function implemented through pure protocols. This also proves my above ideas from the opposite side.

Here, you may have understood it. Yes! TCP communication is responsible for "key logic", while UDP communication is responsible for "non-key logic". Here "non-key logic" includes player movement. In the bubble Hall, TCP communication is used for communication between local players and servers, while UDP is used for communication between local players and other players in the same map. When a local player wants to move, it will broadcast its own mobile message to all players in the same map at the same time. When other players receive this message, they will update their game screen to synchronize the screen. When a local player wants to place a bomb on a map, the local player needs to send this message to other players and servers on the same map at the same time, instead of notifying the server about the message of placing a bomb, the server only notifies other players. When a bomb explodes, a message is sent to the server only when an item is to be picked up.

Then, you may ask, "Is there a certain item on the map". When did the server notify the client? There are two solutions to this problem:
1. When the client places a bomb, it notifies the server of the message of the bomb. After receiving the message, the server can tell the client which items will be generated after the bomb explosion. But I think this solution is not good, because it will increase the data traffic during game operation.
2. the 2nd solution is that after the client enters the map, the server sends the information of the points where each item in the map to each client at the beginning of the game. In this way, you can save two overhead aspects:. when the client places a bomb, it can only notify other players without notifying the server; B. the server also does not need to pass information about a certain item to the client during the game operation.
　　
However, no matter which scheme is used, the server should keep the information of the point where the item in the map is located. Because the server uses it to verify a key logic: players pick up items. When a player wants to pick up a prop at a certain point, the server must determine whether there is a prop at this point. Otherwise, the plug-in can continuously obtain the prop by frequently sending a bag to pick up the prop.

As for the implementation methods of other game logic in bubble Hall, I think we still need to rely on this principle: Is this logic the key logic first? If not all, which part of the logic is non-critical? For non-critical logic, it can all be done by clients (UDP. For the key logic, you must have the server (TCP) checksum and authentication. This is what I want to talk about.

The above is just a theoretical discussion of the possible practices of bubble games in the communication architecture. These ideas are not based on facts. All conclusions come from the analysis of packets and personal experience, the content and opinions of the article may be quite different from the actual implementation of the bubble Hall communication architecture, but I think this is not the main one, this is because I want to introduce to you how to choose and divide the game logic when TCP and UDP Communication coexist. Both the "Key logic" and the specific implementation of "player movement" require developers to summarize and optimize them in specific practices. This article should be an introduction. If you have any questions, please add MSN for discussion.