Winsock pacchetti UDP essere abbandonato?

Abbiamo una comunicazione client/server, un sistema di UDP di installazione di windows. Il problema è che quando la velocità cresce, i pacchetti sono sempre caduto. Abbiamo il sospetto che questo è a causa della UDP buffer di ricezione, che è continuamente in fase di interrogazione causando il buffer di blocco ed eliminazione di ogni pacchetto in arrivo. È possibile che la lettura di questo buffer, può causare i pacchetti in arrivo per essere eliminato? Se è così, quali sono le opzioni per correggere questo? Il sistema è scritto in C. per Favore fatemi sapere se questo è troppo vago e posso provare a fornire ulteriori informazioni. Grazie!

  • È la natura stessa dell’UDP per eliminare i pacchetti sotto pressione. Se si desidera una consegna affidabile, utilizzare il protocollo TCP.
  • Infatti, l’UDP è consentito eliminare, riordinare, e duplicare i pacchetti in qualsiasi punto nel tempo; c’è una “garanzia” è che non vengono danneggiati i pacchetti, ma in realtà vedrete che anche il checksum IP è piuttosto debole).
  • Notato la stessa cosa. Il mio server linux trasmette così veloce che il povero windows casella non può tenere il passo… eppure la macchina windows non è lento allenatore!!! Ho intenzione di provare ad aumentare il buffer
  • vedi anche stackoverflow.com/questions/7968566/…
InformationsquelleAutor | 2009-10-02



