QUAKE 3源代码审查:网络模型(第3部分,共5部分)>>
Quake3的网络模型无疑是引擎最优雅的部分。在较低的级别,Quake III仍然与首次出现在Quake World中的NetChannel模块进行抽象通信。要了解的最重要的一点是:
在快节奏的环境中,任何第一次传输都没有收到的信息不值得再次发送,因为它太老了。
因此,引擎基本上依赖于UDP / IP:由于“可靠传输”方面引入了不可容忍的延迟,所以无任何TCP / IP跟踪。网络堆栈已经增加了两个相互排斥的层:
- 加密使用预共享密钥。
- 用预先计算的huffman键进行压缩。
但是,在设计真正闪耀的地方在服务器端,优雅的系统最小化每个UDP数据报的大小,同时补偿UDP的不可靠性:快照历史通过内存自省生成三角洲数据包。
建筑
网络模型的客户端相当简单:客户端向服务器发送每个帧的命令,并接收gamestate的更新。服务器端更复杂一些,因为它必须将Master gamestate传播到每个客户端,同时占用丢失的UDP数据包。该机制具有三个关键要素:
- 一个硕士的游戏玩家,是事物的普遍真实状态。客户端在Netchannel上发送他们的命令。它们在event_t中被转换,当它们到达服务器时,它将修改游戏的状态。
- 对于每个客户端,服务器保持通过网络在循环阵列中发送的最后一位玩家的32位:它们被称为快照。数组周期与着名的二进制掩码技巧我在Quake World Network中提到(一些优雅的东西)。
- 服务器还具有一个“虚拟”gamestate,每个单个字段设置为零。当没有“先前状态”可用时,这用于增量快照。
当服务器决定向客户端发送更新时,它会使用每个三个元素来生成一个消息,然后通过NetChannel进行传输。
琐事:为了保持这么多的玩家每个玩家消耗大量的记忆:根据我的测量,4个玩家8 MB。
快照系统
为了了解snaphop系统,下面是一个具有以下条件的示例:
- 服务器正在向Client1发送更新。
- 服务器正在尝试传播具有四个4个字段(3个位置[X],位置[Y],位置[Z]和一个健康状态)的Client2的状态)。
- 通过UDP / IP进行通信:这些消息在Internet上经常丢失。
服务器框架1:
服务器已收到每个客户端的一些更新。他们影响了大师(绿色)。现在是将状态传播给Client1的时候了:
为了生成消息,网络模块将始终执行以下操作:
- 在下一个客户端历史记录槽中复制Master gamestate。
- 将其与其他快照进行比较。
这是我们可以在下图中看到的:
- 在Client1历史记录中的索引0处复制Master gamestate:现在称为“Snapshot1”。
- 由于这是第一个udpate,所以Client1历史记录中没有有效的快照,因此引擎将使用所有字段始终为零的“虚拟快照”。这将导致全部更新,因为每个单个字段都将发送到NetChannel。
要了解的重点在于,如果客户端历史记录中没有可用的快照,则引擎将选择“虚拟快照”以生成增量消息。这将导致发送到使用132个比特(每个字段是客户端的完整UDPATE 由位标记preceeded): [1 A_on32bits 1 B_on32bits 1 B_on32bits 1 C_on32bits]
。
服务器框架2:
现在让我们及时向前推进:这是服务器第二帧。正如我们可以看到每个客户端都发送了命令,并且它们影响了主机:Client2已经在Y轴上移动,所以pos [1]现在等于E(蓝色)。Client1还发送了命令,但更重要的是它也确认接收到以前的udpate,所以Snapshot1被标记为“ACK”:
进程是一样的:
- 在下一个客户端历史记录槽中复制Master gamestate:(索引1):这是Snapshot2
- 这次我们在客户端历史记录(snapshot1)中有一个有效的快照。比较这两个快照
因此,仅通过网络发送部分更新(pos [1] = E)。这是设计的美丽:过程总是一样的。
注意:由于每个字段 前面都有一个位标记(1 =已更改,0 =未更改),上面的部分更新将使用36位:[0 1 32bitsNewValue 0 0]
。
服务器框架3:
我们再向前迈进一步,以了解系统如何处理丢失的数据包。现在是第3帧。客户端一直在向服务器发送命令。Client2已经失去生命,现在健康现在等于H.但是Client1还没有确认最后一次更新。也许服务器的UDP丢失了,也许客户端的ACK丢失了,但底线是不能使用的。
不管过程如何,
- 在下一个客户端历史记录槽中复制Master gamestate:(索引2):这是Snapshot3
- 与上一次有效的确认快照(snapshot1)进行比较。
因此,消息将其部分发送,并包含旧更改和新更改的组合:(pos [1] = E和健康= H)。请注意,snapshot1可能已经太旧,无法使用。在这种情况下,引擎将再次使用“虚拟快照”,导致完全更新。
系统的美丽和优雅在于它的简单性。自动相同的算法:
- 生成部分或全部更新。
- 重新发送未收到的OLD信息和单个消息中的新信息。
记忆反思与C
你可能想知道Quake3如何比较快照与内省...因为C没有内省。
答案是,a的每个字段位置netField_t
都是通过数组预先构建的,还有一些聪明的预处理指令:
typedef struct { char *名称 int offset; int 位; } netField_t; //使用字符串运算符保存键入... #define NETF(x)#x,(int)&((entityState_t *)0) - > x netField_t entityStateFields [] = { {NETF(pos.trTime),32 }, {NETF(pos.trBase [0]),0 }, {NETF(pos.trBase [1]),0 }, ... }
这部分的完整的代码中可以找到snapshot.c的 MSG_WriteDeltaEntity
。Quake3甚至不知道它是什么比较:它只是盲目跟随entityStateFields
索引,偏移和大小...并通过网络发送差异。
预破碎
挖掘代码,我们看到NetChannel模块以1400字节()的块分片消息,尽管UDP数据报的最大大小为65507字节。这样做是因为大多数网络MTU为1500字节,引擎可以避免路由器在互联网上行走时将数据包分段。避免路由器碎片非常重要,因为: Netchan_Transmit
- 进入网络后,路由器必须在分组时封锁数据包。
- 离开网络时,问题更加严重,因为数据报的每一部分都必须等待,然后花费时间重新组装。
可靠和不可靠的消息
如果快照系统补偿通过网络丢失的UDP数据报,则必须保证一些消息和命令被传递(当播放器退出或服务器需要客户端加载新的级别时)。
这个保证被NetChannel所抽象:我几年前就写过(哇,我的图纸已经走了很长的路)!
推荐读数
开发团队的成员Brian Hooks 写了一点关于网络模型。