Como detectar se a rede está descartando pacotes UDP?

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, paro de receber pacotes UDP por 2 segundos e o fluxo é retomado como se nada estivesse errado.

Corri o http://www.pingtest.net/ no local do cliente e ele voltou excelente. Sem pacotes descartados e baixa latência. A única diferença que notei entre os dois locais é o ping google.catempo limite no local, mas funciona no meu.

Como faço para testar se a rede em que estou bloqueia os pacotes UDP recebidos? Existe uma maneira de eu isolar quem está descartando os pacotes?

networking udp

— Gili
fonte

Parece um problema de firewall para mim. Você tem algum firewall de software ou hardware?

— Pitbull

Você não pode perguntar ao cliente como sua configuração de rede está definida?

— Ramhound

@ Ramhound, idealmente não. Eu não quero ter que cavar em configurações do roteador um potencial cliente cada vez que eu quero demonstrar meu produto :)

— Gili

Gente, por favor, explique seus votos negativos, caso contrário eu não posso responder.

— Gili

Respostas:

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

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

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

Observe o -uque instrui o netcat a usar o UDP. (E também esteja ciente de que existem versões diferentes de netcat, que precisarão do -pparâmetro ou não; dadas as variantes dos dois mais comuns (?), Ambos incluídos no Debian.)

No local do consumidor: nc -u [addr of machine A] 1234.

Tente enviar algum texto ou, melhor ainda, use pipes para enviar um arquivo entre os dois locais e faça uma diferença depois.

— mpy
fonte

Seu comando remoto falha para mim. A página de manual diz para -l, “ It is an error to use this option in conjunction with the -p, -s, or -z options.”, para que eu tenha corrigido o comando para que eu testei ao trabalho. Além disso, mudei 'ip' para 'addr' porque nomes de host também podem ser usados e, de certa forma, são um 'endereço'.

— James Haigh

@ JamesHaigh: Eu concordo com você no ponto addrvs. ipMas agora com o seu comando, recebo um erro: listen needs -p arg(eu testei meus comandos dados na resposta também ;)). Existem vários nc por aí, se você der mais alguns detalhes, como a versão nc e / ou sua distribuição, adicionarei uma nota à minha resposta.

— Mpy

Oh, certo, é uma pena que eles não sejam mutuamente compatíveis! :-( Ok, então minha máquina remota é Debian. O nccomando padrão é o link simbólico /bin/nc -> /etc/alternatives/nc -> /bin/nc.openbsdfornecido pelo pacote Debian netcat-openbsd. Minha máquina Ubuntu local também possui nc.openbsdpor padrão. Nenhuma aceita -l -p. Também instalei ncatnas duas máquinas a partir do nmappacote Ubuntu / Debian. a máquina Debian mais velho, ncatse recusa -l -p, mas ncatno Ubuntu aceita ambos os sentidos Embora a versão Debian deve ser antigo, uma vez que irritantemente não tem a. --sctpopção: -. /

— James Haigh

Ps Qual é a sua distribuição e ncvariante? Percebo que também há um netcat-traditionalpacote ' ', mas ainda não tentei.

— James Haigh

@ JamesHaigh: Eu realmente uso netcat-traditional(v 1.10-38) como ele é enviado com o debian. Obrigado pela sua dica, incluí agora as duas variantes na resposta.

— mpy

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>

— ckarrie
fonte

Esta é a verdadeira resposta. Requer acesso ao servidor do outro lado. Mas fornece feedback direto sobre a perda de pacotes. E você também pode usá-lo para testar a largura de banda TCP.

— DragonFax

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

Pode valer a pena fazer com que seu aplicativo volte ao SCTP ou mesmo ao TCP. Na verdade, encontrei essa pergunta porque estava procurando como rejeitar pacotes UDP recebidos de usuários que usavam mais do que sua parte do downlink quando este estava congestionado, porque, diferentemente de SCTP e TCP, o UDP não tem controle de congestionamento, tornando muito difícil priorizar o downlink tráfego.

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

Não é uma má idéia ter um substituto, em vez de confiar apenas no UDP. Mesmo se você voltar ao TCP, pelo menos poderá dizer que está funcionando, talvez não seja o ideal.

— James Haigh
fonte