Por q en los juegos actuales se usa UDP en vez de TCP. Pensaba que TCP seria mas rapido para eso ademas de mas fiable.
Saludos
Por lo que he leido, TCP asegura que los paquetes llegan, siendo más lento. UDP no lo asegura, ahí es donde tienes que meter tú un sistema de validación que si no llega un paquete, lo reenvie. Parece ser que en total , UDP es más rápido. Busca información por la red...
Cierto, no recordaba todo aquello del protolo de ventana edslizante, de todas maneras aunque nos aseguremos q llegan, tenemos hecho un camino para nosotros(virtual) y no tenemos q mandar la IP cada vez q enviamos.. sigo sin entender
TCP es un protocolo de nivel transporte "fiable" y orientado a conexion, es decir, necesita primeramente establecer una conexión con el otro extremo y además nos asegura de que los paquetes que enviamos llegan al otro extremo, de ahí que sea un protocolo más "pesado" lo que hace que sea más lento. Sin embargo UDP es "no fiable" y no hay que establecer conexión alguna, es "ligero" más rápido al tener que meter menos cosas en las cabeceras, etc, de ahí que hayan optado por usarlo en juegos, ya que tiene que ir lo más rápido posible además de que si estamos hablando de jugar en "red local" la pérdida de paquetes es muy pequeña por decir inexistente, cuando se juega a través de internet, es decir, usando un server como batlenet por ejemplo, el protocolo usado es tcp ya que es "fiable" como ya dije, espero que esto conteste a tu prengunta.
Un saludo.
Bueno respeto a este tema una cosa, comentas que UDP se utiliza por su rapidez en las redes LAN, bueno esto quizá sería en las redes de 10/MBits, actualmente todas las redes són como mínimo de 100 MBits tendiendo al Giga , con eso quiero decir que TCP tiene que tendir a ser un protocolo viable para el intercambio rápido de datos en una red de area local
Saludos
_________________
Saludos --{Undol}--
[ Este Mensaje fue editado por: undol el 2002-05-12 23:58 ]
UDP no se utiliza porque la red sea de 10Mbits/100Mbits/Gigabit, sino porque en una red de tipo lan, la pérdida de paquetes es mínima. Porque usar TCP que resuelve las pérdidas, si en una red lan, casi no las hay? ya te digo TCP me parece estupendo para internet, pero para una lan mejor UDP. Usar tcp en lan es matar moscas a cañonazos!
Un saludo.
Supongo que otro de los motivos sera que con UDP el servidor puede enviar la misma informacion a todos ordenadores de la LAN usando broadcast...
Hombre la idea de usar UDP y no usar TCP es poque en UDP pudo hacer esto:
Mandar A fiable B no fiable y C no fiable
y si recibo la secuencia:
C(T1) B(T50) A(T90)
puedo ir procesando C ( si no necesito orden ) y no tener q esperar a T90 para procesar B y C.
Ese es el principal motivo.
Puedes detallar un poco mas el tema, no acabo de pillar el tema del fiable no fiable,en que estados se da la situacion y como responde ! etc !!
La idea de utilizar de UDP es principalmente su rapidez de entrega frente a TCP. El problema es que no garantiza la entrega de paquetes (a diferencia de TCP).
A la hora de desarrollar un multiplayer se puede añadir una capa para garantizar que los paquetes UDP son entregados al destinatario siempre y en orden. Esto le "acerca" al protocolo TCP y lo hace más lento.
En cambio, a la hora de desarrollar la aplicación se puede determinar que eventos del juego necesitan confirmación de entrega o un cierto orden y cuales no.
Por ejemplo, eventos como el movimiento de un personaje (en un juego como Diablo, por ej.) pueden enviarse como paquetes UDP no fiables, ya que un jugador enviara varios movimientos en muy pocos segundos y con una conexión decente la perdida de paquetes no suele rondar mas del 10% asi que un movimiento "posterior" anula los anteriores y la percepeción en el resto de jugadores sobre el movimiento del primero es casi normal.
En cambio, eventos que afectan al estado del juego, como un impacto a otro personaje, recoger un objeto, etc... deben ser enviados como paquetes UDP "fiables" para tener la certeza que el resto de jugadores han recibido ese evento y la percepción del entorno de juego sea homogenea.
En resumen, la idea está en aprovechar parte de las características de cada protocolo (TCP y UDP) pero construyendolas desde UDP.
Saludos.
Milinko.
Entiendo vuestras peocupaciones , y veo ciertas ventajas quen el protocolo UDP, pero lo de matar moscas a cañonazos es un poco exagerado, creo conveniente recordar que si lo que acabas haciendo es un control del protocolo UDP es como reinventar TCP,y me parece que los estudiantes de Berkley ya realizaron una buena faena con el tema.
En un entorno como hostil como internet si que utilizaría UDP pero en una Lan creo que me decantaría por TCP.
Tengo que reconocer que solamente he programado de forma real en entornos TCP, quizá me falte realizar lo mismo con UDP para encontrar vuestras preocupaciones
Saludos
El protocolo TCP, al ser "fiable", garantiza la entraga de todos los paquetes. Pero si estamos jugando al Counter-Strike, por ejemplo, y nos disparan y nos matan:¿para qué queremos recibir información de algo que ya pasó(la secuencia de disparos,etc), si ahora ya estamos muertos? Simplemente notamos que ibamos andando y aparecemos muertos(maldita la gracia). Eso es UDP. ¿no?
Nop, yo diria que eso es una bala xDDD
Undol, no se trata de reinventar el protocolo TCP. Lo que se pretende es añadir al protocolo UDP las características de orden y fiabilidad, que, efectivamente, son características propias de TCP pero no las únicas.
El protocolo TCP además de ello, tiene un protocolo de conexión/desconexión bastante costoso y, como ya expliqué en algun post anterior, otras historias como menor prioridad de transporte frente a UDP, cabeceras mas grandes, control de flujo, etc.
Vamos, que la idea no es reconstruir TCP sino hacer un protocolo sobre UDP con alguna tecnica de corrección de errores.
Sobre LAN, te va a dar igual, como bien dices porque los algoritmos de TCP y UDP son "despreciables" respecto al tiempo de entrega de los paquetes, pero si quieres asegurarte un buen funcionamiento posterior sobre Internet te recomiendo UDP sin ninguna duda (en juegos de tiempo real, en juegos de "turnos" es mas sencillo hacerlo sobre TCP, evidentemente).
Venga, un saludo
Milinko.
Nada, que hace tiempo lei este topic y como ahora se la respuesta, pos la posteo.
Y la respuesta es: Canales PUSH
Hasta ahora los juegos y muchas aplicaciones tenian arquitectura cliente servidor, ahora se ha diseñado una nueva arquitectura llamada "publisher subscriber" en la que el servidor hace un multicast con los datos que necesitan los clientes.
Buscad info sobre ello, es mu interesante, el tema esta en que como el servidor lanza los mismos datos para todos (multicast) solo se puede hacer sobre protocolo UDP, sobre este protocolo hay otro que hace control de flujo, de autentificacion de receptores y temas similares (como el MIDP: Multiport Information Ditribution Protocol)
Un saludo.
Dario! :lengua:
Despues de ver las tramas de UDP, TCP y ver sus caracteristicas es normal el uso de UDP en redes amplias como internet. Dado que una factor muy importante es el tiempo de respuesta (jode mucho cuando te comes un rocket [quake2 rocks] por culpa del lag). TCP usa mecasnimos de ventana deslizante y demas que controlan el flujo y no envia datos "a lo tonto" sino que "espera" a q la ventana (buffer) del receptor tenga un tamaño lo suficientemente grande para q el envio sea eficiente. UDP no tiene ese control, manda sin sentido xD por ello y por las razones q comentas supongo yo q se usara UDP.
Por otra parte si miras la funcion send existen unos flags que indican caracteristicas del envio. Una de ellas es OOB q envia los datos "a la fuerza". En el datagrama IP tb exiten flags para el envio "urgente" etc.
Un saludo