Action Hand Tour real-time PvP technology revealed (server article)

Objective

Our game is a ninja fighting for the theme of the Act game, its main play is PVE push chart and PvP sports. In the plot mode, the height reduction plot again makes many players tear eyes. The fun of the arena, along with the season and a variety of events, is also popular among players, from tens of thousands of to hundreds of thousands of of the live platform audience. However, the introduction of real-time PK on the mobile side is not an overnight, this article will introduce you to the game of real-time PvP-related technology.

Technology selection

Real-time PK performance is the process of quickly synchronizing the behavior of N players to show and maintain consistency with other players. Here are a few points to think about:

• Sync what? It can be a player's specific action (such as a move operation), or it can be a key operation (such as a directional key), which is slightly different.
• How to sync? Can choose a variety of ways, the traditional C/s mode, or the peer-to form, or frame synchronization.
• How to sync? The carrier can be tcp/udp. Which is more reliable to use?

Based on the above considerations, in the game, the use of a reliable UDP frame synchronization model as a real-time PVP technical solution. You ask why not use TCP, why not C/S, why not on the peer, the following is decided.

Implementation Details

Here are some important details to solve the many why not problems.

Using the frame synchronization model

Why frame synchronization, the direct reason is the inheritance before the AI (tornado) experience, for ACT type game, we believe that frame synchronization is a good solution, mainly to obtain the following benefits:

• High consistency. For skills in combat, if not accurate to the frame, there will be some strange phenomenon. Imagine the role of a floating fall, one of the clients may see has fallen, the other side in the non-fall when the other skills, there will be two results, even if it pulled back, equally strange. And the mechanism of frame synchronization ensures the consistency of client side.
• Simplified server logic. Traditional C/S architecture, in server computing and calibration, a large number of core logic needs to be implemented by both the client and the server, using frame synchronization can greatly simplify and ensure the stability of the server.
• Low flow consumption. In the mobile network, the user's traffic is money, if the core part of our game consumption is serious, then let 45% 1 of the non-WiFi users feeling why?
• Anti-cheating. To be reasonable, frame synchronization is not friendly to anti-cheating, but there is a simple way to quickly cheat, that is, when the data is inconsistent (escalated data or combat results), that is, the detection of someone cheating.

So, how does the process of frame synchronization work? Demonstrates the process of two client Playera/playerb and server interactions.

For the client, it continually reports its behavior to the server and waits for a frame packet from the server to drive its logic. This approach is an evolution of frame lock Synchronization (lockstep) 2.
For the server, the fixed frame interval (66ms) places the actions of the Playera/playerb in the queue in a frame and synchronizes to two clients, which seems similar to Bucketsync.

I am often asked a question, the other side of the lag will not affect my game experience, from the above our synchronization principle, perhaps you can find the answer.

Using UDP instead of TCP

Frame synchronization and the protocol layer is TCP or UDP is not required, but we do not consider the start of TCP directly embrace UDP, the reason, if the characteristics of the TCP slightly understand, will probably back that Zi Jing: "Slow Start", "Fast retransmission", "congestion avoidance" (three words!) ）。 I summarize it the following few points are not suitable for the real-time requirements of high, latency-sensitive mobile network games:

• Slow start algorithm is not suitable for mobile network scenarios, in the mobile network environment when the signal good bad is the norm, slow start will make the data can not quickly reach the end of time.
• Congestion avoidance algorithm is not suitable for mobile network The main reason is that it takes into account the fairness and convergence of the network, and the AIMD algorithm will make real-time greatly affected, delay significantly improved.

There is also the TCP protocol used for retransmission of the RTO exponential change and congestion algorithm implementation Nagle cache, and so on, TCP is not too suitable for high real-time requirements of the game play the reason, no longer listed.

So why is UDP more appropriate compared to TCP? More useless, look at a set of data:

Obviously, in various network scenarios, the performance of UDP (latency distribution) is basically better than TCP. Test program in the same network environment, by setting a certain delay, packet loss rate, jitter, etc., to obtain TCP/UDP RTT3.

For the choice of peer-to, we give up because the UDP hole is not 100% success, and if the hole is still to go to the server forwarding, so simplify the design considerations, do not choose Peer to sync.

DIY Reliable UDP yourself

What is said above with what (UDP) sync what (frame data) problem, have classmate to ask, UDP unreliable transmission, drop packet how to do? Of course, for data consistency, we do not allow (perhaps allow a small number of) packet loss, TCP reliability is guaranteed by the ack/seq+ retransmission, the most reliable UDP implementations on the world, are similar principles.

The implementation of several reliable UDP (udt,enet, etc.) was found to be slightly complex, and in our development, the reliable UDP implementation within the company did not reach the stage of use, and since it was not complicated to reinvent the wheel, he rolled up the sleeves and wrote.

For reliable UDP implementations, the UDP protocol custom header is this:

12345678910111213141516

