主机失联后还剩什么

主机宕掉，对局仍能继续。本页讨论哪台机器拥有实体、下一个由谁接手，也就是“复制”的第二层含义；两层含义的区别见谁看到什么，由哪台机器运行。

房间状态不会在主机之间复制

一个实体（entity）同一时刻只有一个所有者，也没有第二台机器保留一份实时副本随时准备接管。

如果两份副本都接受同一发射击，它们就必须就两发子弹命中的顺序达成一致。在多台机器之间每秒三十次地就顺序达成一致就是共识，而共识会在游戏无法容忍的地方增加延迟。单一所有者没有这个问题，下面的每个机制都是为了让单一所有者在宕机后也能存活。

真正复制的是在线状态（presence）：哪个主体在哪个节点上。这是一个很小、变化很慢的事实，所以路由可以在各处都知道它，而不必为任何快速变化的内容付出达成一致的代价。

声明的状态并不私属于持有它的进程。平台按声明的间隔为它做快照，所以上一台主机不再响应时，替代主机可以从最近一次快照恢复，玩家则通过普通的房间宽限期（grace window）重新进入。

由此得出两点，外加一条警告：

替代主机拿到的是完整状态，但停留在快照那一刻。一次故障转移（failover）的代价是最近一次快照到失联之间的游戏进程，快照间隔决定了这个最坏情况。
权威变更时，tick 连续性不会延续。平台执行的迁移会保留参与者的 tick 状态；权威的替换则不作此承诺。这两者，以及宽限期过后会发生什么，都在 Rooms 中声明。

只存在于引擎中的状态无法恢复

只保存在引擎 actor 里的内容会随进程一起消失。它从未声明过，所以那台主机之外从来没有人持有过它。

排空下线（drain）一台主机，即不再往它上面分配新房间，让进行中的会话结束或移交，然后放它下线，其实就是有计划、有预告地走一遍故障转移路径。所以在不中断实时会话的前提下部署，不需要第二套机制。

房间的主机获知这件事的方式和获知其他任何事一样：平台出于自身原因要关闭或移交某个房间时，会提前通知。

宽限期过后会发生什么需要声明，而且没有默认值。权威在平台之外的房间类型，必须为失去权威指定三种结果之一：等待声明的窗口结束、关闭房间，或接纳替代权威。声明里不能不写。

你从不指定节点。创建房间的一方不选择房间在哪里运行，也没有哪个操作接受主机作为参数：分配（placement）由平台负责，所以平台可以迁移房间，而你的代码不依赖房间原来在哪里。

如果你自己托管房间（专用服务器或主客户端），情况相同，只多一条：平台会通知你收尾，而你要在宽限期内结束或移交自己的会话。主机在 Rooms 中注册这项绑定，而主机为什么只持有授予它的权利，见由谁决策。