Что остаётся после потери хоста

Матч переживает падение своего хоста. Эта страница о том, какая машина владеет сущностью и какая будет владеть ею следующей, — то есть о втором значении слова «репликация». Чем эти два значения различаются, объясняет страница Кто что видит и на какой машине это работает.

Состояние комнаты не копируется между хостами

В каждый момент у сущности (entity) ровно один владелец, и никакая вторая машина не держит наготове живую копию, чтобы подхватить её.

Если бы две копии приняли один и тот же выстрел, им пришлось бы договориться, в каком порядке попали два выстрела. Договариваться о порядке тридцать раз в секунду между машинами — это консенсус, а консенсус добавляет задержку там, где игра её не терпит. У единственного владельца такой проблемы нет, и все механизмы ниже нужны для того, чтобы единственный владелец мог пережить отказ.

Реплицируется другое — присутствие (presence): какой актор на каком узле. Это небольшой и редко меняющийся факт, поэтому маршрутизация может знать его везде и не платить за согласование того, что постоянно движется.

Объявленное состояние хранится вне хоста

Объявленное состояние не принадлежит только тому процессу, который его держит. Платформа делает его снапшот с объявленным интервалом, поэтому, когда прежний хост перестаёт отвечать, замена может продолжить с последнего снапшота, а игрок возвращается через обычный льготный период (grace window) комнат.

Из этого следуют две вещи и одно предупреждение:

У замены есть всё состояние, но на момент снапшота. Переключение на резерв (failover) стоит той игры, что прошла между последним снапшотом и отказом, и именно интервал определяет этот худший случай.
При смене авторитетного источника непрерывность тика не сохраняется. Когда комнату переносит платформа, состояние тика участника сохраняется; замена авторитетного источника этого не обещает. Оба случая объявляются на странице Rooms — вместе с тем, что происходит, когда льготный период истёк.

Состояние, которое живёт только в движке, не восстанавливается

Всё, что вы хранили только в акторах движка, пропадает вместе с процессом. Это состояние не было объявлено, поэтому за пределами хоста его не было никогда.

Деплой идёт тем же путём, только без потерь

Вывести хост из работы (drain) — значит перестать размещать на нём новые комнаты, дать текущим сессиям закончиться или передать их и только потом отпустить хост. Это тот же путь, что и при отказе, только пройденный намеренно и с предупреждением. Поэтому, чтобы деплоить без обрыва живых сессий, второй механизм не нужен.

Хост комнаты узнаёт об этом так же, как обо всём остальном: платформа заранее предупреждает, что комнату нужно закрыть или передать по причине, которая возникла на стороне платформы.

Что происходит, когда окно истекло, объявляется, и значения по умолчанию нет. Если авторитетный источник комнаты находится вне платформы, её тип указывает, что делать при его потере: переждать объявленное окно, закрыть комнату или пустить замену. Оставить это необъявленным нельзя.

Выбор машины в ваш интерфейс не входит

Вы никогда не указываете узел. Тот, кто создаёт комнату (room), не выбирает, где она будет работать, и ни одна операция не принимает хост аргументом. Размещение — дело платформы, поэтому она может перенести комнату, и ваш код не зависит от того, где та была.

Если вы хостите комнаты сами — на выделенном сервере или мастер-клиенте, — всё так же, с одним дополнением: вам сообщают, что пора сворачиваться, и завершить или передать свои сессии в пределах льготного периода должны вы. На странице Rooms описано, как хост для этого регистрируется, а на странице Кто принимает решения — почему у хоста есть только те права, которые ему выдали.