Esta página aún no está traducida: se muestra la versión en inglés.

Qué sobrevive a la pérdida de un host

Una partida sobrevive a la caída de su host. Esta página trata de qué máquina es dueña de una entidad y cuál lo será después, el segundo significado de “replicación”; Quién ve qué y en qué máquina se ejecuta explica en qué se diferencian los dos.

El estado de la sala no se copia entre hosts

Una entidad tiene exactamente un dueño a la vez, y ninguna otra máquina mantiene una copia viva lista para tomar el relevo.

Si dos copias aceptaran el mismo disparo, tendrían que ponerse de acuerdo en el orden en que impactaron los dos disparos. Ponerse de acuerdo sobre un orden treinta veces por segundo entre máquinas es consenso, y el consenso agrega latencia justo donde un juego no la tolera. Un único dueño no tiene ese problema, y cada mecanismo que sigue existe para que un único dueño pueda sobrevivir a una falla.

Lo que sí se replica es la presencia: qué actor está en qué nodo. Es un dato pequeño que cambia poco, así que el enrutamiento puede conocerlo en todas partes sin pagar por ponerse de acuerdo sobre nada que se mueva.

El estado declarado se guarda fuera del host

El estado declarado no es privado del proceso que lo tiene. Se guarda en snapshots a un intervalo declarado, así que, cuando el host anterior deja de responder, un reemplazo puede retomar desde el último snapshot, y el jugador (player) vuelve a entrar por el período de gracia (grace window) habitual de las salas.

De esto se desprenden dos cosas y una advertencia:

• El reemplazo tiene el estado completo, pero tal como estaba en el snapshot. Lo que cuesta una conmutación por error (failover) es el juego entre el último snapshot y la pérdida, y el intervalo es lo que fija ese peor caso.
• La continuidad del tick no se conserva cuando cambia la autoridad. Un traslado que hace la plataforma conserva el estado de tick del participante; un reemplazo de la autoridad no lo promete. En Rooms se declaran los dos casos, junto con lo que pasa cuando vence el período de gracia.

Un deploy sigue el mismo camino, sin la pérdida

Retirar un host de servicio (drain) — dejar de ubicar salas nuevas en él, dejar que las sesiones en curso terminen o se transfieran y después soltarlo — es el camino de la conmutación por error recorrido a propósito y con aviso. Por eso, desplegar sin cortar sesiones en vivo no requiere un segundo mecanismo.

El host de la sala (room) se entera de la misma forma en que se entera de todo: la plataforma avisa con anticipación que una sala se va a cerrar o transferir por un motivo propio de la plataforma.

Lo que pasa cuando vence el período se declara, y no hay valor predeterminado. Un tipo de sala cuya autoridad vive fuera de la plataforma nombra uno de tres resultados para cuando la pierde: esperar un período declarado, cerrar la sala o admitir una autoridad de reemplazo. La declaración no puede omitirlo.

Elegir la máquina no es parte de tu interfaz

Nunca nombras un nodo. Quien crea una sala no elige dónde se ejecuta, y ninguna operación recibe un host como argumento: la ubicación le corresponde a la plataforma, así que puede mover una sala sin que tu código dependa de dónde estaba.

Si alojas salas tú mismo — en un servidor dedicado o en un cliente maestro —, vale lo mismo, con un agregado: se te avisa que debes cerrar, y terminar o transferir tus sesiones dentro del período de gracia te corresponde a ti. En Rooms se explica cómo se registra un host para ese binding, y Quién toma las decisiones explica por qué el host tiene solo los derechos que se le otorgaron.