QUAKE 3源代码审查：网络模型

本文主要是介绍QUAKE 3源代码审查：网络模型，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！

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） - > xnetField_t entityStateFields [] = {{NETF（pos.trTime），32 }，{NETF（pos.trBase [0]），0 }，{NETF（pos.trBase [1]），0 }，...}

这部分的完整的代码中可以找到snapshot.c的 MSG_WriteDeltaEntity。Quake3甚至不知道它是什么比较：它只是盲目跟随entityStateFields索引，偏移和大小...并通过网络发送差异。