Foro de elhacker.net

Hola, estoy haciendo unas pruebas con conexiones UDP, en realidad estoy en Blitz3D pero cualquier ayuda me va a venir bien, si no corresponde el tema en este sub foro, perdon..

Tengo algo asi como una aplicacion de consola, un cliente y un server, la idea es establecer una conexion UDP y poder testear la velocidad de la conexion,,

La pregunta seria: ¿como? Como hago para saber el tiempo exacto que demoro en llegar un dato de un pc al otro?

Algo asi como un comando Ping

bueno, cualquier cosa sirve,, idea o codigo ejemplo, ya sea en C o C++, yo lo adapto a Blitz

Gracias!! Saludos!!

UDP es un protocolo sin conexión

¿Has probado a empezar a contar desde que mandas el ping hasta que recibes "el pong"?

Ping suele trabajar sobre ICMP por si quieres echarle un vistazo

Hola! Gracias por la respuesta!

Bueno, si.. UDP es un protocolo nomas, digo conexión UDP por llamarlo de alguna forma jeje

Si cuento de "ping a pong" no me falsearia el resultado? No lo veo muy exacto.. pero a lo mejor son cosas mias.. voy a hacer una prueba con eso, a ver que tal..
Busco el resultado mas exacto por tratarse de un juego online.. cada comando enviado cuenta y su velocidad tambien..

Gracias! Saludos!

UDP no garantiza ni la entrega ni el orden de los paquetes. Si bien esto permite que éste protocolo sea, de base, más ligero que TCP, estas características traen problemas con los que no hay que lidiar en el caso de TCP. Por ejemplo, dado que no se mantiene una conexión persistente, cada paquete puede viajar por un camino diferente y, en consecuencia, el tiempo que tardan en llegar dos paquetes diferentes puede ser radicalmente diferente. Salvo que estés en una red local y el camino para comunicar ambos equipos sea único, es posible que la medida de tiempos no sea especialmente útil.


Aún así, si quieres testear el tiempo tienes que tener en cuenta lo siguiente:

* Si el tiempo a medir es únicamente en una dirección, es decir, únicamente te interesa el tiempo que tarda el paquete en ir de A a B, necesitas que ambos equipos tengan la hora perfectamente sincronizada. Si no es así, dado que estamos hablando de plazos de, normalmente, una centésima o menos, los cálculos de tiempo que realices tendrán un margen de error bastante amplio. Para contar el tiempo en este caso necesitas enviar en el mensaje la hora exacta del equipo A en el momento de enviar el mensaje; el equipo B recibe la hora, la compara con su hora interna y calcula la diferencia.

* Si el tiempo a medir es el de una petición y una respuesta, has de tener en cuenta que hay mensajes que se pueden perder y, los que no se pierdan, pueden tener tiempos de respuesta bastante dispares. El cálculo de tiempo en este caso es similar al anterior: el equipo A empaqueta la hora en el mensaje y lo envía, el equipo B recibe el mensaje, recupera la hora y se la envía de vuelta al equipo A. Ahora el equipo A calcula la diferencia entre la hora recibida y la hora actual y con eso obtienes el tiempo de respuesta.

Lo suyo sería hacer un envío de varios mensajes diferentes para intentar calcular un tiempo medio, pero imagino que ya has pensado en eso.

Un saludo.

Los protocolos con conexión, por ejemplo tcp, tampoco garantizan nada de eso, sería un caos si cada vez que tu creas una conexión tuvieses poder sobre los protocolos de enrutamiento,  sobre los recursos, etc,  del resto de Internet...
Otra cosa sería, por ejemplo, protocolos con reserva de recursos.
Perdón por el semi-offtopic :-)

Con TCP los paquetes no se "pierden" porque entonces eso significa que la conexión se ha cortado. Así mismo, TCP garantiza el orden en el que llegan los paquetes porque crea una conexión persistente y única por la que van a viajar todos los mensajes que se transmitan por esa conexión. Es por este motivo que una conexión TCP es, por definición, mucho más pesada y lenta que una conexión UDP.

Al menos así es como lo recordaba.

Hola! Gracias por responder

El problema que tuve con TCP cuando hice unas pruebas anteriores es la lentitud, los objetos del juego se desfasaban, y tenia 2 situaciones diferentes en las 2 pantallas (no me imagino con 10 players, caos total)

Yo calculo que con UDP eso se podría mejorar bastante.. y empiezo a citar:


Yo creo que el mayor problema es el orden de los paquetes, ya que si alguno no llega, bueno, llegara el siguiente y con eso puedo actualizar la pantalla y poner a los jugadores en posición nuevamente.. (claro, si justo el paquete que no llega es por ejemplo: un disparo, puede ser mas molesto)

Debería de ordenar los paquetes e indicar de que jugador pertenece X paquete?

Voy a tener en cuenta esos consejos eferion,, yo creo que deberia ser un paquete de ida y vuelta, y calcular el promedio (si, habia pensado en sacar el promedio exactamente ;) )




Seguro no "garantiza" la llegada de los datos? Tengo entendido que si.. si se pierde algún paquete es por desconexion...

Gracias por las respuestas!! Voy a intentar con esos consejos!

Saludos!

Únicamente he dicho que no aseguraba lo citado en mi mensaje anterior.

Algo estarías haciendo mal. Aunque TCP sea algo más lento que UDP, es totalmente despreciable comparado con los 100ms de ping con los que puede jugar cualquier persona a un juego online perfectamente.

Si, pero si ponemos eso en un loop (por ejemplo), los bytes empiezan a sumar.. Ademas no es tan importante que se pierda algun paquete.. (tampoco es que se pierdan a cada rato)

Esta parte si me dejo dudas: Debería de ordenar los paquetes e indicar de que jugador pertenece X paquete?

Perdon la doble pregunta,, es que no quiero que pase desapercibida..

Saludos! Gracias!

Depende de como sea el juego, eso tendrás que decidirlo tú según las necesidades y la estructura.

Ordenar paquetes quizás no tenga sentido en el caso que comentas. Lo que puedes hacer es poner un contador incremental en cada paquete. Entonces, lo que tienes que hacer es almacenar el id del último paquete recibido... si recibes un paquete con un identificador anterior, lo descartas sin miedo.

También puedes, para evitar desbordamientos del contador, usar una ventana de descartes. Por ejemplo, si recibo el identificador X se que he de descartar automáticamente los 10.000 mensajes anteriores, si recibo un mensaje con cualquier otro id entonces lo tomo como válido.

Otra opción para evitar el desbordamiento es usar la fecha y la hora en lugar de un contador, pero esta solución implica algo más de código.

Por otro lado, si no pasa nada porque se pierda algún paquete es preferible usar UDP, ya que es mucho más versátil y lo puedes adaptar a cualquier necesidad. Además, piensa que, en general, un paquete se perderá únicamente si hay sobrecarga en la red, lo cual no suele ser algo tan extremadamente común.

Un saludo.

Eso me gusta.. y podría almacenar datos (movimientos, disparos, acciones) previas de cada jugador.. aunque no es quizá tan necesario..

Usando la hora también me gusta, pero supone una carga mas para el host.. tener que revisar la hora por cada jugador, comparar, etc..


El juego es de aviones, tiene misiones y (si todo sale bien con udp) modo versus

Ya lo tengo medio completo el test, gracias por las respuestas!

Saludos!