如题 目前在处理一个同步问题
因为需要模拟物理，目前的同步方式是以一个客户端的地图为主的。当两个客户端联机对战，会随机一个主客户端（称为A1），另外一个客户端（称为A2），A1同步速度到A2，且消息是A1转弯时，将需要旋转到的角度以及此时的位置通过服务器发送给A2。A2收到消息后先进行位置的核对，以很快的速度回到同步的位置，也就是位置A1转弯的位置，之后进行转弯处理。
目前非转弯状态是正常的，但是当A1转弯时，发送给A2的过程，服务器假设有200ms的延迟，200ms后，A2收到了转弯消息，但在0-200ms的这个过程中，A2已经以原来的速度直行了200ms，会闪现回到A1转弯时候的位置，然后转弯，且此时的速度越快，走得路程越远，闪现的距离越快。看起来就很不协调。
请问 如何去缓解这个闪现的情况呢。
不要直接闪现过去，而是追逐插值到目标点，当你A2 收到转弯信息的时候，你模拟一个看不到的As退回到原位置并且转弯。然后A2 以当前的位置转弯追逐As（在你规定的时间内，例如300ms追上），追上后就不需要这个As了。
好的好的 感谢回复 
其实不想多开一个As去模拟碰撞，对这边整体性能会有一定的影响，请问还有其他的方法吗 
两个客户端必须完全同步吗？被同步的那个客户端慢一点跑，先缓存一点数据
怎么能让客户端去承担另一个客户端的延迟 要就平等承担用服务器状态同步或者帧同步，而且你的同步逻辑就有点问题，为什么A2同步A1的时候还让A2有本地计算，在你延迟的时候A2就不应该动了，等下一次同步信息到达A2，A2才继续根据原点和下一个同步点且是否拐弯的逻辑进行缓动才正确
他那个模型是一个客户端就是服务器，状态同步另外一个客户端就有延迟问题，帧同步的话整体都有延迟问题会影响一点手感。
“在你延迟的时候A2就不应该动了”， A2本身在高速的跑。如果那时候不动，肯定直接就顿一下了。我感觉他在做的是类似赛车的游戏，直接停着等命令感觉上不太好。
各自管理各自，不对其他客户端数据核对，让服务器做数据核对，转发
其实赛车游戏，也可以试试p2p。不发单个转弯命令。
每个客户端控制己方车辆，跑己方车辆的物理控制器，并用udp狂发己方车的定位位置和速度包到另外的客户端。对非自己控制的车，只作为障碍物，每时每刻收到同步包，都给对应的车进行位置和速度缓动插值。
会有一定延迟和不同步，不过大致上轨迹会比较平滑一点，因为一方面是插值，另一方面是命令的频率比较高，不会累积太多误差。
这边有试过狂发同步信息，就是信息太多会导致另一边消息处理堆积处理不过来。因为需要同步的数量一多，消息就疯狂的加了。只有一两个的时候 效果确实挺好的。
直接停顿的话也感觉是蛮奇怪的。
各自管理处理 就是两边数据差异比较大的。
物理帧同步吗？