主要涉及复杂服务器模型的讲解的游戏就几种经典的

MMO massively multiplayer online game，MMORPG role-playing games

FPS first person shooters。还有 RTS Real-Time Strategy Game。

回合制游戏总是最容易实现的，同步问题都没有，到点了才更新状态或者都是持续更新单人状态。

游戏数据类型

一个游戏最有可能给数据进行分类的话：

• 非保障数据
• 保障数据，保证可靠以及正确
• 最近数据，最新的是保障数据，旧的没那么重要
• 最快保障：移动等决定性状态更新。

服务器层次结构

CS 模型 V.S . P2P 模型，一个是集中式一个是分布式，分布式对带宽的消耗很大（全连接），外加 NAT 原因，大型游戏基本都用 CS 模型。P2P 的本质其实是运算在所有的客户端都演算一遍的。CS 则是在 server 上运行游戏，客户端负责渲染（交互）。

首先讲解的 Starsiege: tribes 游戏（MMOFPS）里

下图是这个游戏的整个架构：

• 层次结构是 socket api -> connections manager -> stream manager-> 中间层 manager -> game
• 这里中间层的 manager 用来管理数据包的保障性并且依据情况进行重传等操作（移动、事件等），事件管理器本质上是一个事件触发回调 RPC 的消息队列，然后流管理器会负责把这些 RPC 发出去（比如伤害等于对某个角色回调伤害成员，即 RPC 了）。ghost 管理器是管理玩家的信息的，而对于 128 玩家同屏来说，是有优先级的，如果服务器每次都要同步了 127 个用户的包再发过来肯定是不靠谱的。移动管理器是保证移动数据正确的，不然伤害什么的都会出错。
• 连接管理器是用来管理 socket 的，而不用每次调用 socket api，相当于 buffer pool？（可能有流控和 ack）
• 流管理器是为了每次把一堆数据发出去，而不是一个数据发一个包，（这个角度看 UDP 的  datagram 也可以当成流用了）所以他要把上层各种事件管理的数据封装成流，然后传给连接管理器发出去

然后是  RTStrategy 例子 Age of Empires（回合制）

• 书本这里比较简略，这里有一个具体的帧锁定的算法描述（知乎用户韦易笑）：

帧锁定同步算法 - Skywind Insidehttp://www.skywind.me/blog/archives/131

• 确定锁同步网络模型，deterministic lockstep，P2P，但是必须处理 NAT 的问题，最后还是要服务器转发（之前计网速通指南讨论过了 nat 打洞并不能保证成功）。lockstep 同步的是每个节点（aka 玩家）的命令，而不是对每个事件（或者物体单元）都发送一次。这个模型的具体这里有个综述：网络同步在游戏历史中的发展变化（二）—— Lockstep与帧同步_Jerish的博客-CSDN博客 有时间可以把参考连接都读了。这个之后书本专门有个章节讲，不知道还要不要整理那部分笔记。
• 延迟问题，对于 A 要执行命令进行客户端 play 的时候，必须保证接受完来自其他客户端的消息。才能进行模拟。
• 轮班计时器，命令缓存，每 m 毫秒广播一次清空缓存队列。直观看是增加了延迟，但是全局来看的话，这样能够保证时间窗口内的命令能够被各客户端同步并且确认，之后本地模拟执行。星际争霸也用这种方法。这种方法的还有好处是不用协调各种同步的东西了。所以确定性的意思就是保证这每轮采样是确定的。
• 覆盖操作不过键盘操作还是要，因为覆盖操作必须是最新的，而且需要保证发送，比如军队移动等，这种数据直接有键盘事件就可以发送，也不用进行同步，直接覆盖就行了。（额，对于进入同一个地方导致 overlap 的话还是要同步的）。
• 指令模型的另一个好处是可以 replay。（这个其实就是通常说的帧同步 对比 状态同步）
• 然后对于十分延时的问题，只能把玩家踢出去了。踢出去之前可以进行暂停检测，如果等待超过某个阈值就踢了，没办法了。
• 同步问题，一个是事务的有序性，这个我感觉可以用数据库的 serializeable 的方法 2PL 什么的来弄吧，也不用 abort，就直接 restart 就行了，这样能保证最后指令执行在一个可串行化的顺序就行了。然后是游戏里必须使用伪随机数生成器保证所有终端的模拟都遵循一致的 “随机性”。
• p2p 的另一个好处是检测作弊方便，区块链可追溯属于。

帧同步和状态同步（前面这个猫猫游戏的demo例子是状态同步）概念澄清

