Preguntas frecuentes

Esta página reúne dudas que suelen aparecer al integrar Eco o al trasladar conocimientos de TNet 3 a la arquitectura actual de Nervelink.

Arquitectura

¿Eco es una implementación nueva de networking?

No. Eco parte de TNet 3 y conserva gran parte de su arquitectura y comportamiento, pero utiliza la nomenclatura y organización de Nervelink y puede incorporar cambios propios.

¿Eco es simplemente un renombrado de TNet?

No conviene tratarlo como un reemplazo mecánico de nombres. Aunque existen equivalencias directas como TNManager → Eco, TNObject → Objeto y TNBehaviour → Componente, la documentación debe seguir la implementación de Eco.

¿Qué repositorio debo consultar?

Para usar Eco, consulta primero:

Para comparar el origen de una característica:

Conexiones y canales

¿Un cliente sólo puede estar en un canal?

No. Una conexión puede pertenecer simultáneamente a varios Canal. La pertenencia a canales es una capa lógica sobre la conexión de red.

Cliente
└── Conexión
    ├── Canal A
    ├── Canal B
    └── Canal C

Consulta Canales para conocer cómo se gestionan entradas, salidas y estados múltiples.

¿Canal y conexión son lo mismo?

No.

¿Entrar en un canal significa que ya puedo enviar inmediatamente?

No necesariamente. Durante la unión existen estados transitorios. Debes esperar a que el canal haya quedado registrado en la sesión y a que el objeto pueda enviar. Objeto.PuedeEnviar existe precisamente para comprobar esta condición en operaciones asociadas a objetos.

¿Puedo abandonar un canal sin desconectarme?

Sí. Salir de un Canal no termina la conexión con el servidor. La misma conexión puede continuar participando en otros canales.

Objetos y componentes

¿Qué diferencia hay entre Objeto y Componente?

Objeto proporciona la identidad de red, propiedad, canal, datos y ciclo de vida. Componente aporta comportamiento asociado a ese objeto.

GameObject
├── Objeto
├── Componente
└── Componente

¿Qué diferencia hay entre id y uid?

id identifica el objeto dentro de su contexto de canal. uid combina la identidad del objeto con el canal para permitir una identificación global del objeto de red.

¿Puedo cambiar el propietario de cualquier objeto?

No. Los objetos estáticos tienen restricciones distintas de los objetos dinámicos. En Eco, el cambio de propietario se valida además contra la pertenencia del jugador destino al canal del objeto.

¿Qué significa isMine?

Indica si el propietario del objeto es el jugador local. No significa que el objeto sea visible únicamente para ese jugador.

Comunicación y sincronización

¿RFC o sincronización?

Usa RFC para acciones o eventos puntuales y sincronización para mantener propiedades o estado.

"Abre la puerta"      → RFC
"La puerta está abierta" → Estado

Consulta Comunicación y Sincronización.

¿Qué ocurre cuando llamo a Objeto.Set y todavía no puede enviar?

El valor se aplica localmente y el cambio puede quedar pendiente para transmitirse cuando el objeto vuelva a estar en condiciones de enviar. Esto es importante durante uniones, transiciones de canal y otros estados temporales.

¿Debo usar AutoSincronizar para todo?

No. Es una herramienta de conveniencia para casos sencillos y prototipos. Los sistemas críticos suelen beneficiarse de un estado explícito, autoridad clara y una frecuencia de actualización diseñada para cada dato.

¿La sincronización siempre pasa por el propietario?

La implementación de Objeto.Set está diseñada para que las solicitudes de cambio pasen por el propietario cuando el emisor no es el propietario local. Esto ayuda a mantener una fuente de autoridad única para el estado del objeto.

Transporte

¿TCP y UDP se pueden utilizar indistintamente?

No. TCP ofrece entrega fiable y ordenada. UDP está pensado para tráfico donde la pérdida o el procesamiento de valores intermedios puede ser aceptable.

¿Usar UDP hace automáticamente una operación más rápida?

No. El transporte afecta a latencia, fiabilidad y coste, pero la semántica de la operación sigue siendo responsabilidad del diseño de comunicación.

¿Qué es un Buffer?

Es el contenedor binario que Eco utiliza para escribir y leer datos que forman parte de los mensajes de red. Se encuentra por debajo del nivel de gameplay y del protocolo.

Servidor

¿Puedo ejecutar cliente y servidor dentro de la misma instancia de Unity?

Sí. Eco dispone de un modo de servidor local que conecta ClienteJuego y ServidorJuego dentro del mismo proceso. Es útil para pruebas, pero no sustituye a una prueba de red real entre procesos o máquinas.

¿El servidor siempre es multihilo?

La implementación está preparada para ejecución multihilo y puede compilarse con SINGLE_THREADED cuando se necesita ejecutar el procesamiento sin el hilo de red dedicado.

¿Qué persiste realmente el servidor?

Depende del mecanismo utilizado. Eco distingue entre datos del servidor, estado de canal, datos de jugadores, objetos persistentes y RFC guardadas. No todo dato que existe durante una sesión se convierte automáticamente en una partida persistida.

Depuración

¿Dónde miro cuando un mensaje no llega?

Sigue la cadena de abajo hacia arriba:

¿Qué hago si una API de TNet no existe en Eco?

No la sustituyas automáticamente por una función con el mismo nombre aproximado. Busca primero la equivalencia en Equivalencias Eco ↔ TNet y después confirma la implementación actual en el repositorio de Eco.

Código y navegación

¿Dónde está el código principal de Eco?

La red comienza principalmente en:

src/Assets/Pandora/Logica/Nucleo/Core/Red/

La estructura se divide en cliente, común, servidor y componentes relacionados con protocolo, transporte y serialización.

¿Por dónde debería empezar a estudiar Eco?

La ruta recomendada es:

Inicio rápido
  ↓
Fundamentos
  ↓
Modelo de red
  ↓
Comunicación
  ↓
Transporte
  ↓
Runtime
  ↓
Guías