2011-12-16 3 views
7

Questo è uscita dal mio programmaInvio pacchetti UDP da localhost a localhost e viene eseguito su pacchetti a volte interrotti. Come lo fermo e perché succede?

sending agent update 
Created new player 
Identified 
sending agent update 
Physics: 2 ticks this frame 
time= 200 
time= 300 
***Packet Dropped: 2:10 *** 
***Packet Dropped: 2:11 *** 
***Packet Dropped: 2:12 *** 
***Packet Dropped: 2:13 *** 
***Packet Dropped: 2:14 *** 
***Packet Dropped: 2:15 *** 
***Packet Dropped: 2:16 *** 
***Packet Dropped: 2:17 *** 
***Packet Dropped: 2:18 *** 
***Packet Dropped: 2:19 *** 
***Packet Dropped: 2:20 *** 
***Packet Dropped: 2:21 *** 
time= 400 
Physics: 2 ticks this frame 
time= 500 
Physics: 2 ticks this frame 

invio di pacchetti da host locale a host locale, i pacchetti sono in calo. Questo succede solo all'inizio. I primi 10 pacchetti passano, quindi i pacchetti dopo quella caduta. Da 5 a 40 pacchetti in fila. Quindi i pacchetti smettono di cadere.

C'è qualche ragione per cui questo dovrebbe accadere?

Aggiornamento:

Il seguente codice risolto il problema.

int buffsize = 65536; // 65536 
setsockopt(socket, SOL_SOCKET, SO_RCVBUF, (void*)&buffsize, sizeof(buffsize)); 

Stavo inviando pacchetti troppo veloci e ho superato il buffer di ricezione predefinito di Windows, che è solo 8 KB. L'aumento della dimensione del buffer ha risolto il problema.

+0

Difficile dire senza vedere il codice. Troppe incognite. –

risposta

8

Controllare la dimensione del buffer UDP configurato di default nel sistema operativo.

Se lo si trova di meno, è possibile fornire in modo esplicito un valore maggiore durante la creazione di un socket UDP.

 
int buffer_size = 4 * 1024 * 1024 ; 
setsockopt(socket, SOL_SOCKET, SO_RCVBUF, &buffer_size, sizeof(buffer_size)); 

Si possono trovare THIS collegamento molto utile.

+0

Ho trovato questa soluzione prima di leggere la risposta, ma tu hai assolutamente ragione. Questo ha risolto il mio problema. – HaltingState

+0

Recentemente ho avuto un problema simile e mi sono imbattuto in un limite rigido per le dimensioni massime del buffer di ricezione/invio. Aumentando quelli ad alto valore risolto il problema: 'sysctl -w net.core.rmem_max = $ [2 * 1024 * 1024]' e 'sysctl -w net.core.wmem_max = $ [2 * 1024 * 1024]'. È stato abbastanza divertente 'setsockopt' * non * restituire un errore e sembra ignorare solo valori superiori a questo massimo. – hochl

+0

@hochl Sono d'accordo, può essere un po 'frustrante (avendo affrontato me stesso una volta :)) – Arunmu

1

Come un'ipotesi molto veloce - in passato ho visto questo perché le finestre di ricezione sono piene. Fondamentalmente la tua applicazione non consuma abbastanza velocemente i pacchetti e il kernel ha solo tanto spazio riservato: devi aumentare il parametro rwin. O dall'altra parte li sta inviando troppo veloce - i params su una macchina Linux sta

net.ipv4.udp_rmem_min = 4096 
net.ipv4.udp_wmem_min = 4096 
4

Probabilmente stai inviando pacchetti troppo velocemente e quindi sovraccarichi i buffer. È necessario implementare la stimolazione di trasmissione per assicurarsi che il trasmettitore non sommerga il ricevitore. Non lo eviterai mai al 100%: è la natura di UDP che non fornisce una garanzia di consegna.