I have a standard implementation for receiving UDP packets asynchronously using SocketAsyncEventArgs. What I do not understand from docs and some googling is if I should do the real work of processing messages inside the callback itself, like this comment indicates in the complete implementation I am referring to, or I should offload processing to other threads e.g. via ConcurrentQueue or BlockingCollection.
My concerns are the following:
- If processing directly in the callback, could it decrease receiving performance or introduce random delays due to temporary thread pool starvation or some other implementation detail?
- Due to slight delays in processing (vs. just offloading to a collection) could more packages be dropped due to a full buffer?
- Could more packages be reordered in the sense that the callback is called in different order than packages are actually arriving from a network.
So what is the best practice or intended way of processing messages using SocketAsyncEventArgs to ensure minimum missed datagrams, no additional reordering of callback calls and no additional delays?
And a related question - does ReceiveAsync guarantees any order at all or at least tries to call the callback in the same order that packages are received from a network, or I should use blocking receives for that? The target use case is to subscribe to 6-8 UDP channels, within each of them the order is highly important. Running a number of blocking threads looks more complex than just handling callbacks, but not that hard if only such solution guarantees message order.