Come eseguire il debug della perdita di pacchetti?

Question

Ho scritto un'applicazione C++ (in esecuzione su Linux) che serve un flusso RTP di circa 400 kbps. Per la maggior parte delle destinazioni questo funziona bene, ma alcune destinazioni perdono la perdita di pacchetti. Le destinazioni problematiche sembrano avere una connessione più lenta in comune, ma dovrebbero essere abbastanza veloci per lo stream che sto inviando.

Poiché queste destinazioni sono in grado di ricevere flussi RTP simili per altre applicazioni senza perdita di pacchetti, la mia applicazione potrebbe essere in errore.

ho già verificato alcune cose: - in un tcpdump, vedo tutti i pacchetti RTP in corso sulla macchina di invio - c'è un UDP inviare buffer in posto (ho provato dimensioni comprese tra 64KB e 300KB) - il I pacchetti RTP rimangono perlopiù sotto i 1400 byte per evitare la frammentazione

Cosa può fare un'applicazione di invio per ridurre al minimo la possibilità di perdita di pacchetti e quale sarebbe il modo migliore per eseguire il debug di tale situazione?

Answer 1

Non inviare pacchetti in grandi blocchi di tipo bursty.

La perdita di pacchetti è in genere causata da router lenti con dimensioni del buffer di pacchetti limitate. Il router lento potrebbe essere in grado di gestire 1 Mbps bene se ha il tempo di inviare, diciamo, 10 pacchetti prima di riceverne altri 10, ma se il lato del mittente da 100 Mbps lo invia una grossa porzione di 50 pacchetti non ha altra scelta che lasciare 40 di loro.

Provare a distribuire l'invio in modo da scrivere solo ciò che è necessario scrivere in ciascun periodo di tempo. Se devi scrivere un pacchetto ogni quinto di secondo, fallo in quel modo invece di scrivere 5 pacchetti al secondo.

Answer 2

Questa potrebbe non essere la risposta che si desidera, ma se avessi problemi di perdita di pacchetti, proverei a cambiare la mia applicazione per usare TCP, e mi sono tolta la maggior parte delle preoccupazioni relative alla perdita di pacchetti.

Answer 3

Si dovrebbe provare a ridurre la velocità di invio dei pacchetti. Una connessione lenta può significare tutti i tipi di cose e provare a inviarli pacchetti (piccoli o grandi) ad alta velocità non aiuterà.

Answer 4

netstat ha diverse opzioni utili per eseguire il debug della situazione.

primo è -su netstat (il dump statistiche UDP):

dima@linux-z8mw:/media> netstat -su              
IcmpMsg:                     
    InType3: 679 
    InType4: 20 
    InType11: 548 
    OutType3: 100 
Udp: 
    12945 packets received 
    88 packets to unknown port received. 
    0 packet receive errors 
    13139 packets sent 
    RcvbufErrors: 0 
    SndbufErrors: 0 
UdpLite: 
    InDatagrams: 0 
    NoPorts: 0 
    InErrors: 0 
    OutDatagrams: 0 
    RcvbufErrors: 0 
    SndbufErrors: 0 
IpExt: 
    InNoRoutes: 0 
    InTruncatedPkts: 0 
    InMcastPkts: 3877 
    OutMcastPkts: 3881 
    InBcastPkts: 0 
    OutBcastPkts: 0 
    InOctets: 7172779304 
    OutOctets: 785498393 
    InMcastOctets: 525749 
    OutMcastOctets: 525909 
    InBcastOctets: 0 
    OutBcastOctets: 0 

avviso "RcvbufErrors" e "SndbufErrors"

Opzione aggiuntiva è quello di monitorare ricevere e inviare i buffer UDP del processo:

dima@linux-z8mw:/media> netstat -ua 
Active Internet connections (servers and established) 
Proto Recv-Q Send-Q Local Address   Foreign Address   State 
udp  0  0 *:bootpc    *:* 
udp  0  0 *:40134     *:* 
udp  0  0 *:737     *:* 
udp  0  0 *:mdns     *:* 

Qui è necessario esaminare la colonna Recv-Q e Send-Q della connessione che ti interessa. Se i valori sono alti e non scendono a zero, il processo non può gestire il carico.

È possibile utilizzare questi comandi sull'invio e sulla macchina ricevente.

Inoltre è possibile utilizzare mtr, che unisce traceroute e ping - fa un rumore metallico ogni hop nel percorso. Questo potrebbe rilevare un hop lento nel percorso. Eseguilo su altre macchine per verificare la connettività con la seconda.

Answer 5

RTP utilizza in genere UDP, che è intrinsecamente perdita. I pacchetti potrebbero essere persi ovunque tra mittente e destinatario, quindi il debug locale non ti mostrerà nulla di utile.

cose ovvie da fare:

• una: ridurre il tasso di dati globale
• B: Ridurre la velocità dei dati 'di punta', di l'invio di piccoli pacchetti più spesso piuttosto che uno pezzo enorme ogni pochi secondi. cioè, RIDUCE il tuo UDP invia il buffer - forse anche solo a 1400 byte.
• c: vedere se è possibile passare a una variante TCP di RTP.

Se tutto il resto fallisce, WireShark è tuo amico. Ti darà una vera immagine di quanti dati - e quando viene inviata dalla tua app.