networking - ser - que debo estudiar para crear videojuegos

¿Por qué los desarrolladores de juegos evitan TCP y hacen que UDP sea confiable en el nivel de la aplicación? (4)

Muchos desarrolladores de juegos eligen hacer que UDP sea confiable en el nivel de la aplicación . ¿No es eso para lo que está hecho TCP? Hice una API que habilita la comunicación Cliente-Servidor usando paquetes UDP y TCP. ¿Debo agregar UDP confiable a la lista? ¿Y por qué? ¿Hay algún problema si uso TCP?

Solo quiero saber si RUDP tiene algún beneficio sobre TCP, por lo que puedo elegir si agregar o no soporte RUDP.

El problema es con los paquetes fuera de orden .

Después de mirar alrededor, descubrí que el problema es que TCP quiere encerrar todos los paquetes recibidos hasta que se reciban en el orden que espera la aplicación. Esto podría ser bastante perjudicial para el rendimiento de un juego multijugador de tamaño razonable donde solo te importan las últimas posiciones de jugador y no dónde estaban hace unos pocos milisegundos.

RUDP cambia todo eso y solo proporciona el "paquete más reciente" como Erik de los estados de Unity:

Erik-Juhl @ Unity Technologies

La razón principal por la que la gente elegiría UDP / RUDP sobre TCP es por la forma en que TCP maneja los paquetes desordenados. Es posible que solo le interese el paquete recibido más recientemente y lo desee tan pronto como llegue. En TCP, si su paquete recibido más recientemente no es el siguiente en secuencia, TCP no se lo entregará hasta que se haya recibido todo lo demás.
Si necesita garantizar la secuencia y la entrega , simplemente use TCP . Si necesita garantizar la secuencia y la entrega, además de obtener los paquetes más recientes tan pronto como lleguen, entonces use RUDP . Dime más...

No entiendo demasiado acerca de estos protocolos, pero de acuerdo con mi conocimiento actual, TCP es un protocolo orientado a la conexión y UDP es un protocolo sin conexión. UDP se utiliza principalmente en juegos en vivo multijugador en línea debido al hecho de que UDP es más rápido porque no se intenta la recuperación de errores. En esos juegos, se usa UDP porque la confiabilidad no es realmente crucial. TCP toma medidas para asegurarse de que todos los paquetes que se envían los reciba el cliente, mientras que UDP simplemente los envía sin verificar si se han recibido. ¡Por favor, corríjame si estoy equivocado!

Referencia: http://www.diffen.com/difference/TCP_vs_UDP

Si dijera directamente que UDP es más rápido, comparativamente que TCP, se usa para tales aplicaciones; no vas a creer y aceptar Los desarrolladores, continuando con esto, desarrollaron cierta confiabilidad en UDP (llamada RUDP) para hacer que imitara un poco al TCP. Aún así, no implementa funcionalidades TCP por completo (en su totalidad).

Es por eso que me gustaría responder a su pregunta con referencia a un artículo. Reliable UDP (RUDP): The Next Big Streaming Protocol? :

TCP tiene un conjunto de instrucciones que garantiza que cada paquete de datos llegue a su destinatario. Es comparable a la entrega registrada en su forma más básica. Sin embargo, si bien parece obvio al principio que "asegurarse de que el mensaje llegue allí" es primordial cuando se envía algo a otra persona, hay algunas consideraciones adicionales que deben tenerse en cuenta. Si un enlace de red que utiliza TCP / IP advierte que un paquete ha llegado fuera de secuencia, TCP detiene la transmisión, descarta cualquier cosa del paquete fuera de secuencia, envía un mensaje de "vuelva a donde salió mal" y comienza la transmisión de nuevo.
Si tienes todo el tiempo del mundo, está bien. Entonces, para transferir mi información de salario de mi empresa a mí, francamente no me importa si esto toma un microsegundo o una hora, quiero que se haga bien. TCP es fantástico para eso.
Sin embargo, en un modelo de servicio centrado en video, simplemente hay tanta información que si algunos paquetes no llegan al enlace, hay situaciones en las que preferiría omitir esos paquetes y continuar con el flujo general del video que obtener todos los detalles de la fuente original. Nuestro cerebro puede imaginar los fragmentos saltados del video para nosotros siempre que no se distraiga con el audio desigual y el video stop-motion. En estas circunstancias, es claramente deseable tener la opción de enviar la mayor cantidad de datos de un extremo del enlace al otro de manera oportuna, independientemente de cuánto se atraviese con precisión. Es para este tipo de aplicación que UDP es óptimo. Si un paquete parece no haber llegado, el destinatario espera unos minutos para ver si llega, posiblemente hasta el momento en que el espectador necesita ver ese bloque de video, y si el búfer llega al punto donde debería estar el paquete faltante, entonces simplemente continúa, y la aplicación se salta el punto donde están los datos faltantes, pasando al siguiente paquete y manteniendo la base de tiempo del video. Puede ver un parpadeo o algún artefacto, pero el momento pasa casi al instante y es muy probable que su cerebro llene el espacio.
Si este error se produce en TCP, TCP puede tardar más de 3 segundos en renegociar la secuencia para que se reinicie desde el punto que falta, descartando todos los datos posteriores, que deben volver a ponerse en cola para enviarlos nuevamente. Solo un paquete perdido puede provocar el reenvío de toda una "ventana" de datos TCP.

