Games104网络基础部分

面临的挑战

实现网络物体一致

网络延迟 网络掉线和重连

反作弊和防信息泄露

对于不同设备连接和实现同步 多个游戏的子系统实现同步

承载更多的用户
高并发 高可用性 高性能

TCP

优点

面向连接 可靠和有序 流控制 拥塞控制

缺点

太慢了

UDP

优点

快

缺点

无连接 不可靠和无序 没有流控制 没有拥塞控制

对于UDP和TCP的混合使用

使用在udp的连接下使用自动重传协议 ARQ和 前向纠错 FEC

ARQ

通过滑动窗口和选择性重传

在选择性重复ARQ中，只有损坏或丢失的帧被重传

接收端发送每一帧的ack，发送端维护每一帧的超时时间

当接收端收到损坏的数据包时，它将发送一个NACK，发送端将发送/重传接收到NACK的帧

FEC

XOF异或

Let E = XOR (A, B, C, D)
• A = XOR (B, C, D, E)
• B = XOR (A, C, D, E)
• C = XOR (A, B, D, E)
• D = XOR (A, B, C, E)

如果有报文丢失，可以和其他4个报文一起恢复
在连续数据传输中，只能丢失一个数据包。如果A和B同时丢失，则算法无法恢复

Reed-Solomon Codes

定制您的UDP基于ARQ和FEC

可靠性

选择性重复ARQ

混合 ARQ 和 FEC使用

在ARQ之前，采用FEC进行纠错

实时

更小的重传超时时间RTO增长
没有拥塞控制
速度重传机制
没有延迟ACK传输

灵活性

设计协议速度
支持可靠和不可靠

时钟同步

RTT往返时间

NTP网络时间协议

理想情况下，上行和下行速度一样。


现实中，不一样的处理方法

多求几次RTT然后去除最高值，取剩下的平均值。

Remote Procedure Call（RPC）

远程调用函数

Interface Definition Language接口定义语言

类似于用来两边对话的格式，例如ProtoBuf

RPC Stubs

客户端存根是一个过程，它在客户端看来就像是一个可调用的服务器过程
•客户端程序认为它在调用服务器，但实际上它是在调用客户端存根
服务器端存根看起来像服务器的调用者
•服务器程序认为它是由客户端调用的，但实际上它是由服务器端存根调用的
•存根相互发送消息，使RPC透明地发生

Stub Compiler

票据编译器
比如ProtoBuf直接做好了。
•“存根编译器”读取IDL声明，并为每个服务器过程生成两个存根过程
•服务器程序员实现服务的过程，并将它们与服务器端存根链接
客户端程序员实现客户端程序，并将其与客户端存根链接
•存根管理客户端和服务器之间远程通信的所有细节
#Real RPC Package Journey

网络拓扑结构

原始的p2p

两者进行相互连接就行
每个客户端向所有人广播游戏事件
其他人
•鲁棒性
•作弊更容易
•所有节点之间需要同步，以保持分布式游戏状态的一致性

通过建立hostServe的P2P

•玩家可以充当“服务器”，即主机
•如果主机断开连接，游戏可能会结束
•主机需要处理玩家无法控制的游戏参与者，如机器人

运用游戏如下

优点

1. 更加灵活
2. 移除多人游戏中“服务器问题”的问题。
3. 在服务器上没有额外的成本

缺点

1. 作弊就容易多了
2. 每个玩家都需要一个像样的网络连接才能让游戏正常运行
   3.只能处理有限数量的玩家

专用的服务器Dedicated Server

•权力
模拟游戏世界
•向玩家分发数据
•高性能要求高

优点

1. 易于维护以及避免作弊
2. 能否应对庞大的游戏世界
3. 游戏的响应性并不依赖于每个客户端的网络条件

缺点

1. 服务器成本高
2. 更多的工作在服务器端程序
3. 单点故障

游戏同步

Snapshot Synchronization 快照同步

基本步骤

•客户端向服务器发送输入
•服务器模拟游戏世界
•生成整个游戏状态快照
•发送给客户
•客户端根据快照更新显示

优化

对比上一帧快照只发送变化的部分

Lockstep Synchronization帧同步

步骤

帧同步初始化

加载……
•确保每个节点的初始数据客户是确定的
•游戏模型
•静态数据
•……
•同步时钟

准确性同步

•客户端向服务器发送输入
•服务器接收和排序
•等待所有客户端输入后再转发
•客户端从服务器接收数据后，执行游戏逻辑

缺点

需要全部用户都收集完成后才实现同步，出现了网慢者得利的情况。

Bucket Synchronization 桶同步

