Come rilevare se la rete sta abbandonando i pacchetti UDP?

Ho un'applicazione di streaming video che funziona bene nel mio ufficio ma fallisce miseramente nella posizione del cliente. Il sintomo è che ogni paio di secondi, smetto di ricevere pacchetti UDP per 2 secondi, quindi il flusso riprende come se nulla fosse sbagliato.

Ho eseguito http://www.pingtest.net/ presso la sede del cliente ed è tornato eccellente. Nessun pacchetto rilasciato e bassa latenza. L'unica differenza che ho notato tra le nostre due posizioni è che il ping google.catimeout nella loro posizione ma funziona nella mia.

Come posso verificare se la rete su cui mi trovo blocca i pacchetti UDP in arrivo? C'è un modo per isolare chi sta lasciando cadere i pacchetti?

networking udp

— Gili
fonte

Mi sembra un problema con il firewall. Hai dei firewall software o hardware?

— Pitto,

Non puoi chiedere al cliente a cosa è impostata la sua configurazione di rete?

— Ramhound,

@Ramhound, idealmente no. Non voglio scavare nelle impostazioni del router di un potenziale cliente ogni volta che voglio provare il mio prodotto :)

— Gili,

Ragazzi, per favore, spiegate i vostri voti negativi, altrimenti non posso rispondere.

— Gili,

Risposte:

Puoi provare a stabilire una connessione UDP con netcat.

Su una macchina A esterna alla rete del consumatore, eseguire:

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

Notare ciò -uche indica a netcat di usare UDP. (E attenzione, ci sono diverse versioni di netcat, che avranno bisogno del -pparametro o no; date sono le varianti per le due più comuni (?), Entrambe incluse in Debian.)

Sulla posizione dei consumatori: nc -u [addr of machine A] 1234.

Prova a inviare invia del testo, o ancora meglio usa le pipe per inviare un file tra le due posizioni e fai una diff in seguito.

— mpy
fonte

Il tuo comando remoto non riesce per me. Il man dice per -l, “ It is an error to use this option in conjunction with the -p, -s, or -z options.”, così ho corretto il comando per quello che ho provato al lavoro. Inoltre, ho cambiato 'ip' in 'addr' perché anche i nomi host possono essere usati e in un certo senso sono un 'indirizzo'.

— James Haigh,

@JamesHaigh: sono d'accordo con te sul punto addrvs. ipMa ora con il tuo comando, ricevo un errore: listen needs -p arg(ho testato anche i miei comandi forniti nella risposta ;)). Ci sono vari nc là fuori, se dai qualche dettaglio in più come la versione nc e / o la tua distribuzione, aggiungerò una nota alla mia risposta.

— MP

Oh giusto, è un peccato che non siano reciprocamente compatibili! :-( Ok, quindi la mia macchina remota è Debian. Il nccomando predefinito è il link simbolico /bin/nc -> /etc/alternatives/nc -> /bin/nc.openbsdfornito dal pacchetto Debian netcat-openbsd. Anche la mia macchina Ubuntu locale ha nc.openbsddi default. Nessuno dei due accetterà -l -p. Ho installato anche ncatsu entrambe le macchine dal nmappacchetto Ubuntu / Debian. la vecchia macchina Debian, ncatrifiuta -l -p, ma ncatsu Ubuntu accetta entrambi i modi. Anche se la versione Debian deve essere antica in quanto fastidiosamente non ha l' --sctpopzione.: - /

— James Haigh

Ps Qual è la tua distribuzione e la tua ncvariante? Ho notato che esiste anche un netcat-traditionalpacchetto " ", ma non l'ho provato.

— James Haigh,

@JamesHaigh: effettivamente uso netcat-traditional(v 1.10-38) come viene fornito con debian. Grazie per il tuo suggerimento, ora ho inserito entrambe le varianti nella risposta.

— mpy

sul lato server, stabilire un server UPD con

iperf -s -u

sul lato client, controlla la connessione UDP con

iperf -u -c <IP Address of Server>

— ckarrie
fonte

Questa è la vera risposta. Richiede l'accesso al server dall'altra parte. Ma ti dà un feedback diretto sulla perdita di pacchetti. E puoi anche usarlo per testare la larghezza di banda TCP.

— DragonFax,

I netcatcomandi nella risposta di mpy sono utili per scopi diagnostici, ma sto completando quella risposta con un altro approccio al tuo problema di fondo.

Potrebbe valere la pena fare in modo che l'applicazione ricada su SCTP o anche su TCP. In realtà ho trovato questa domanda perché stavo cercando come rifiutare i pacchetti UDP in arrivo dagli utenti che utilizzano più della loro quota del downlink quando è congestionato, perché a differenza di SCTP e TCP, UDP non ha controllo di congestione rendendo molto difficile stabilire le priorità del downlink traffico.

Sia SCTP che TCP hanno il controllo della congestione e giocano bene con QoS, ma SCTP ha l'ulteriore vantaggio rispetto a TCP che è stato progettato per applicazioni di streaming in tempo reale, rendendolo un buon sostituto sia per TCP che per UDP. In effetti, SCTP è il migliore di entrambi i 2 protocolli di trasporto più comuni.

Non può essere una cattiva idea avere un fallback, piuttosto che fare affidamento solo su UDP. Anche se torni a TCP, almeno puoi dire che funziona, forse non in modo ottimale.

— James Haigh
fonte