6 Replies
  1. 12

    Predefinito presa la dimensione del buffer in Windows sockets è 8k, o 8192 byte. Utilizzare il setsockopt funzione di Windows per aumentare la dimensione del buffer (fare riferimento al SO_RCVBUF opzione).

    Ma al di là che, aumentando la dimensione del buffer di ricezione sarà solo ritardare il tempo fino a quando i pacchetti di farlo cadere di nuovo se non la lettura di pacchetti abbastanza veloce.

    In genere, si desidera che due thread per questo tipo di situazione.

    Il primo thread che esiste solamente per un servizio di presa. In altre parole, il thread unico scopo è quello di leggere un pacchetto da presa, aggiungere un qualche tipo di correttamente sincronizzato struttura dati condivisa, segnale che un pacchetto è stato ricevuto, e quindi leggere il prossimo pacchetto.

    Il secondo thread esiste per elaborare i pacchetti ricevuti. Si siede inattivo fino a quando il primo thread segnali di un pacchetto è stato ricevuto. Poi tira il pacchetto correttamente sincronizzato struttura dati condivisa e processi. Si attende quindi di essere segnalato di nuovo.

    Come un test, prova a corto circuito l’intero trattamento dei vostri pacchetti e scrivere un messaggio per la console (o un file) ogni volta che un pacchetto è stato ricevuto. Se è possibile fare questo senza cadere i pacchetti, quindi rompere il vostro funzionalità in un “ricevere” filo e un “trattamento” filo sarà di aiuto.

  2. 5

    Sì, lo stack è consentito eliminare i pacchetti, in silenzio, anche quando le sue buffer di troppo pieno. Questo fa parte della natura dell’UDP, uno dei bit di affidabilità rinunciare quando si passa da TCP. È possibile reinventare TCP — mal — aggiungendo logica di tentativi, i pacchetti ACK, e quali, oppure si può passare a qualcosa di in-tra SCTP.

    Ci sono modi per aumentare lo stack dimensione del buffer, ma che è in gran parte manca il punto. Se non si riesce a leggere abbastanza veloce per tenere il buffer di spazio disponibile già, rendendo il buffer più grande è solo andando a mettere fuori il tempo necessario per l’esecuzione di spazio di buffer. La soluzione corretta è quella di rendere più grande il buffer interno del proprio codice, e spostare i dati dallo stack del buffer nel tuo programma il buffer di ASAP, dove si può aspettare di essere trattati per arbitrariamente i tempi lunghi.

  3. 3

    È possibile che la lettura di questo buffer, può causare i pacchetti in arrivo per essere eliminato?

    Possono essere eliminati i pacchetti se arrivano più velocemente di quanto la loro lettura.

    Se è così, quali sono le opzioni per risolvere questo problema?

    Una possibilità è quella di modificare il protocollo di rete: l’utilizzo di TCP, o implementare un qualche riconoscimento + il flusso di controllo’ utilizzo di UDP.

    Altrimenti ti serve per vedere perchè tu non sei di lettura veloce/abbastanza spesso.

    Se la CPU è al 100% utilitized allora avete bisogno di fare meno lavoro per pacchetto o avere una CPU più veloce (o utilizzare il multithreading e la Cpu se non hai già).

    Se la CPU non è al 100%, quindi forse quello che succede è:

    • Leggere un pacchetto
    • Si fa un certo lavoro, che prende x msec in tempo reale, alcune delle quali è trascorso bloccato su alcuni altri I/O (in modo che la CPU non è occupato, ma non attualmente in uso per leggere un altro pacchetto)
    • Durante quelle x msec, un’inondazione di pacchetti in arrivo e alcune sono caduto

    Una cura per questo ci sarebbe da cambiare la filettatura.

    Un’altra possibilità è di fare diverse simultanea lettura dal socket (ciascuno dei vostri legge fornisce un buffer in cui un pacchetto UDP può essere ricevuto).

    Un’altra possibilità è vedere se c’è un (O/S-specifico) opzione di configurazione per aumentare il numero e la ricezione di pacchetti UDP che lo stack di rete è disposti a buffer fino a quando si tenta di leggere.

  4. 3

    Primo passo, aumentare il ricevitore dimensione del buffer, Windows praticamente concede a tutti di dimensioni ragionevoli richieste.

    Se questo non aiuta, il consumare il codice sembra abbastanza lento aree. Vorrei utilizzare il threading, ad esempio, con pthreads e di utilizzare un producer-consumer motivo per mettere in arrivo datagramma in una coda su un altro thread e quindi consumare, così da ricevere chiamate non blocco e il buffer non viene eseguito pieno

    3 ° passo, modificare il livello di applicazione del protocollo, per consentire batch pacchetti e batch pacchetti al mittente per ridurre l’intestazione UDP overhead dall’invio di un sacco di pacchetti di piccole dimensioni.

    4 ° passo controllare le vostre apparecchiature di rete, switch, etc. può dare output dettagliato le loro statistiche di traffico, buffer overflow, etc. – se quello è il problema di ottenere più velocemente gli interruttori o, eventualmente, di cambiare le difettoso

    … cordiali saluti, sto usando UDP multicast traffico sul nostro backend continuo con avg. ~30Mbit/sec con picchi di un 70Mbit/s e il mio tasso di caduta è nudo nil

  5. 0

    Non sono sicuro di questo, ma su windows, non è possibile sondaggio presa e causare un pacchetto di cadere. Windows raccoglie i pacchetti separatamente da polling e non dovrebbe causare cadute.

    sto supponendo che il vostro uso di select() per eseguire il polling del socket ? Per quanto ne so , non può causare una caduta.

    • hmm..grazie per la risposta, credo che abbiamo bisogno di ulteriori ricerche la causa di questo quindi
  6. 0

    I pacchetti possono essere persi a causa di un aumento correlato il traffico di rete in qualsiasi punto lungo il percorso, o full buffer di ricezione. Per ridurre questo rischio, si potrebbe aumentare la dimensione del buffer di ricezione in Winsock.

    Essenzialmente, l’UDP è un protocollo inaffidabile nel senso che il pacchetto di consegna non è garantita e nessun errore viene restituito al mittente la mancata consegna. Se siete preoccupati per la perdita di pacchetti, sarebbe meglio implementare il riconoscimento pacchetti nel tuo protocollo di comunicazione, o a porta a una più affidabile protocollo TCP. Non ci sono davvero altre veramente affidabili modi per prevenire la perdita di pacchetti UDP.

Lascia un commento