Usando nodejs puedo transmitir paquetes udp con una carga útil de 50000 caracteres. Pero no puedo hacerlo con socat (Linux ubuntu 20.04 tanto en el cliente como en el servidor).
Para esta prueba he estado usando una VPN que conecta el host de mi casa con el host de mi trabajo. Esperaba cierta pérdida de datos con socat, ¡pero no hasta ese punto!
En el host remoto (de trabajo), un servidor socat espera una solicitud para enviar una respuesta udp inflada > 50000 bytes.
cat <<EOF > sotest.sh
#!/bin/bash
head -c 50000 < /dev/zero | tr '\0' 'q'
EOF
chmod +x sotest.sh
socat udp4-listen:13000,reuseaddr,fork EXEC:"./sotest.sh" # server
#client
printf "trigger" |socat -T 5 -,ignoreeof udp4:10.50.1.184:13000,sndbuf=64000,rcvbuf=64000 > t.t
Y verificar el tamaño del mensaje wc -c t.tme da alrededor de 8k caracteres en lugar de 50k.
Si uso mi cliente/servidor nodejs udp, el cliente nodejs recibe en su totalidad el mensaje de 50k caracteres enviado por el servidor. cliente :https://jsfiddle.net/xtcpL63a/ servidor:https://jsfiddle.net/851fc7bp/
La única pista que tengo es el mensaje de error con socat que sólo se puede ver en modo de depuración.
022/12/03 22:37:40 socat[1051733] N forked off child process 1051734
2022/12/03 22:37:40 socat[1051733] N forked off child process 1051734
2022/12/03 22:37:40 socat[1051733] I close(7)
2022/12/03 22:37:40 socat[1051733] I resolved and opened all sock addresses
2022/12/03 22:37:40 socat[1051733] N starting data transfer loop with FDs [5,5] and [6,6]
2022/12/03 22:37:40 socat[1051733] I transferred 73 bytes from 5 to 6
2022/12/03 22:37:40 socat[1051734] I just born: child process 1051734
2022/12/03 22:37:40 socat[1051734] I close(4)
2022/12/03 22:37:40 socat[1051734] I close(3)
2022/12/03 22:37:40 socat[1051734] I close(6)
2022/12/03 22:37:40 socat[1051734] I dup2(7, 0) -> 0
2022/12/03 22:37:40 socat[1051734] I dup2(7, 1) -> 1
2022/12/03 22:37:40 socat[1051734] I close(7)
2022/12/03 22:37:40 socat[1051734] N execvp'ing "./sotest.sh"
2022/12/03 22:37:40 socat[1051733] I transferred 8192 bytes from 6 to 5
2022/12/03 22:37:40 socat[1051733] I transferred 8192 bytes from 6 to 5
2022/12/03 22:37:40 socat[1051733] I transferred 8192 bytes from 6 to 5
2022/12/03 22:37:40 socat[1051733] I transferred 8192 bytes from 6 to 5
2022/12/03 22:37:40 socat[1051733] I transferred 8192 bytes from 6 to 5
2022/12/03 22:37:40 socat[1051733] I transferred 8192 bytes from 6 to 5
2022/12/03 22:37:40 socat[1051733] I transferred 848 bytes from 6 to 5
2022/12/03 22:37:40 socat[1051733] E read(5, 0x5566b4417150, 8192): Connection refused
2022/12/03 22:37:40 socat[1051733] N exit(1)
2022/12/03 22:37:40 socat[1051733] I shutdown(5, 2)
2022/12/03 22:37:40 socat[1051733] I shutdown(6, 2)
Este problema no puede estar relacionado con el búfer en el lado de Linux, tampoco puede estar relacionado con mtu. Entonces, ¿qué está pasando con socat?
Solución: Tero Kilkanen señaló el problema. Obligar a socat a utilizar buffers más grandes en el lado del cliente me permitió recibir el mensaje en su totalidad; resuelve pero realmente no explica este comportamiento...
#client
printf "${MSG}" |socat -b100000 -T 5 -,ignoreeof udp4:10.50.1.184:13000,sndbuf=64000,rcvbuf=64000 > t.t
Del lado del servidor, aseguró que se enviara un paquete; Puedes ver la diferencia de comportamiento en los registros de depuración:
socat -b100000 -d -d -d udp4-listen:13000,reuseaddr,fork EXEC:"./sotest.sh"
Respuesta1
socatEl tamaño de búfer predeterminado es 8k. Solo está configurando el tamaño del búfer en el lado del cliente. Por lo tanto, el servidor utiliza el tamaño de búfer predeterminado de 8k. Por eso los paquetes se envían en datagramas UDP de 8k.
Entonces, por alguna razón, el cliente sólo lee el primer datagrama UDP enviado por el servidor.