• 前面其实讲过一次，但是书本的概念不是很清晰，这里补充一下。
• 帧同步的实现是定义逻辑帧（锁同步?），服务器的作用是用来同步指令，然后发送，客户端本地按顺序演算，支持战斗回放。就是前面说的确定锁同步网络模型。
• 状态同步是服务器运算说有点状态，然后计算好下一个的状态再返回给客户端同步全局状态。
• 但是状态同步和客户端先行不是同等级别的概念，为了防止客户端看到操作和结果之间时间点的割裂，必须再画面表现上优化，客户端先行、平滑插值等在表现上降低对延迟的感受。这里的机器猫完全没有这个实现。RPG游戏中，动画的特效一般做的比较长时间，看着好看同时延长网络响应时间， 攻击的时候给人感觉是击中了。放技能也有一个前摇，同时将攻击请求提交给服务器。等服务器结果返回时，动画也播放完毕了，之后就是更新状态和 HUD 而已。
• 还有一个问题是反作弊，对于 RTS 和帧同步的方案，只需要定时服务器（或者某个客户的托管服务器，或者大家）校验一下就行了，但是这个只是防止了数据作弊，对于信息泄漏的话可能无解，因为运算和所有数据都在客户端，完全可以全部 dump 出来，包括视野信息，以及透视等。而状态同步不会泄漏运算流程。
• 然而对于手游，客户端运算才能保证在各种无线网络下的延迟问题，这是和网络因素决定的（就和 TCP 的基础设施反而和网络不相适应导致要定制 UDP 一样）。这种反作弊的确就用校验可以解决，最常用的做法验算，确定客户端随机数种子，还有客户端操作。那么记录正常战斗的数据，放到其他客户端去验算，看看验算能否通过即可。
• Realword 部分，王者荣耀，皇室战争是帧同步，魔兽用的是帧同步，lol 可能是状态同步（没有相关信息，但是好像本地会有 cd 信息，存疑），dota 用的是帧同步。

世界状态

这涉及到对象的复制。为了成功复制一个游戏对象，一般有三步：

• 标记数据包是包含对象状态的数据包。
• 唯一标识复制对象。
• 指明被复制对象的类型。

定义数据包

• 对于一个数据包他可能是包含多种数组的，，，
• 用一个 enum 来标识他。所有对象都用一个不可重复的标识符->> 单线程自增 uint 就行了。
• 如果有40亿就用两个uint，这样就有 1600 亿个对象了，哈哈哈哈。

精细反序列化

• 对于已经存在的对象，就不创建了。如果不存在，才反序列化。
• 类的类型名字，这个特别耦合
• 用 if dynamic cast 判断类型是因为他会返回 null 指针（我竟然不知道/没印象）。
• 不能用 dynamic cast，RTTI 禁用。我差点忘记 RTTI 是什么了，就是虚函数表里面再存一个 typeinfo，这样就能运行时 dynamic cast （记住 decltype 是 compile time 的，rtti 不过 dynamic 和 typeid ，异常而已）到不同的类型，并且能返回 runtime error。游戏里不开启 RTTI。

对象创建注册表 object creation registry

• 大量的时候用 GUID 做 id
• Unreal 的 C++ 由于是深度定制的，所以完全支持四字符 int, int a = 'GOBJ'.
• 对于标准而言这个是 implementation define 的，gcc ，msvc 支持。然后其实要求 I32 才行，比如 ILP32。I32+LP64. 然后可以用 uint32_t . 又没办法手动写转换,,,, 可以试试宏。
• 代码5.7 ObjectCreationRegistry，用模板直接注册其成员函数。-> 学到的知识点是虽然 C++ 没有能把类型作为对象的机制，但是模板就是啊！学会了！而且用上宏和配置文件，可以自己外面维护一个 map 表格，然后自己编译成宏（用 perl 就行了）再宏展开得到批量注册代码段。

MTU 问题，一个包尽量传多点数据。

整个世界复制过程（TCP？可靠 UDP！）

• 序列化游戏中的对象
• 有必要的时候覆写和创建
• mark and sweep 垃圾清理（server 上总是最新的世界），渲染的话另说。
• 增量世界复制 -> 对于更新或者覆写传输 command 而不是序列化的对象。对于创建也省去了一次 map 的查询（额，本来也很快，除非他是线性探测哈希）。
• 鲁棒性，必须考虑不是 create 命令的时候也有找不到对象的情况，由于这种情况必须跳过流/offset，必须还是反序列一个 dummy，或者传的时候添加一个 len hdr。
• 更加紧密的版本控制涉及 bitmap （然而反序列的时候反而引入一堆 if else，只能说是 S-T trade off 问题，而且 S 太大本身也增加 T 了），不知道 git 那些是怎么 diff 文本的了属于。

RPC I，为什么要用 RPC（这段主要从网络资料学的）

RPC 的概念是网络编程基础，这里不赘述。

这本书还手把手教做 RPC 框架的，也是可以

