O que sobrevive à perda de um host

Uma partida sobrevive à morte do host. Esta página trata de qual máquina é dona de uma entidade e qual será a próxima dona — o segundo sentido de “replicação”. A página Quem vê o quê e em qual máquina separa os dois sentidos.

O estado da sala não é copiado entre hosts

Uma entidade tem exatamente um dono por vez, e nenhuma segunda máquina mantém uma cópia viva, pronta para assumir.

Duas cópias que aceitassem o mesmo tiro teriam de concordar sobre a ordem em que os dois tiros chegaram. Concordar sobre uma ordem trinta vezes por segundo entre máquinas é consenso, e o consenso acrescenta latência justamente onde um jogo não tolera. Um dono único não tem esse problema, e todos os mecanismos abaixo existem para que ter um único dono não custe a partida.

O que se replica, sim, é a presença: qual ator está em qual nó. É um fato pequeno e que muda devagar, então o roteamento pode conhecê-lo em todo lugar sem pagar por consenso sobre nada que se mexe.

O estado declarado fica fora do host

O estado declarado não é privado do processo que o mantém. Ele ganha snapshots em um intervalo declarado; assim, quando o host anterior para de responder, um substituto retoma a partir do último snapshot, e o jogador volta pelo período de tolerância (grace window) comum das salas.

Disso decorrem duas coisas, e um aviso:

O substituto tem o estado inteiro, mas como estava no snapshot. Um failover custa o jogo entre o último snapshot e a perda, e é o intervalo que fixa esse pior caso.
A continuidade do tick não atravessa uma troca de autoridade. Uma transferência feita pela plataforma preserva o estado de tick do participante; já a substituição da autoridade não promete isso. É em Rooms que as duas coisas são declaradas, junto com o que acontece quando o período de tolerância passa.

O estado que existe só na engine não é recuperado

O que você guardou apenas em atores da engine vai embora com o processo. Esse estado nunca foi declarado, então nada fora daquele host chegou a tê-lo.

Um deploy é o mesmo caminho, sem a perda

Retirar um host de serviço (drain) — parar de alocar novas salas nele, deixar as sessões em andamento terminarem ou serem transferidas e então liberá-lo — é o caminho do failover, percorrido de propósito e com aviso prévio. Por isso, fazer o deploy sem derrubar sessões ao vivo não exige um segundo mecanismo.

O host da sala fica sabendo disso do mesmo jeito que fica sabendo de qualquer coisa: a plataforma avisa com antecedência que uma sala (room) vai ser fechada ou transferida por um motivo do lado dela.

O que acontece depois que a janela passa é declarado, e não há padrão. Um tipo de sala cuja autoridade vive fora da plataforma nomeia um de três desfechos para a perda dessa autoridade: esperar uma janela declarada, fechar a sala ou admitir uma autoridade substituta. A declaração não pode deixar isso em aberto.

A escolha da máquina não faz parte da sua interface

Você nunca nomeia um nó. Quem cria uma sala não escolhe onde ela roda, e nenhuma operação recebe um host como argumento: a alocação é da plataforma, e por isso ela pode mover uma sala sem que seu código dependa de onde a sala estava.

Se você mesmo hospeda salas — um servidor dedicado ou um cliente mestre —, vale o mesmo, com um acréscimo: você recebe o aviso para encerrar, e terminar ou transferir suas sessões dentro do período de tolerância é responsabilidade sua. É em Rooms que o host se registra para esse vínculo, e Quem toma as decisões explica por que o host tem apenas os direitos que recebeu.