Como detectar se a rede está descartando pacotes UDP?

Question

Eu tenho um aplicativo de streaming de vídeo que funciona bem no meu escritório, mas falha miseravelmente no local do cliente. O sintoma é que a cada dois segundos eu paro de receber pacotes UDP por 2 segundos, então o fluxo recomeça como se nada estivesse errado.

Eu corri o link no local do cliente e ele voltou excelente. Nenhum pacote descartado e baixa latência. A única diferença que notei entre os nossos dois locais é que ping google.ca vezes em sua localização, mas funciona no meu.

Como testar se a rede em que estou bloqueia pacotes UDP de entrada? Existe uma maneira de isolar quem está descartando os pacotes?

    

Answer 1

Você pode tentar estabelecer uma conexão UDP com netcat .

Em uma máquina A fora da rede do consumidor:

nc -u -l -p 1234            # if using netcat-traditional
nc -u -l 1234               # if using netcat-openbsd (as pointed out by @JamesHaigh)

Observe o -u que instrui o netcat a usar o UDP. (E também esteja ciente de que existem diferentes versões de netcat , que precisarão do parâmetro -p ou não; dado são as variantes para as duas mais comuns (?), Ambas incluídas no Debian.)

Na localização do consumidor: nc -u [addr of machine A] 1234 .

Tente enviar enviar algum texto ou até mesmo usar melhor os canais para enviar um arquivo entre os dois locais e fazer um diff depois.

    

Answer 2

no lado do servidor, estabeleça um servidor UPD com

iperf -s -u

no lado do cliente, verifique a conexão UDP com

iperf -u -c <IP Address of Server>

    

Answer 3

Os comandos netcat na resposta de mpy são úteis para fins de diagnóstico, mas estou complementando essa resposta com outra abordagem para seu problema subjacente.

Pode valer a pena fazer com que seu aplicativo volte a SCTP ou até mesmo ao TCP. Eu realmente encontrei essa pergunta porque eu estava procurando como rejeitar pacotes UDP de entrada de usuários usando mais do que sua parte do downlink quando está congestionada, porque ao contrário de SCTP e TCP, o UDP não tem controle de congestionamento tornando muito difícil priorizar o downlink tráfego.

Tanto o SCTP quanto o TCP têm controle de congestionamento e funcionam muito bem com QoS, mas o SCTP tem o benefício adicional sobre o TCP que foi projetado para aplicativos de streaming em tempo real, o que o torna um bom substituto para TCP e UDP. Com efeito, o SCTP é o melhor dos dois protocolos de transporte mais comuns.

Não pode ser uma má ideia ter um substituto, em vez de confiar apenas no UDP. Mesmo se você só voltar ao TCP, então pelo menos você pode dizer que está funcionando, talvez não otimamente.