• 我有点抽风，没有理解为什么应用层有了 http 还要做 RPC，RPC 本身是包括传输+序列化的。然后 gRPC 他本来就是用 http 来做的。
• 所以为什么要做 rpc 呢？一个是 http 的头部很垃圾。然后rpc 库主要还要提供高级的特性，而不是简单的传几个包。这些服务包括服务注册和发现，负载均衡和熔断等东西的。
• 而且历史上是先解决了 RPC （80s）再做网页（90s）的。HTTP 也可以认为是一种 rpc 了，特别是 http2 之后性能好带宽开销少，要么用上 protobuf 这种二进制本质也是为了节约 http 这种文本的。
• 而且要明确 http 解决的重点问题不一样，如果用的话就等于为没用到的功能付钱，http 在缓存、幂等重试乃至 Cookie 这种浏览器安全相关的方面做了很多功夫。网络环境不同可能有一些不同的协议冒出来，像现在面向移动网络，http2 在减少 RTT、优化长连接（吃我推送拉日活），而 RPC 还是说想专注微服务那边去优化的。
• 然后说 http 短连接的时候，他可能是乱序的，所以不如直接用 tcp 长字节流来做 rpc 了。
• 还有安全问题，一个是 ssl 保密，一个是 ddos，对于不通用的协议难背攻击。http 解码也垃圾（字符串行和分隔符分割，unp里面已经体会过要 read line 来 parse 的麻烦了）。http 保活难讲。（额，http2另说）
• 比如 dubbo 的功能高级用法 | Apache Dubbo
• 真的有点吓人：启动时检查（服务），序列化安全（安全的序列化而已），集群容错（集群挂了重新调控），负债均衡，线程模型，p2p 直连，只订阅（绕过注册中心测试本地），多注册中心，结果缓存（lru那个 递归 memo），泛化 mock 调用（就是不用知道 api，通过 kv pair 调用），上下文信息 （寄存器快照），异步执行 (直接返回)，异步调用（队列等待，定时），参数回调（服务端调用客户端，反向代理），本地存根（让客户端也可以执行部分逻辑，本地 stub 存根，这个这里没解释清楚，下面再讲一遍），tls，路由规则（调整负载均衡的东西吧，和之前配路由器一样），日志，分布式事务，IDL 交互式数据语言…… 我晕！！！

RPC

• 首先是 RPC over 我们之前做的 replication（复制世界的意思） 流包上，然后让 replication 接收到 RA_RPC （包头的 flag）就路由（我说的路由可能就是 dispatch 的意思，有点概念杂糅了）给 rpc manager 负责解包。然后每个 RPC 都做一个解码器才行。注册的时候就只需要提供接口！即几个 key ，一般做一个结构体定义在客户端就行了。
• 然后胶水函数必须生成的。客户端需要胶水，这些胶水是把参数写进流里。而服务端需要胶水
• 用C++实现一个RPC框架 - 知乎 (zhihu.com)
• 关于这个 stub 是什么我在补充一下，stub 本质上就是胶水，因为本地调用 rpc 的时候实际是通过一个 stub 调用（或者说他叫 proxy？代理人做一层 wrapper 或者说 adapter）的，然后 stub 发给服务器解包再调用。看了一些自己的 rpc 的实现，基本都要宏来实现或者进行一些字符串替换！字符串替换的话可能会比做编译语法分析简单。如果用 json 的话需要自己的 json 库。
• dubbo 的本地存根的意思是本地再 hook 一次，让 rpc 调用，可以用来做 local 缓存，过滤异常参数。我很好奇为什么要这样做？直接先检查参数再调用 rpc 不好吗？为什么要通过框架来配置？我大概懂了，因为实际调用的时候都是直接通过 dubbo 获取远程的服务类然后进行调用的（getBean）这个相当于不用调用 wrapper 直接 hook，相当于装饰器吧，不用改变原来的代码就能 hook 一个 middleman 过来。（就跟 linux 要提供 LD_PRELOAD 和 gcc 支持 --wrap f 支持库打桩一个道理吧）
• 但是游戏里面需要不止远程过程调用，需要远程方法调用，基本 Java 那种的，RMI 远程方法 invocation。这样还要涉及 this 指针，对于 C++ 来说由于实现差异，只能用 C++ 11 的 function 来实现第一个参数 this 指针了。RMI 需要作为标识符，这个标识符可以沿用我们之前说的那个 four chars uint32.

第六章开始就是作者做的 demo 不断改进的一些分析了，感觉是很多《 XXX in practice》书籍风格的内容 ，尽管这部分我跟进运行了demo 和阅读了源码也做了笔记，但是由于笔记内容和源码比较紧密，读者没有上下文信息一头雾水，我直接 po 上来没有用，可能需要额外整理一下。

随书配套的源码，支持 vs 和 xcodehttps://github.com/MultiplayerBook/MultiplayerBook

这本书还是比较基础的，但是的确能学到很多内容，在刚刚看完 UNP 两卷基础 API  和游双的高性能服务器前半部分（到目前我只是看了 linux 特色 api 和做了些小型程序编写而已）之后其实对真实网络应用的开发还是有点模糊的，这个的确是个不错的学习材料。