So now, since I pointed to what I believe is a problem with the synchronous interface in asio (socket dependency upon the demuxer) ...
Exactly - in my own (soon upcoming, hopefully) Asio review I mention that I see the Asio demuxer as a general asynch I/O demuxer (which is also what I understand Chris intends). E.g. the demuxer could be used for file I/O, and in that case there should be interfaces (eventually) to use Boost.Filesystem with the demuxer. Of course the (current) synchronous Filesystem interfaces will not go away. The same could be said for many other (currently synchronous only) libraries. I don't think Sockets should be an exception - i.e. Sockets can only be used with a demuxer, but Filesystem can be used without. We can argue about the most efficient and scalable way to design high-performance network applications, but there will always be use cases for small, simple, synchronous socket libraries. As long as there is well-documented and easy paths to the higher-performance asynchronous interfaces, I see real advantages to layering it this way. This takes nothing away from the high quality of Asio, and I would even be happy with taking Asio as is, with a future path towards the simpler synchronous socket operations. Cliff