Servidor
Ciclo de vida de ServidorJuego, autoridad, jugadores, canales, persistencia y extensiones.
Servidor
ServidorJuego concentra la lógica autoritativa de Eco: conexiones, jugadores, canales, objetos, paquetes, persistencia y servicios auxiliares.
Principio de autoridad
El cliente puede solicitar una operación, pero el servidor es quien debe decidir si esa operación modifica el estado compartido cuando las reglas del juego requieren autoridad central.
Responsabilidades
Conexiones
Acepta jugadores y mantiene sus estados de sesión.
Canales
Mantiene los ámbitos activos y coordina jugadores, objetos y estado.
Persistencia
Guarda y restaura el estado del mundo y puede dormir canales sin jugadores.
Extensión
Permite interceptar paquetes no gestionados mediante onCustomPacket.
Ciclo de vida
Preparación
Configura identidad del servidor, persistencia, administración y transporte.
Arranque
Start() prepara TCP y el UDP opcional y activa el procesamiento de red.
Aceptación
Listen() mantiene la escucha de nuevas conexiones TCP y crea el estado asociado al participante.
Operación
El servidor procesa paquetes, actualiza jugadores y canales y ejecuta las operaciones autoritativas.
Cierre
La detención del servidor finaliza las conexiones y permite guardar el estado si la configuración lo requiere.
Jugadores
El servidor mantiene estructuras separadas para iterar y para resolver participantes por ID o endpoint.
Jugador
├── ID
├── Endpoint
├── Nombre
├── Datos
└── CanalesEsto permite que un jugador sea tratado como participante lógico independientemente de la representación física de la conexión.
Canales
Los canales activos se almacenan en listas y diccionarios para combinar iteración y acceso rápido.
ServidorJuego
├── Canal 10
│ ├── jugadores
│ ├── objetos
│ └── estado
└── Canal 20
├── jugadores
├── objetos
└── estadoEl mismo jugador puede pertenecer a más de un canal.
Persistencia y memoria
ServidorJuego dispone de un archivo de mundo y de funciones reemplazables de lectura/escritura.
Sleep() reduce la memoria utilizada por canales sin jugadores y Wake() permite restaurarlos. El servidor también puede realizar este tipo de reducción durante procesos de guardado.
Persistencia no significa mantener todo en RAM
Un canal persistente puede existir lógicamente aunque no todos sus datos permanezcan activos en memoria todo el tiempo.
Procesamiento multihilo
La implementación contempla ejecución multihilo y expone isMultiThreaded según la configuración de compilación.
Es el comportamiento normal. El servidor puede procesar red y trabajo auxiliar fuera del hilo principal.
La directiva SINGLE_THREADED permite una configuración donde el procesamiento se coordina desde el ciclo de actualización.
Integración con Unity
No asumas que todo callback del servidor ocurre en el hilo principal de Unity. El código que acceda a objetos de Unity debe considerar explícitamente su contexto de ejecución.
Paquetes personalizados
Cuando el servidor recibe un paquete que no procesa internamente puede utilizar onCustomPacket.
servidor.onCustomPacket = (jugador, buffer, reader, request, reliable) =>
{
// Interpretar una extensión de protocolo propia.
};Las extensiones deberían definir claramente versión, serialización, permisos y comportamiento ante datos inválidos.
Administración y lobby
El servidor puede mantener una lista de administradores y enlazarse con un servidor de lobby mediante enlaceLobbyLink.
Estas funciones son servicios alrededor de la sesión, no sustitutos del modelo de canales.
Servidor local
ServidorJuego puede conectarse a un ClienteJuego local, utilizando colas internas en lugar de sockets.
Consulta Servidor local y la guía correspondiente.
Relación con TNet
| Eco | TNet | Responsabilidad |
|---|---|---|
ServidorJuego | GameServer | Runtime servidor |
Jugador / Entidad | Player | Participante |
Canal | Channel | Ámbito compartido |
Paquete | Packet | Protocolo |