leyendo parcialmente de sockets

Question

Tengo un pequeño programa de prueba que envía muchos paquetes udp entre el cliente-> servidor-> cliente (prueba ping/pong). Los paquetes son de tamaño fijo en cada ejecución (la última ejecución es el tamaño máximo permitido de paquete udp). Estoy rellenando los paquetes con datos aleatorios, excepto el comienzo de cada paquete que contiene el número de paquete. Entonces, solo estoy interesado en ver si recibo todos los paquetes en el cliente.

Estoy usando sendto() y recvfrom() y solo leo el tamaño de (packet_number) (que en este caso es un int). ¿Qué pasa con el resto de los datos? ¿Termina en Fairyland (se descarta)? ¿O el nuevo paquete que llega se agrega a este "viejo" de datos?

(usando Linux)

Answer 1

Cada lectura de las colas de socket UDP un datagrama completo de la memoria intermedia de recepción del socket del kernel, no importa cuál sea su tamaño de buffer de usuario. Es decir:

• Si su búfer es más grande que el siguiente datagrama pendiente, leerá menos que su tamaño de búfer.
• Si su memoria intermedia es más pequeña, leerá el valor de su tamaño de búfer y el resto de los datos se descartarán.
• Puede establecer la opción MSG_TRUNC en el flags, por lo que recv(2) devolverá la longitud total del datagrama, no solo la parte que ha leído en el buffer de userland.

Espero que esto ayude.

Answer 2

no he probado esto, pero desde mi interpretación de la página del manual, siempre se descartarán. Esto parece razonable ya que de lo contrario no habría forma de detectar el comienzo del siguiente paquete.

Hay dos maneras de detectar el truncamiento:

usar la bandera MSG_TRUNC. recvfrom devolverá el tamaño real del paquete incluso si no se ajusta al búfer proporcionado. Entonces, simplemente puede verificar si el valor de retorno es más grande que el len que dio como argumento.

Utilice recvmsg y compruebe la estructura devuelta para la bandera MSG_TRUNC.

Para evitar la truncación, use un buffer de 64k. Los paquetes UDP no pueden ser más grandes que eso (campo de 16 bits de longitud en el protocolo).

Answer 3

Para responder a su primera pregunta, ¿los datos se descartan? Sí lo hace. Los protocolos IP & ARP entran en juego cuando su paquete es más grande que el Path MTU. La MTU de ruta es la unidad de transmisión máxima de la ruta entre su cliente y su servidor. Suponiendo que su tarjeta NIC es una tarjeta ethernet estándar, entonces su MTU máxima es de 1500. Ahora, supongamos que la MTU de ruta completa entre su cliente y el servidor es 1500. En este escenario, si envía cualquier paquete que sea mayor que 1472 bytes (1500 - (encabezado de 20 bytes IP) - (encabezado UDP de 8 bytes)) entonces se producirá la fragmentación de IP. Lo que sucederá entonces es que la capa de IP cortará el paquete en fragmentos para cumplir con la MTU del enlace de ethernet. Ahora, antes de poder enviar cualquier información, la dirección MAC del destino debe ser resuelta. Entonces, de repente, el protocolo ARP recibirá múltiples fragmentos de IP que solicitan la misma resolución de IP a MAC. Lo que sucederá entonces es que ARP iniciará una solicitud ARP para el primer paquete recibido y esperará la respuesta ARP.Mientras espera, ARP descartará todos los fragmentos que realizan la misma solicitud de ARP y solo hará cola en el último fragmento que haya llegado. Por lo tanto, si envía un paquete de más de 1472 bytes, no espere recibir el paquete completo en el otro extremo si su caché ARP está vacía.

¿Tiene el paquete recién llegado conseguir adjunta al No, no consigue anexa. UDP es un protocolo de datagramas con límites estrictos de mensajes. Por lo tanto, cada paquete que llega se considera como un datagrama completo independiente; los datos no serán agregados.