•桶:固定时间段
•每一个桶
•收集所有指示
•向所有玩家广播
•不需要等待所有玩家的命令被接收才转发

如果超时服务器将不做出反应，或滞留下一帧处理。

同步的准确性难点

•确定的
•相同的输入序列需要在所有机器上产生相同的游戏状态
•确定性难处
•浮点
•随机数
•容器和算法(排序，添加，删除等)
•数学工具(向量，四元数等)
•物理模拟(非常困难)
•代码逻辑执行顺序

浮点数

使用统一标准IEEE 754
数学库的统一，浮点编译器的情况，及运行平台的情况
解决方案:避免精度边界问题
定制精度定点
数学库查表(三角函数等)
放大和截断

随机数

使用随机种子保证每台设备的随即结果相同。

跟踪和调试

获取校验和的方法

所有数据校验
关键数据校验
其他方法

自动定位错误

服务器比较不同
客户端的校验和客户端上传50帧完整的日志
在比较的日志中查找不一致的地方

延迟

因为网络造成的延时

解决方案

使用缓冲到缓存器中

重连

快照可以定期保存在本地客户端，并序列化到磁盘
当重新连接发生时，从磁盘序列化数据恢复游戏状态
服务器在快照后发送玩家命令
加速以赶上游戏进度

怎样追赶上帧

在示例代码中，每次跟踪10帧
如果最初是每秒10帧，当追逐帧时，它可能运行每秒100帧

State Synchronization状态同步

实现：将相关的状态传给服务器，让服务器判断结果，并通知所以客户端。

比如玩家将移动和攻击这个状态传给服务器。

物体的复制协议

状态数据

保证了大多数当前状态的最终交付
对象的位置
对象的生命值

• 150 +属性

事件

瞬时事件的不可靠通知
请开枪
这把枪是开的
炸弹引爆
更多的事件

控制数据

高频，从玩家控制输入中提取的快速更新数据的最佳传输方式
当前所有玩家的模拟杆值
病人自己当前的位置
更多的属性

游戏状态

•游戏状态是表示游戏世界的必要条件。例句:HP,MP

状态同步

•服务器不会为所有客户端生成单个更新。它向客户端发送一个定制的数据包
•如果游戏世界太复杂，你可以设置一个兴趣区域Area Of Interest(AOI)来减少服务器开销

服务器授权游戏世界

服务器
•游戏世界授权
从客户端接收输入和状态
•运行游戏逻辑
•发送状态
客户端
•接收数据，模拟游戏世界
•游戏玩法改进

授权和复制的客户端

授权(1P)
•玩家的本地游戏客户端
服务器
•授权服务器
复制(3 P)
•在其他玩家的客户端中模拟角色

如玩家只能对玩家的状态进行改变，在其他客户端中出现的是复制品。

愚蠢的客户端问题

客户端在收到之前不能做任何事情
服务器状态更新
如何看到即时回应?

客户端预测

守望先锋的举例

• RTT = 160ms
• Half RTT = 80ms
• Command frame = 16ms

所以我们将预测96ms的动作。

服务器和解

授权客户端:缓冲区
• 记录客户预测时的每一个状态
• 与客户端接收到的过去服务器数据进行比较

环形状态缓冲区
•在客户端存储我们过去几帧的所有状态
过程
•如果客户端计算出与服务器相同的结果，客户端将继续其愉快的方式来模拟下一个输入

如果被服务器上的运动被障碍阻塞
• 位置错误!(红色)
• 客户端必须接受新的服务器更新
• 从新确认的位置开始回溯所有预测移动
•如果客户端和服务器对结果不一致，我们就预测错了
•必须和解
环形输入缓冲区
•在客户端上存储过去几帧的所有输入。
过程
•用服务器的结果覆盖客户端的结果
•重放你所有的输入，以跟上你现在所相信的

丢包问题

•客户端输入包无法到达服务器
•服务器试图保留很小的未处理输入缓冲区
•如果服务器耗尽了输入缓冲区，服务器将在一个窗口中复制你最后的输入
•推送客户端尽快发送遗漏的输入
当然不同游戏可能处理方案也不一样，可能直接停止了

状态同步VS帧同步

	状态同步	帧同步
是否要写进逻辑	非必要的	必要的
响应	更好的响应	较差的响应
网络流量	通常高	通常低
开发效率高	复杂得多	易于开发，难于调试
玩家数量	玩家数量少	支持少量和大量的玩家
跨平台	相对容易	相对困难
重新连接	相对容易	相对困难
重放文件大小	大	小
作弊难度	相对难	相对容易