Currently AFAICT in order to use the async operations asio requires a model which allocates a new handler for each message received. This might be fine for many situations where those handlers will change from message to message. But for my use case I have only one handler that needs to get called for *any* message that comes in. In the asio case it means that for each message I received it would: remove the handler from the demuxer map, call the handler, which would do my custom parsing and routing, and push a new async_receive of myself (which creates a new handler object and inserts it again into the demux map). This is clearly suboptimal, and will result in considerable performance degradation. To refer to some concrete code, one can look at the Daytime.6 tutorial which does basically that procedure.
In practice, I tried out asio on Windows using the iocp implementation with the "same handler every time" pattern of usage, and was quite happy with CPU utilization on a 100 Mbit/s peak multicast stream (1000 -> 1500 bytes/message). I expect that there may be some gains to be had, especially in the epoll/kqueue based reactor implementations to allowing a user to "preregister" a handler. Maybe there could be overloads of the asynch operations that accept a pre-bound handler? However, as I'm sure you know, there will always be some "Per I/O operation" structures involved like the buffer, etc. It's pretty common on IOCP servers to post several asynch reads on the same socket, to avoid queueing and extra copying. Regards, Dave