ricezione di dimensioni variabili di dati tramite socket TCP

Question

Ho riscontrato un piccolo problema con il trasferimento di dati su socket (TCP). Piccolo background su quello che sto facendo:

Sto inviando dati dal lato A al B. I dati inviati possono essere di lunghezza variabile, assumendo dimensioni massime di 1096 byte.

A) send(clientFd, buffer, size, NULL) 

su B, dal momento che non so cosa dimensioni aspettarsi, cerco sempre di ricevere 1096 byte:

B) int receivedBytes = receive(fd, msgBuff, 1096, NULL) 

Tuttavia, quando ho fatto questo: ho realizzato un stava mandando piccole porzioni di dati ..sono circa 80-90 byte. Dopo alcuni scoppi di invio, B li ha radunati per aver ricevuto un totale di 1096 byte. Questo ovviamente ha danneggiato i dati e l'inferno si è scatenato.

Per risolvere il problema, ho rotto i miei dati in due parti: intestazione e dati.

struct IpcMsg 
{ 
    long msgType; 
    int devId; 
    uint32_t senderId; 
    uint16_t size; 
    uint8_t value[IPC_VALUES_SIZE]; 
}; 

Su un lato:

A) send(clientFd, buffer, size, NULL) 

su B, ho ricevuto l'intestazione e determinare la dimensione di payload per ricevere: e quindi ricevere il resto del payload.

B) int receivedBytes = receive(fd, msgBuff, sizeof(IpcMsg) - sizeof(((IpcMsg*)0)->value), 0); 
int sizeToPoll = ((IpcMsg*)buffer)->size; 
printf("Size to poll: %d\n", sizeToPoll); 

if (sizeToPoll != 0) 
{ 
     bytesRead = recv(clientFd, buffer + receivedBytes, sizeToPoll, 0); 
} 

Quindi, per ogni invio, che ha un carico utile, finisco per chiamare riceve due volte. Questo ha funzionato per me, ma mi chiedevo se c'è un modo migliore per farlo?

Answer 1

Sei sulla buona linea con l'idea di inviare un'intestazione che contiene informazioni di base sui seguenti dati, seguiti dai dati stessi. Tuttavia, questo non sempre funziona:

int receivedBytes = receive(fd, msgBuff, sizeof(IpcMsg) - sizeof(((IpcMsg*)0)->value), 0); 
int sizeToPoll = ((IpcMsg*)buffer)->size; 

La ragione è che il protocollo TCP è libero di frammentare e inviare l'intestazione nel maggior numero di pezzi come essa ritiene opportuno sulla base di una propria valutazione delle condizioni di rete sottostanti applicate a ciò che è chiamata strategia di controllo della congestione. Su una LAN avrai praticamente sempre la tua intestazione in un unico pacchetto, ma provalo in tutto il mondo attraverso Internet e potresti ottenere un numero molto più piccolo di byte alla volta.

La risposta è quella di non chiamare TCP 'receive' (solitamente recv) direttamente ma di estrarlo in una piccola funzione di utilità che prende la dimensione che si deve realmente ricevere e un buffer in cui inserirla. Entra in un ciclo che riceve e accoda i pacchetti finché tutti i dati non sono arrivati ​​o si verifica un errore.

Se è necessario andare in modalità asincrona e servire più client contemporaneamente, si applica lo stesso principio ma è necessario indagare sulla chiamata "select" che consente di ricevere una notifica quando i dati arrivano.

Answer 2

TCP/IP è un'interfaccia "raw" per l'invio di dati. Garantisce che, se i byte vengono inviati, che sono tutti lì e nel giusto ordine, ma non fornisce alcuna garanzia sul chunking e non sa nulla dei dati che stai inviando.

Pertanto, se l'invio di un "pacchetto" su TCP/IP che deve essere elaborato come tale, è necessario conoscere quando si dispone di un pacchetto completo da una delle seguenti tecniche:

• pacchetti di dimensioni fisse .Nel tuo caso 1096 byte
• Prima invia/ricevi una "intestazione" nota che ti dirà la dimensione del pacchetto inviato.
• Utilizzare un tipo di simbolo "fine del pacchetto".

In uno dei primi due, si conosce il numero di byte che si prevede di ricevere, quindi è necessario bufferizzare tutto ciò che si riceve fino a quando non si ha il messaggio completo, quindi elaborarlo.

Se si riceve più di quanto previsto, cioè si riversa nel pacchetto successivo, lo si divide, si elabora il pacchetto completato e si lascia il resto bufferizzato per l'elaborazione successivamente.

In quest'ultimo caso in cui è presente un simbolo di fine pacchetto, che potrebbe trovarsi in qualsiasi punto del messaggio, quindi qualsiasi cosa lo segua, si memorizza il buffer per il pacchetto successivo.