Cliente/servidor Socat udp com mensagem truncada

Cliente/servidor Socat udp com mensagem truncada

Usando nodejs posso transmitir pacotes udp com uma carga útil de 50.000 caracteres. Mas não consigo fazer isso com o socat (Linux ubuntu 20.04 no cliente e no servidor).

Para este teste, usei uma VPN conectando meu host doméstico ao meu host de trabalho. Eu esperava alguma perda de dados com o socat, mas não tanto!

No host remoto (de trabalho), um servidor socat aguarda uma solicitação para enviar de volta uma resposta udp inchada > 50.000 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 

E verificar o tamanho da mensagem wc -c t.tme dá cerca de 8 mil caracteres em vez de 50 mil.

Se eu usar meu cliente/servidor udp nodejs, a mensagem de 50k caracteres enviada pelo servidor será recebida na íntegra pelo cliente nodejs. cliente :https://jsfiddle.net/xtcpL63a/ servidor:https://jsfiddle.net/851fc7bp/

A única pista que tenho é a mensagem de erro com socat que pode ser vista apenas no modo de depuração

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 não pode estar relacionado ao buffer do lado do Linux, nem pode estar relacionado ao mtu. Então, o que está acontecendo com socat ?

Solução: Tero Kilkanen apontou o problema. Forçar o socat a usar buffers maiores do lado do cliente me permitiu receber a mensagem na íntegra; resolve, mas não explica realmente esse comportamento ...

#client
printf "${MSG}" |socat -b100000 -T 5 -,ignoreeof udp4:10.50.1.184:13000,sndbuf=64000,rcvbuf=64000 > t.t 

Do lado do servidor, garantiu que um pacote fosse enviado; você pode ver a diferença de comportamento nos logs de depuração:

socat -b100000 -d -d -d udp4-listen:13000,reuseaddr,fork EXEC:"./sotest.sh"

Responder1

socato tamanho do buffer padrão é 8k. Você está configurando apenas o tamanho do buffer no lado do cliente. Portanto, o servidor usa o tamanho padrão do buffer de 8k. É por isso que os pacotes são enviados em datagramas UDP de 8k.

Então, por algum motivo, o cliente lê apenas o primeiro datagrama UDP enviado pelo servidor.

informação relacionada