¿Tiene sentido usar TCP y UDP a la vez?

Después de leer ¿UDP es aún mejor que TCP para juegos en tiempo real con muchos datos? , Me pregunto si tiene sentido usar TCP y UDP al mismo tiempo, pero para diferentes cosas:

• TCP para enviar información que se envía con poca frecuencia, pero se debe garantizar que llegue de manera confiable.
  Como las actualizaciones de puntaje, el nombre de un jugador o incluso el estado de encendido / apagado de una luz en el mundo del juego.

• UDP para transmitir información que se actualiza constantemente y puede perderse ocasionalmente, ya que la información más nueva siempre está en camino.
  Tales como posición, rotación, etc.

¿Es esta una idea razonable? ¿Cuáles son los posibles inconvenientes?
¿Hay mejores formas de manejar esto?

Resulta en la pérdida de paquetes para UDP debido a la contención entre los dos protocolos; recuerde que UDP no garantiza la entrega, mientras que TCP sí. Más paquetes TCP pasarán mientras UDP sufre: TCP induce la pérdida de paquetes UDP . También ha surgido la idea (histórica) de que la infraestructura del enrutador favorece el TCP sobre el UDP, aunque dudo que aún sea cierto en esta etapa tardía.

Creo que sería mejor encontrar uno de los protocolos UDP orientados a la conexión que está disponible para su uso en juegos y similares, que le ofrece algunos de los beneficios de TCP sin ninguna de sus desventajas. Hay algunos de estos, generalmente con un documento técnico que detalla cada concepto.

Un ejemplo de ellos es la biblioteca de código abierto Enet , su característica principal es la entrega confiable y en orden de paquetes por UDP.

Aquí hay una cita de Sam Jansen de un comentario en gafferongames.com :

Hablando como investigador de redes y no como desarrollador de juegos, la conclusión de nunca usar TCP y UDP juntos parece un poco fuerte. TCP solo tendrá pérdida de paquetes si está enviando demasiados datos; de alguna manera al igual que los datos UDP que está enviando. La diferencia es que no tienes control directo sobre la velocidad a la que TCP envía, esto está oculto para ti.

Si solo necesita enviar algunos datos confiables y no quiere preocuparse por la retransmisión e implementar un protocolo confiable, y sabe que la velocidad será baja, entonces no habrá problemas con el uso de TCP y UDP.

La relación no es tan compleja entre los dos realmente: TCP simplemente aumenta su velocidad de envío (si hay datos para enviar) hasta que se pierde el paquete, en cuyo caso vuelve a marcar su velocidad, luego comienza a aumentar la velocidad nuevamente (esto tiempo más lento). Cuando su aumento en la velocidad causa la pérdida de paquetes, es muy probable que también afecte a cualquier otra secuencia de datos, incluidos sus paquetes UDP.

El documento Características de la pérdida de paquetes UDP: el efecto del tráfico TCP obtuvo sus resultados al abrir múltiples conexiones TCP a la vez e inundar la red con datos. Esto conduce a la congestión seguida de la sincronización global , que causan paquetes descartados. Obviamente, un cliente de juegos no abrirá una docena de conexiones a la vez e inundará la red con datos, por lo que sus resultados serán diferentes.

Para responder tu pregunta:

Me pregunto si tiene sentido usar TCP y UDP al mismo tiempo, pero para diferentes cosas [...]

Sí, esto es aceptable si se mantiene dentro de los límites de ancho de banda.

• TCP para enviar información que se envía con poca frecuencia, pero se debe garantizar que llegue de manera confiable. Como las actualizaciones de puntaje, el nombre de un jugador o incluso el estado de encendido / apagado de una luz en el mundo del juego.

Cuando use TCP y UDP, siempre debe preferir enviar tanto como sea posible a través de UDP y lo menos posible a través de TCP.

Ahora, te pregunto esto: ¿es realmente necesario enviar la puntuación, el nombre del jugador y el estado de una luz sobre TCP? Si bien es cierto que necesita recibir estos datos eventualmente, ¿es cierto que necesita recibir estos datos estrictamente en orden y exactamente una vez?

Probablemente no.

UDP funciona bien para estos casos, y Quake 3 es un buen ejemplo de cómo.

Entonces, ¿cuál es un buen ejemplo de TCP junto con UDP? Bueno, piensa en el chatbox de un juego. Las actualizaciones de este chatbox (es decir, las nuevas líneas de texto) deben enviarse de manera confiable y estrictamente en orden. Por lo tanto, TCP es un buen ajuste.

¿Es esta una idea razonable?

• si

¿Cuáles son los posibles inconvenientes?

• Pérdida de paquetes, más complejidad de código, otra conexión para administrar == más posibilidades de desconexiones, tiempos de espera, excepciones, lo que sea ...

¿Hay mejores formas de manejar esto?

• Use una biblioteca UDP confiable existente. Dos de los más populares son: Red Lidgren (C #), RakNet (C ++). Por experiencia, puedo decir que Lidgren es súper fácil de usar, rápido y confiable.

Hay una restricción de recursos adicional a considerar. La mayoría de las implementaciones (creo en todo, pero no tengo referencia) de TCP en el servidor tienen límites en la cantidad de conexiones TCP simultáneas que el servidor puede tener abiertas al mismo tiempo. Esto limitaría la cantidad de jugadores que puedes tener abiertos al mismo tiempo si cada jugador necesita su propia conexión.

Los límites están definidos por la configuración en el sistema de red. Además, cada conexión utiliza algo de memoria que debe provenir de algún lugar del servidor.

Una solución es abrir solo una conexión TCP temporal mientras se transfieren los datos y cerrarla de inmediato. Esto hará que las transacciones sean más lentas, abrir una conexión tcp es un proceso bastante "costoso". Como siempre, se trata de diseñar un sistema robusto desde el principio para permitir un gran crecimiento.