Optimization of Data Broadcast Solutions

In the server group architecture, we generally introduce a gateway server or component with similar functions. All client connections are here, and data is forwarded to the current map server.

 

In this way, there is a great possibility of optimization during data broadcast. In the previous single-server architecture, for example, to broadcast mobile messages, you can directly find the list of players around you, construct the data to be sent, and then call send in sequence. However, in a multi-server architecture, the data transfer between the map server and the gateway server will be very large, and the data will be different from the target IP address, the actual content is the same.

 

In fact, this optimization solution was considered in the previous single server architecture. The original method of sending data packets immediately encountered a problem when a large amount of data needs to be sent at the same time. To prevent the game logic from being blocked due to the sending call in the logic thread, we put the data sending work into an independent thread. When the game logic thread needs to send data to the client, it only submits the data packet to be sent and the client connection handle to the packet sending thread. This process is similar to the multi-server architecture with gateway.

 

At that time, it was also designed to avoid sending too many requests to the packet sending thread, because each packet sending request needs to copy a packet and add it to the sending queue, the obvious drawback is the CPU consumption of multiple copies of data and the memory consumption of multiple copies of data in the queue. Therefore, the necessity for optimization is very high.

 

The final solution is to submit a packet sending request only once. The request packet contains the list of client handles to which the packet is sent, so that the data does not need to be copied at all, in addition, the memory usage is only one copy.

 

This can also be done in a multi-server architecture. The difference is that the packet sending request is sent to the gateway server.

 

 

The previous solution has only taken this step, so we can continue to consider the possibility of further optimization.

 

For simple chat packets, for example, when the server broadcasts such packets in a group channel, the client handle list in each packet sending request is the same, unless the team members change. Therefore, you can consider that this list does not need to be sent every time. Use the control command to create these broadcast groups on the gateway server. You only need to specify the number of the broadcast group to broadcast data in the future. This is introduced in the cloud wind's "Multicast in game servers" article.

 

The groups here can also be called channels, such as group channels, Team channels, Guild channels, world channels, local channels, and current channels. Of course, there may also be self-built channels, each channel has a unique ID. The current channels of different players must be independent, but other channels can be shared.

 

Special instructions on the current channel are required. The current channel refers to a visible range centered on the player's current position, that is, the range to be broadcast when the player moves or speaks. The player positions change frequently, so the player list changes frequently in this channel, and the current channels of different players cannot be shared like the group channel.

 

This solution is very effective for scenarios where the player list is not frequently changed, but it is difficult to broadcast the current channel when the player list is frequently changed, maintaining this type of channels will make the channel member management commands between the map server and the gateway server very frequent.

 

However, there is also an option here. One is to notify the gateway server immediately when the channel members change, and the other is to check whether there are any member changes only when the channel data is to be submitted.

 

For example, if a player is sitting and not moving, and a player continuously passes by, the player list on his current channel is constantly changing, but if the player does not perform any operations, for example, for mobile and chat on the current channel, this change does not need to be reported to the gateway server, because no data in the channel needs to be broadcast.

 

Of course, if you do this, you may need to keep two lists of players on the map server to compare the changes to the list, this is to weigh the memory usage and network data transmission volume. Although it has not been verified by practice, I still prefer the latter solution.

------------------------------------------

By the way, I would like to add more remarks to the previous article.

When talking about the location synchronization policy of online games in the previous article, I did not describe the location synchronization method of 3D games too much, but I did not write it out at the end.

In 3D games, when a key is used to move a location, the intuitive idea is to broadcast the current status when the key is pressed and broadcast it when the key or button status changes, in this way, the amount of data sent is small.

However, after the actual encoding and consideration, the server cannot directly know the current exact location of the client, however, the server may need to know the current real location of each player at any time. For example, if an AOE skill is used, the server must calculate which players are within this range.

If this mobile synchronization scheme is used, the server is required to run a mobile Simulation for each player, and the current location should be updated continuously at a certain frequency. First, the simulation consumes too much CPU, and second, the simulated location cannot be completely consistent with the current real location of the client. Therefore, the final result is, it is better to let the client report its location on a certain frequency.

This is exactly wow's practice. As long as the mobile key is pressed, the client continuously reports its current position and moving direction to the server at a frequency of 10Hz, the server then broadcasts this information to the players around it.