Action Hand Tour real-time PvP frame synchronization scheme (client)

Action Hand Tour real-time PvP frame synchronization scheme (client)

1. Overview

1.1. Frame synchronization scheme based on UDP

In the selection of technology, the reason for the selection of frame synchronization scheme , in Kevin's introduction of PvP frame synchronization backstage implementation of the article has been described in detail, here a brief summary of the following:

High consistency . If the input of each frame is synchronized, in the same context, the calculated result should also be synchronized.

low flow consumption . In addition to frame synchronization, other scenarios (such as state synchronization) want to achieve high consistency and need to synchronize very large amounts of data. Whether it is for mobile networks, or for the solid collateral is not appropriate.

server logic is simplified . With the frame synchronization scheme, the server only needs to do simple frame synchronization and does not need to care too much about business details. Benefits the extension of client functionality and server stability and performance.

against cheating . The client only needs to escalate the checksum data to the server at the appropriate machine, and the server can quickly identify if anyone is cheating by comparing the data reported by 2 clients. And then indirectly prevent cheating by means of no income .

So why choose UDP instead of TCP. There are 2 main reasons:

Weak network environment .

Real-time requirements .

We use a test app, in WiFi and 4G environment, TCP and UDP two ways to connect the same server, respectively, to obtain the corresponding RTT comparison.

We can see that in a weak network environment, the RTT of UDP is almost unaffected. The RTT fluctuation of TCP is relatively large, especially the impact of packet loss rate is obvious.

1.2. FSP protocol stack based on UDP

Due to the unreliability of UDP, a custom stack of protocols is implemented on the basis of UDP: FSP, or Framesyncprotocol.

The basic principle of FSP is the ack/seq retransmission mechanism of the anti-photo TCP, which realizes the reliability of transmission, and also adopts the way of redundancy changing speed , and guarantees the speed of transmission. Kill each other in the frame synchronization scheme.

2. Technical principle

2.1, Frame synchronization technology principle

As shown in the following illustration, client A's operations A1 with Client B's operations B1 encapsulated into Operatecmd data sent to the PVP server. The PVP server generates a logical frame every 66MS, and after receiving A1 and B1 within the time period of the frame, generates a frame data block, which is sent to clients A and b at the end of the frame time. The frame data block has frames in the frame number. After the client A and B receive the frame data, they know what the client A and B have done in the frame. Then according to the received Operation A1 and B1 play performance, the final presentation to the player A and B results are consistent. To achieve client A and B data synchronization.

Fig. 1 Principle of frame synchronization technology

2.2, FSP protocol stack principle

As the following illustration shows, the sender maintains a send queue, numbering each time it is sent. Each time it is sent, the data to be sent is written to the queue. Then send the data + number in the queue to the recipient.

When the recipient receives the data, it is sent back to the sender for confirmation. When the sender receives a confirmation number, the packet that corresponds to the number is removed from the queue, or the data is still saved in the Send queue.

The next time you send, new data will enter the queue. The data in the queue and the latest number are then sent to the recipient. Repeat with this loop.

Fig. 2 Principle of FSP protocol stack

The diagram above resolves:

The 1th time sent, in the Send queue only Data1, so Data1 and number 1 (seq=1) sent to the receiver. After you receive the confirmation number 1 (ack=1), remove the Data1 from the queue.

The 4th to 7th time, because the confirmation number was not received since the 4th send, the queue contains Data4 to Data7. After the 7th time, the confirmation number 6 is received and the DATA4 to Data6 is removed from the queue.

8th time, the queue contains Data7 and Data8. Receive confirmation number 8 after sending to remove Data7 and Data8 from the queue.

The above key point is that the sender does not receive the confirmation number, does not wait, but will continue to send the next time . Combined with Figure 1:

If the sender is a server, a frame data is written to the send queue every 66MS and then sent to the client with all the frame data of the team column.

If the sender is a client, each of the player's Operatecmd data is written to the sending queue when the player has an action, and then all the Operatecmd data from the team is sent to the server along with the column. If the send queue is not empty, it is sent repeatedly at 99MS intervals. If the send queue is empty, it is no longer sent. Until the player next action.

Because the server and the client are both senders and receivers. The server and the client send each time, in addition to the number that will be sent on the same time, and with an acknowledgement of the sender's number.

3, Technology implementation

3.1, the overall framework

Fig. 3 The overall framework of the PVP communication module

This is a typical hand-travel PVP Communication module for the overall framework. Here the main share of FSP module and frame Synchronization module technology implementation.

3.2. FSP Module

