Elaborazione di pacchetti nel ciclo asincrono o no?

Question

In C #, quando si ricevono dati di rete con i metodi BeginReceive / EndReceive, c'è qualche motivo per cui non si dovrebbero elaborare i pacchetti non appena li si riceve? Alcuni compiti possono essere decentemente intensivi per la CPU. Lo chiedo perché ho visto alcune implementazioni che spingono i pacchetti in una coda di elaborazione e poi li gestiscono lì. A me questo sembra ridondante perché, per quanto ne so, i metodi asincroni anche operano su un pool di thread.

Answer 1

Come sottolinea Mitch, devi essere in grado di ricevere abbastanza pacchetti per avere un messaggio / frame completo. Ma non c'è motivo per cui non dovresti iniziare a elaborare immediatamente quel frame ed emettere un altro BeginReceive. In effetti, se ritieni che l'elaborazione possa richiedere del tempo, è meglio consegnarla al pool di thread di lavoro anziché bloccare un thread dal pool di I / O (che è il punto in cui verrà attivato il callback).

Inoltre, a meno che non ti aspetti un basso numero di connessioni, generare un thread per gestire ciascuna connessione non è un approccio molto scalabile, sebbene abbia il vantaggio di una certa semplicità.

Di recente ho scritto un articolo sul pipelining dell'elaborazione dei dati da un socket di rete, che puoi trovare qui .

Answer 2

In genere, è necessario ricevere pacchetti "sufficienti" per avere un elemento di dati "processabile".

IMO, è meglio avere un thread il cui lavoro sta ricevendo dati e un altro per elaborarlo effettivamente.