Various synchronous learning notes

Frame synchronization
One sentence summary ： The server only forwards , damage , The location is calculated by all clients （ In the same version ） Independent computing , If the code is correct , Then the calculation results will be consistent .
advantage ： Reduce server pressure , High accuracy .
shortcoming ： Long reconnection time , Easily out of sync ( The calculation results are inconsistent ), Floating point numbers cannot be used to calculate ( Floating point numbers may not be correct after being transmitted over the network , Even if the same machine is assigned floating-point numbers several times, it will be different ).
Some big guy's explanation ：
Synchronize user events at each frame of the game , After broadcast by the server , Simulate state changes on each client . Since only user events are synchronized , So network The transmitted data block is relatively small , Synchronized and timely , very Suitable for fighting games This kind of game needs to do accurate simulation . And because only events, not States, are synchronized , therefore The data transmitted on the network has nothing to do with the number of objects in the game , Compare Suitable for games with more game units , Such as timely strategy game . For a single user , Because the network transmission is often unstable , Often affect the stability of simulation , This causes the rendering to jump (jitter). In order to deal with this problem , It tends to introduce The event buffer To smooth network transmission . But this affects the timeliness of the simulation . And because there is no state , So when it is necessary to disconnect and reconnect , Often because the client needs to complete all previous simulations again , therefore Longer reconnection time . For multiple users , Because for Keep everyone synchronized , It is often necessary to wait for the slowest client , Thus, the whole game is very vulnerable to the network delay of a single user . and Only synchronize Events , It is often difficult to prevent fraud . Of course, the most troublesome problem is to ensure the consistency of the client simulation , So this model is sometimes called Deterministic Lockstep. Including pseudo-random operations using the same random seed , Do not use floating-point arithmetic, etc . Usually, LAN games use this strategy . Age of Empires , Glory of Kings , And famous DOOM, All use this strategy .
Snapshot synchronization
I'm not sure about that .
Some big guy explained ：
This is C/S The simplest synchronization strategy in the pattern . The client sends events to the server , After the server completes the simulation, it periodically synchronizes the snapshots of all States to the client . Because of all The simulation is on the server side , This strategy is easiest to use to prevent deception . And in this mode , All clients can be viewed as a state of the server terminal, So it is the easiest to implement . The best aspect is not affected by the network jitter of a single user , However, users with faster networks often have greater advantages . Because you want to synchronize the states of all GameObjects , Therefore, the data packets transmitted through the network are often large , Unable to achieve real-time synchronization . In order to cope with packet size , Some compressed coding methods are often required , such as Delta Encoding. In order to cope with the delay , You need to be right about snapshot Conduct Interpolation and Extrapolation. In order to ensure smooth motion in the game , Will use more complex difference algorithm , But it is often easy to appear unnatural . This strategy is usually used by The game status is relatively small , Games that do not require high real-time performance . Many are based on HTTP The game of agreement , All adopt this strategy .
State synchronization
This is the easiest strategy to think of and the most difficult to implement . Both the client and the server simulate state changes , After the client sends the event to the server , Forecast status changes locally . After the server receives the status , On the server Do the same simulation , then Pass the changed state back to the client . For objects that do not change , The client remains in its original state （ Moving or stationary ）, For changed objects , The client is subject to the return of the server . There is often a delay in the status return of the server , therefore After the client receives the new status , Replay events after the synchronization point . The advantage is , Whether it's the content of the transmitted data 、 size , The frequency of synchronization can be adjusted , So we can find a good balance between the precision of simulation and the efficiency of simulation , And because in The client also performs simulation , Users often receive more timely feedback , And the experience is better . However, because the server side and the client side should run the same simulation , Therefore, there is also the problem of two terminal synchronization . Last , In fact, the above agreement , Just let the player's status synchronize . The key to real-time performance lies in the network , So in order to approach real time , Need to minimize network latency , Including reducing the amount of data transferred , Use UDP To avoid TCP The retransmission Problems, etc. . In addition, in order to make the player's actions feel like real-time synchronization , Often rely on local Extrapolation.