Foros - Stratos

Programadores => Programación en red => Mensaje iniciado por: Degiik en 08 de Abril de 2004, 12:58:45 AM

Título: Varias Sobre Udp
Publicado por: Degiik en 08 de Abril de 2004, 12:58:45 AM
 Cuando se usan sockets UDP, con 'recvfrom' se recibe el 'sento' enviado¿?, o puede ser que el 'sendto' se fragmente en paquestes y se necesiten varios 'recvfrom' para construir el 'sento' enviado. ( como ocurre con sockets TCP ).

Que forma ofrece mejor rendimiento para recoger los datagramas, asincrona o sincrona + hilo.

Thanks.
Título: Varias Sobre Udp
Publicado por: rrc2soft en 08 de Abril de 2004, 04:39:12 AM
 
CitarCuando se usan sockets UDP, con 'recvfrom' se recibe el 'sento' enviado¿?, o puede ser que el 'sendto' se fragmente en paquestes y se necesiten varios 'recvfrom' para construir el 'sento' enviado. ( como ocurre con sockets TCP ).
En UDP, todo lo que envias con el sendto se recibe (o no... UDP no es "confiable" como TCP) con el recvfrom. Eso si, no hay fragmentacion: si envias 100 bytes, o recibes 100 o recibes 0. Eso ocurre porque UDP es un protocolo orientado a datagrama (paquete), y el paquete es la unidad minima de informacion. TCP es un protocolo orientado a flujo de datos, de ahi que un paquete saliente pueda transformarse en varios entrantes.

CitarQue forma ofrece mejor rendimiento para recoger los datagramas, asincrona o sincrona + hilo.
...algun alma caritativa que responda a esta parte de la pregunta...  ;)  
Título: Varias Sobre Udp
Publicado por: ethernet en 08 de Abril de 2004, 01:09:24 PM
 Supongo que esto ultimo dependera del SO que estes usando aunque la verdad yo no me pararia en mirar esas menudencias que la verdad no afectan nada al rendimiento final. Si te sirve de algo el quake pone el socket no bloqueante y hace poll en cada frame.
Título: Varias Sobre Udp
Publicado por: Zaelsius en 08 de Abril de 2004, 01:13:31 PM
 Pozi, UDP no fragmenta los paquetes, y además el tamaño máximo de éstos es de 4096 bytes(4KB)
Título: Varias Sobre Udp
Publicado por: Degiik en 08 de Abril de 2004, 06:34:19 PM
 thanks por la info