Arquitectura
Cómo se relacionan las capas de Eco y cómo fluye la información entre ellas.
Arquitectura
Eco es la capa de red utilizada por Pandora. Parte de la arquitectura de TNet, pero utiliza la nomenclatura, organización y extensiones propias de Nervelink.
Regla fundamental
Piensa en Eco como un sistema por capas. Canal, Objeto, Jugador, RFC, Paquete y Buffer resuelven problemas distintos; no son sustitutos entre sí.
Mapa de la arquitectura
┌─────────────────────────────────────────────────────────────┐
│ Gameplay │
└────────────────────────────┬────────────────────────────────┘
│
Objeto / Componente
│
┌──────────────┴──────────────┐
│ │
RFC Estado
│ │
└──────────────┬──────────────┘
│
Canal
│
Paquete / Protocolo
│
Buffer
│
TCP / UDP / custom
│
┌──────────────┴──────────────┐
│ │
Cliente ServidorLas cuatro capas que debes distinguir
Modelo de red
Define quién participa, qué objetos existen y en qué canal viven.
Comunicación
Define qué se quiere comunicar y quién debe recibirlo.
Transporte
Convierte la operación en un mensaje serializado y lo transporta.
Runtime
Ejecuta cliente y servidor y mantiene sus ciclos de vida.
Modelo de red
Canal
Un Canal delimita un ámbito de jugadores y estado. Una conexión puede pertenecer a varios canales simultáneamente; esto es una propiedad del modelo de Eco, no una conexión física adicional.
Jugador
Jugador representa una participación en la sesión. Su identidad es independiente de la conexión física y dispone de datos propios que pueden sincronizarse.
Objeto
Objeto aporta identidad de red, ownership, canal, datos y ciclo de vida. Su uid combina el contexto del canal con la identidad del objeto.
Componente
Componente es la capa de integración con MonoBehaviour: permite acceder cómodamente al objeto de red y es el punto habitual desde el que se declaran RFC, datos y operaciones de instanciación.
Comunicación
Una operación empieza en gameplay y acaba convertida en un mensaje de protocolo.
Componente
│
├── RFC ────────────────┐
│ │
└── Set / Sync ─────────┤
▼
Objeto
│
Paquete
│
Buffer
│
TransporteLa selección de destinatario se realiza antes de que el mensaje abandone el contexto de Eco. Por eso Destinatarios pertenece conceptualmente a Comunicación y no a Transporte.
Runtime
El cliente mantiene su conexión y representación local. El servidor mantiene el estado compartido, administra jugadores y canales y procesa las solicitudes que requieren autoridad del servidor.
ClienteJuego
├── Conexión TCP
├── UDP opcional
├── Canales
├── Jugador local
└── Cola / procesamiento de paquetes
ServidorJuego
├── Listener TCP
├── UDP opcional
├── Jugadores
├── Canales
├── Persistencia
└── Procesamiento de paquetesFlujo de una operación
Gameplay [step]
Tu código decide qué quiere hacer: cambiar estado, ejecutar una acción, crear un objeto o cambiar de canal.
Modelo de red [step]
Eco determina el Objeto, Canal, propietario y contexto de la operación.
Comunicación [step]
Se selecciona RFC, sincronización o una operación de protocolo existente y se determinan sus destinatarios.
Serialización [step]
Los parámetros se convierten a una representación binaria mediante Buffer y las herramientas de serialización.
Transporte [step]
El mensaje viaja mediante TCP, UDP cuando corresponde, o una conexión personalizada.
Aplicación remota [step]
El receptor procesa el paquete, actualiza el estado correspondiente y ejecuta los callbacks asociados.
Relación con TNet
| TNet | Eco | Responsabilidad |
|---|---|---|
TNManager | Eco | Fachada y operaciones globales |
TNObject | Objeto | Identidad y estado de red |
TNBehaviour | Componente | Integración con Unity |
Channel | Canal | Ámbito compartido |
Packet | Paquete | Protocolo |
Buffer | Buffer | Datos binarios |
Player | Jugador | Participante |
No copies el workflow antiguo de TNet literalmente
Los ejemplos históricos suelen asumir un único canal activo y una API distinta. En Eco debes seguir el comportamiento actual del repositorio y utilizar las páginas de Modelo de red y Guías como referencia práctica.