 Autor
|
Tema: Como probar una conexion UDP (Leído 7,177 veces)
|
Vaagish
 Desconectado
Mensajes: 875
|
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!!
|
|
|
|
|
En línea
|
|
|
|
A.I.
Desconectado
Mensajes: 61
|
establecer una conexion UDP
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
|
|
|
|
|
En línea
|
|
|
|
Vaagish
Desconectado
Mensajes: 875
|
 |
Re:
« Respuesta #2 en: 3 Marzo 2015, 01:40 am » |
|
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!
|
|
|
|
|
En línea
|
|
|
|
eferion
Desconectado
Mensajes: 1.248
|
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 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. La pregunta seria: ¿como? Como hago para saber el tiempo exacto que demoro en llegar un dato de un pc al otro? 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.
|
|
|
|
|
En línea
|
|
|
|
A.I.
Desconectado
Mensajes: 61
|
...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...
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 :-)
|
|
|
|
|
En línea
|
|
|
|
eferion
Desconectado
Mensajes: 1.248
|
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... 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.
|
|
|
|
|
En línea
|
|
|
|
Vaagish
Desconectado
Mensajes: 875
|
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: 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. 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  ) Los protocolos con conexión, por ejemplo tcp, tampoco garantizan nada de eso 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! |
|
|
|
« Última modificación: 3 Marzo 2015, 18:00 pm por Vaagish »
|
En línea
|
|
|
|
A.I.
Desconectado
Mensajes: 61
|
Seguro no "garantiza" la llegada de los datos?
Únicamente he dicho que no aseguraba lo citado en mi mensaje anterior.
|
|
|
|
|
En línea
|
|
|
|
T. Collins
Desconectado
Mensajes: 206
|
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:
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.
|
|
|
|
|
En línea
|
|
|
|
Vaagish
Desconectado
Mensajes: 875
|
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!
|
|
|
|
|
En línea
|
|
|
|
|
 |