Muchos desarrolladores de juegos eligen hacer que UDP sea confiable en el nivel de la aplicación. ¿No es eso para lo que está hecho TCP?

Si puede tolerar con la velocidad de cómo se procesan los datos en ambos extremos, está bien.

Pero, en los juegos, esto no está bien. Debe pasar cuadros de video (y audio, etc.) muchas veces por segundo y también a muchos jugadores (si es multijugador). Todo necesita mucha más velocidad y una capacidad de procesamiento de datos más rápida; en lugar de usar el TCP comparativamente más lento. Incluso si algunos paquetes se dejan caer a medio camino, está bien que la aplicación avance, ya que el cerebro también pasará a la siguiente en lugar de pensar en esos nervios.

Hice una API que habilita la comunicación Cliente-Servidor usando paquetes UDP y TCP. ¿Debo agregar UDP confiable a la lista? ¿Y por qué? ¿Hay algún problema si uso TCP?

Eso depende de cuán mejor quiera que la aplicación responda. Le sugiero que agregue UDP confiable a su lista.

Ya he mencionado los problemas con el TCP.

Solo quiero saber si RUDP tiene algún beneficio sobre TCP, por lo que puedo elegir si agregar o no soporte RUDP.

Con una sobrecarga baja y una velocidad más alta, apostaría por un UDP confiable que por el voluminoso TCP para desarrollar tales aplicaciones (juegos).

Respuesta corta: TCP no está optimizado para latencia (en absoluto); como resultado, tiene varias propiedades que son asesinos de latencia para juegos (aunque entran en juego solo cuando se pierde un paquete). En particular, el bloqueo de cabeza y el retroceso exponencial tienden a ser muy molestos para los juegos de ritmo rápido.

El que más duele en la latencia es el bloqueo de cabecera (también conocido como bloqueo de HOL): si se pierde un paquete, no se permite que todos los paquetes subsiguientes dentro de la misma transmisión, aunque lleguen al otro lado de la comunicación, alcancen nivel de aplicación (¡ay!), hasta que el paquete perdido se retransmita (y esto tomará alrededor de 2 * RTT, que incluso para un servidor por continente, es de alrededor de 100 ms (= "en un tirador, ya te mataron) )).

Respuesta larga:

Es un tema complicado, y debemos distinguir varios escenarios distintos:

NOSOTROS NECESITAMOS un flujo confiable de mensajes ordenados (o bytes). En este caso, los beneficios de RUDP sobre TCP, si están presentes, son muy mínimos (podemos jugar un poco con la reducción de los tiempos de retransmisión, y eliminamos el retroceso exponencial, pero eso es más o menos). En particular, el bloqueo de cabecera de línea sigue siendo inevitable con CUALQUIER tipo de flujos ordenados confiables (ya sea TCP, RUDP o lo que sea).
NECESITAMOS una entrega de mensajes confiable pero potencialmente desordenada. Esto PUEDE evitar el bloqueo de HOL, pero requiere un manejo bastante complicado a nivel de la aplicación.
NO NECESITAMOS FIABILIDAD (= "fuego y olvídate"). Un buen ejemplo de esa información es cuando tenemos que mostrar un acierto: si no lo mostramos de inmediato, no hay necesidad de mostrarlo medio segundo después, por lo que si el paquete no lo hizo, bueno, es mejor simplemente ignorarlo y no gastar recursos en volver a enviar el paquete.
sí NECESITAMOS un estado eventualmente sincronizado (pero NO nos importa pasar por todos los estados intermedios); este es un escenario extremadamente común para simulaciones. Esto ES POSIBLE implementar sobre UDP (y sin incurrir en penalización de bloqueo de HOL). Sin embargo, habilitar la compresión sobre conexiones no confiables no es trivial, y la compresión es LA DEBE para la mayoría de los juegos. Afortunadamente, dicha compresión es factible (ver http://gafferongames.com/networked-physics/snapshot-compression/ y / o http://ithare.com/udp-from-mog-perspective/#low-latency-compression para discusión). Si se implementa este enfoque (que se puede hacer sobre paquetes completamente no confiables), proporcionará una mejora MUY significativa sobre TCP (elimina el bloqueo de HOL, por lo que estamos hablando de retrasos en el orden de los tics de red) y esto puede ser tan bajo como 1 / 120seg ~ = 8ms - sobre retardos-alrededor de RTTs, y estos son al menos 100 ms para un solo paquete perdido).

Comentario lateral:

En realidad, es posible simular UDP sobre TCP (eliminando las latencias TCP) - ver http://ithare.com/almost-zero-additional-latency-udp-over-tcp/ . Sin embargo, tenga en cuenta que para utilizarlo, todo lo anterior debe realizarse de forma manual. Todavía no hay una bala mágica que permita evitar el bloqueo de HOL para una transmisión ordenada de manera confiable; en su lugar, esta técnica permite hacer que varias conexiones TCP se comporten "casi como si" es UDP no confiable, pero no bloqueante.