IConnection

IConnection separa el modelo de red de Eco de la implementación física de la conexión. Esta abstracción permite que el runtime utilice el transporte TCP/UDP habitual o una integración externa compatible.

Eco
 ↓
ClienteJuego
 ↓
IConnection
 ├── TCP / sockets
 ├── Steam Networking
 └── transporte personalizado

Cuándo utilizarla

No necesitas implementar IConnection para un juego normal. Es apropiado cuando:

• la plataforma ofrece su propio transporte;
• necesitas reemplazar sockets por una API externa;
• estás creando una integración específica de servidor;
• quieres mantener el protocolo de Eco y cambiar sólo el canal físico de transporte.

Responsabilidades

Una implementación de conexión debe encargarse de aspectos como:

Conectar
Desconectar
Enviar bytes
Recibir bytes
Estado de conexión
Dirección / identidad del peer

El cliente sigue interpretando los bytes mediante Paquete y Buffer.

Steam Networking

La arquitectura permite integrar Steam Networking como transporte alternativo. El juego conserva el mismo modelo de canales, jugadores y objetos, mientras IConnection sustituye la ruta de sockets.

Gameplay
   ↓
Eco
   ↓
ClienteJuego
   ↓
IConnection
   ↓
Steam Networking

Esto resulta especialmente útil cuando una plataforma proporciona NAT traversal, identidad o routing propio.

Error habitual

No mezcles una implementación de IConnection con lógica de gameplay:

Incorrecto
IConnection
 ├── conectar
 ├── enviar bytes
 └── crear enemigos

La separación correcta es:

IConnection
 └── transporte

Eco / ClienteJuego
 └── protocolo y sesión

Objeto / Componente
 └── gameplay

Diagnóstico

Cuando una conexión personalizada falla, comprueba por capas:

1. conexión física establecida;
2. bytes enviados y recibidos;
3. handshake RequestID / ResponseID;
4. creación de ClienteJuego;
5. entrada en canales;
6. procesamiento normal de paquetes.

Si el handshake no funciona, todavía no tiene sentido investigar objetos o RFC.

Referencias