2012-07-20 19 views
5

Ho reso il mio server UDP e client con boost :: asio socket udp. Tutto sembrava a posto prima di iniziare a inviare più datagrammi. Arrivano correttamente da client a server. Ma, sono uniti nel mio buffer in un unico messaggio.Come dividere ricevuto con boost asio udp socket datagrammi uniti

Io uso

udp::socket::async_receive con std::array<char, 1 <<18> tampone

per fare richiesta asincrona. E ricevere dati tramite callback

void on_receive(const error_code& code, size_t bytes_transferred)

Se invio dei dati troppo spesso (ogni 10 millisecondi) che ricevo diversi datagrammi contemporaneamente nel mio buffer con richiamata sopra. La domanda è: come separare separato da? Nota: i datagrammi UDP hanno lunghezza variabile . Non voglio usare l'intestazione aggiuntiva con le dimensioni, perché renderà il mio codice inutile per i datagrammi di terze parti.

+0

Potresti mostrare il tuo codice? –

+0

Utilizzare una funzione di callback fornita dall'utente nel messaggio 'on_receive', che elabora tutti i messaggi inclusi nel singolo pacchetto ricevuto. – Chad

+0

Certo, potrebbe essere trovato qui: [udp2tcp_tunnel] (https://github.com/valery-l/udp2tcp_tunnel). È in corso - ancora un piccolo server ping-pong (che invia via TCP dal client, ricevendo lo stesso messaggio di test dal server di UDP). Mi sembra di aver trovato il problema. Se invio vari buffer in ** sequenza buffer ** da 'basic_datagram_socket :: async_send_to (buffer_sequence, handler)', arriverà come ** un ** datagramma (non ** un ** datagramma per ** ogni buffer * *). –

risposta

0

Credo che questa sia una limitazione nel modo in cui boost :: asio gestisce i flussi di dati senza stato. Ho notato esattamente lo stesso comportamento quando uso boost :: asio per un'interfaccia seriale. Quando stavo inviando pacchetti con intervalli relativamente grandi tra loro, stavo ricevendo ciascuno in un callback separato. A mano a mano che le dimensioni del pacchetto aumentavano e il divario tra i pacchetti diminuiva, raggiungeva uno stadio in cui eseguiva il callback solo quando il buffer era pieno, non dopo aver ricevuto un singolo pacchetto.

Se si conosce esattamente la dimensione dei datagrammi previsti, la soluzione per limitare la dimensione del buffer di input è perfettamente ragionevole, poiché si conosce a priori esattamente la dimensione del buffer.

Se la tua congestione deriva dal trasferimento di più tipi di pacchetti diversi, quindi non puoi pre-allocare il buffer di dimensioni corrette, potresti potenzialmente creare diversi socket su porte diverse per ogni tipo di transazione. È un po 'più "hacky", ma data la natura praticamente illimitata della disponibilità di porte effimere, a patto che non si utilizzino 20.000 tipi di pacchetti diversi che probabilmente ti aiuteranno altrettanto bene.