Desconectar y limpiar la sesión

Una desconexión no debería tratarse únicamente como cerrar un socket. El cliente mantiene jugadores, canales, objetos, colas y estado de conexión que deben quedar en un estado coherente antes de volver a conectarse.

Desconectar

La operación de desconexión pertenece al cliente de red. Después de solicitarla, no asumas que el estado remoto desaparece de forma instantánea en el mismo frame.

Conectado
   ↓
Solicitar desconexión
   ↓
Cerrar transporte
   ↓
Limpiar sesión
   ↓
Desconectado

Canales y objetos

Durante la desconexión los canales dejan de representar una sesión válida y los objetos asociados a ellos dejan de ser utilizables para enviar mensajes.

Una comprobación especialmente útil es Objeto.PuedeEnviar:

if (objeto.PuedeEnviar)
{
    // Operación de red válida.
}

No conserves referencias a objetos de red de una sesión anterior para utilizarlas después de reconectar sin comprobar su registro y contexto.

Reconexion

Una nueva conexión debe reconstruir la sesión. No es correcto asumir que un playerID, channelID, uid o colección de objetos de la sesión anterior seguirá siendo válido.

Sesión A
  └── conexión + canales + objetos
             ↓
         desconexión
             ↓
Sesión B
  └── nueva conexión + nuevo estado

El hecho de que el mismo dispositivo o usuario vuelva a conectarse no convierte las dos sesiones de red en la misma sesión técnica.

Errores habituales

Enviar durante la desconexión

Comprueba el estado de conexión y la posibilidad real de envío antes de lanzar RFC o cambios de estado.

Reutilizar objetos destruidos

Un objeto marcado como destruido o que ya no pertenece a un canal válido no debe recibir nuevas operaciones de red.

Mezclar datos de dos sesiones

Limpia listeners, referencias y caches propios del juego cuando corresponda. Eco gestiona su estado de red, pero el juego sigue siendo responsable de sus propias referencias externas.

Referencias