//客户端上行包typedef structUdpPkgRecvHead{    uint16_t seq; //start from 1    uint16_t ack; //ack server seq    uint16_t sid; //player uid    uint8_t  action_len; //pkg actions contain}UdpPkgRecvHead;//...//服务器下行包typedef structUdpPkgSendHead{    uint16_t seq; //inc when frame id ++    uint16_t ack; //ack client pkg‘s seq    uint8_t frame_len; //pkg frames contain}UdpPkgSendHead;

Based on the above definition, the process of reliability assurance is probably as follows:

The client contracts to the server after one of the following conditions is met:

• When the player has operation
• When the packet is not received after the interval (99ms)
• After the packet has been received at a certain interval (99MS)

If the player has the operation, then the confirmation information with the player's operation upstream package "piggyback" to the server; If there is no action, the confirmation information is escalated to the server at a fixed time. The client's SEQ adds 1 for each action (action), and the server SEQ adds 1 to each frame of data, and the two sides have different RTO values of 4.

For the guarantee of reliability, the request retransmission can be used, and we use the redundant retransmission. One advantage of using redundant retransmissions is that it simplifies the troublesome timing problems, and each packet that is received is in the complete order. In the case of network congestion, bandwidth utilization is better than TCP, and it is insufficient to increase the traffic slightly. Is the process of redundant retransmission:

The illustrations are as follows:

The client sends Action1 come over, remember Seq=1, the server did not receive.
The client also added Action2, at which time the new package would contain both Action1,action2 and seq=2.
The server confirms the package for the previous step, and the package ack=2 sent to the client indicates confirmation.
The client has not received ack=2 confirmation from the server for some reason (possibly delay, etc.), and Action3 is added and the contract is seq=3.
When the client again hair Action4, found before the ack=2, so the new package will only take Action3,action4 and seq=4.

This demonstrates the process of redundant transmissions, where the server can dynamically remove redundancy or discard expired packets based on seq/ack conditions for packets received. Perhaps you would think that full redundancy is not appropriate and there is a clear space for optimization? In the long-term operation of the actual current network, the redundancy rate of total redundancy is about 100%, which is the right price for reliability and more real-time performance compared to some reliable transmission of the last three frames.

Summary: In shaving some optimizations and details, this is the mechanism of reliable UDP, simple and effective, with a minimum overhead of 5. After testing and actual online operation, the performance in the weak network environment is also good.

Anti-cheating strategy

The technical details of the implementation are over, so let's talk about our anti-cheating strategy. Some experience is the practice of truth:)
We know that the frame synchronization is all in the client computing, the server can do is very limited. We do not know the player's current position, do not know the player's skill usage, do not know the current amount of the player's blood, what to anti-cheating?

Real-time detection, made two points:

Client fixed interval reported on both blood volume and skill usage, server record
The end of a single inning, reporting the outcome relationship

Based on these two points, we can know a certain frame of the player's blood volume, everyone reported their own and each other, two-way verification can be seen whether there is cheating behavior. What bothers him is that when there are only two people, it is more troublesome to judge who is cheating. When more than two people, you can arbitrate.

We do a bit of fault tolerance, when the outcome of the result is abnormal, only to further check the reported record to judge the cheaters, sentenced to lose. For cases where the escalation data is inconsistent but the outcome is consistent, the log is logged to diagnose (prone to version changes) issues.

With real-time detection, it is possible to detect cheating in a single office (acceleration, unlimited CDs, lock blood, etc.), as they eventually result in inconsistent data between the two parties and inconsistent settlement or escalation of blood volume.

A non-real-time statistical anti-cheating scheme

Statistical anti-cheating can be useful when there are loopholes that can be exploited but cannot be positioned for a while. The loophole here refers to the behavior that causes the game to end unexpectedly due to an unknown cause such as dropping the line or not sending the package through some kind of behavior.

When we settle in the game, the non-normal winning (drop line, etc.) will be recorded and act on a penalty mechanism.

There is an upper limit on the number of abnormal wins per day, and the abnormal win will not be counted when the upper limit is reached.
The number of abnormal wins plays a role in real-time detection logic, and if the data on both sides is inconsistent, the player who wins more than normal fails.
The number of abnormal wins affects the player to enter the match, the higher the number of times required to wait longer to start matching.

This program has played a role online, effectively blocking a small number of abnormal players to exploit the vulnerability, reducing its impact surface.

Something

The technical implementation of the game's real-time PvP is described above, with a frame composition and a look at its periphery.

There are two points to note:

• TGW's multi-pass access supports the UDP four layer, and the UDP service needs to listen for all Tunel ip/port.
• The principle of frame synchronization requires that we must refine the match. The game is binary version + resource version consistent to match each other, you can do more fine-grained according to the two sides of the ninja client data hash value is consistent matching.

This paper introduces the basic technology of real-time PvP, some optimization methods and the diagnosis of difficult problems on the line, which are limited in length and listen to tell.

Action Hand Tour real-time PvP technology revealed (server article)