FSP module is mainly used to implement FSP protocol stack. The protocol format is defined as follows.

FSP Uplink protocol Definition:

Figure 4 FSP module receive logical Flow

Among the key points are:

For Recv New Ack judgment, the operate that has been sent has been confirmed for deletion.

Judge Recv New Seq , filtering out packets that cause chaos in the network problem.

In the figure above, the received frame is eventually stored in the Recvqueue. We put the receive logic in the child thread . So it is only necessary to read the fremelist from the Recvqueue in the main thread when the recv is needed.

As shown in the following illustration, it is the routing logic flow of the FSP module. The sending logic is also placed in the child thread . There are 2 ways to trigger the sending logic:

Business Layer Unsolicited call send

Trigger once at a specified time (using a different time at WiFi and 4G to reduce the percentage of pure confirmed packets received by the server, which is conducive to improved communication performance)

Figure 5 FSP module to actively send logical process

Fig. 6 The FSP module sends the logical flow periodically

3.3, frame synchronization module

The following diagram is the framework of frame synchronization module.

Fig. 7 Framework of Frame synchronization module implementation

Follow the arrow numbers above to describe the following:

(1) responsible for receiving the framelist from the FSP module.

(2) Every 1 frames in the framelist are deposited into framequeue.

(3) At the same time, the frame number of every 1 frame of framelist is transformed, and the client frame number is obtained. Also, you need to lock the client frame to the previous frame of the next 1 server frames (Lockframeindex) before waiting for the next 1 server frames to arrive. The FrameIndex and Lockframeindex are then passed into the framebuffer.

(4) The client takes out every 1 frames from the framebuffer the current multiple (speeduptimes) that may require a jump frame acceleration.

(5) If the speeduptimes is 0, it means that there are no frames in the buffer that need to be processed. If the speeduptimes is 1, the buffer ends, but no acceleration is required, and only the latest 1 frames need to be processed. If the speeduptimes is greater than 1, remove the speeduptimes frame from the framequeue and take out the synccmd inside.

(6) The Synccmd will be passed into the operationexecutor.

(7) Operationexecutor is associated with the business logic of the specific game, and is responsible for the specific processing of the synccmd into the business logic and the pre performance module.

Its flowchart is as follows:

Figure 8 Frame Sync Logical flow 1

Figure 9 Frame Sync Logical Flow 2

4, the latest optimization

4.1, disconnection of the connection optimization

In the traditional network module development idea, when the send timeout to reach the threshold, or the bottom of the decision to disconnect , you need to re-establish the connection. Before this part of the work is to a partial upper layer of the module to perform, the module needs to wait for the Apollo communication module connected successfully after the PVP communication module connection. This complicates the logic.

because of the unreliability of UDP itself, it can be considered that network disconnection is also a part of its unreliability .

The FSP protocol stack is designed to solve the unreliability of UDP, so it also solves the problem of disconnection and connection .

After removing the original disconnection connection logic, the FSP module itself is used to deal with the disconnection, and the measurement can improve the response speed of the network recovery . Because the PVP server set the timeout threshold is 15 seconds, sometimes, in fact, the network has been restored, but because the Apollo communication module on the network recovery response is too slow, resulting in unnecessary loss.

4.2, access to GSDK

From the data after the current access to GSDK, can reduce the network latency, but not obvious.

4.3, ackonly optimization

Ackonly optimization refers to the reduction of pure acknowledgment packet data received by the server. The purpose of this is to:

reduce the amount of packets to help save router performance in WiFi. GSDK has a statistic that suggests that more than 20% of the network latency is due to router performance.

Save the flow , to some extent, can also save network equipment performance, at the same time save money for users under 4G.

The optimization is implemented in 2 parts:

(1) null frame without confirmation

(2)WiFi delay Confirmation

The ackonly ratio before the optimization is: 57%
Null frame zero-confirm optimization down to: 38%
WiFi latency confirm optimization down to: 25%

5. Some attempts

The FSP module is abstracted from the business, making it possible to quickly complete a demo that uses the frame synchronization scheme to communicate.

Experimental local LAN PvP game, as long as the same network segment, you can successfully game. (This functionality can be implemented if there is a requirement)

The local Bluetooth PvP game was tested, and the Bluetooth was found to be in a connected state, and its communication was carried out in a TCP-like data stream. At the same time it has interference with WiFi signals, and if WiFi is turned on, the delay is very high. In non-wifi, the delay of a single data is very low, but if the 66MS frequency of data transmission, the delay is very high.

A set of tools for FSP on-line diagnosis and disconnection Diagnosis is established.