TCP y UDP en profundidad

Eco utiliza TCP como transporte principal del cliente y contempla UDP para datos donde la pérdida o reordenación sea aceptable. ClienteJuego mantiene explícitamente ambos protocolos y expone si UDP puede utilizarse. fileciteturn216file0

TCP

TCP es apropiado para operaciones que necesitan entrega fiable y ordenada:

• entrada y salida de canales;
• creación y destrucción de objetos;
• cambios de propiedad;
• datos persistentes;
• control de sesión.

La conexión TCP constituye el vínculo principal entre cliente y servidor.

UDP

UDP puede utilizarse para tráfico frecuente donde repetir o perder datos sea preferible a bloquear el flujo fiable. El cliente comprueba canUseUDP antes de asumir que está disponible. fileciteturn216file0

Ejemplos conceptuales:

Posición / orientación de alta frecuencia → UDP posible
Handshake / creación de objetos           → TCP
Estado persistente                         → TCP

La elección depende de la semántica del dato, no de si el dato “parece rápido”.

Activación

El protocolo incluye RequestSetUDP, ResponseSetUDP y RequestActivateUDP. UDP no es simplemente otro socket que se usa sin negociación: existe una fase de activación asociada a la sesión. fileciteturn227file0

NoDelay

ClienteJuego.noDelay permite cambiar el comportamiento de Nagle en TCP. Activarlo puede reducir latencia a costa de aumentar tráfico, por lo que debe medirse con el patrón de mensajes real. fileciteturn216file0

Conexión personalizada

La arquitectura también permite utilizar una IConnection personalizada. Esto abre la puerta a transportes externos cuando el proyecto necesita una capa distinta del socket TCP/UDP tradicional.

Regla de diseño

No selecciones UDP para “hacerlo más rápido” sin definir primero qué sucede cuando un paquete llega tarde, duplicado o nunca llega. Si la lógica no puede tolerarlo, el dato necesita un flujo fiable o una estrategia explícita de corrección.

Referencias