Let me start off by saying I'm primarily a Windows developer, and don't have any experience with the high perf apis available on *nix. So many of my issues may be related to that. I have extensively used I/O Completion Ports in C/C++ and have used the async methods in .NET. I have also used ASIO on and off for the last few months. My immediate thoughts on asio. Generally it provides a very good interface for scalable i/o. But I think there is some room for improvement, both in API and implementation. I would *not* recommend asio for inclusion in boost until at least the IPv6 issue is taken care of. For the API, one thing that struck me is the almost C-style error handling. I believe the .NET way is better. It provides a point that the developer must call to get the result of the operation, and that the sockets can throw any exceptions that would normally be thrown in sync operations. ie, void MyHandler(IAsyncResult res) { int len; try { len=sock.EndRecv(res); } } I was disappointed to not see IPv6 there. Yes, it hasn't reached critical mass yet, but it is coming fast and should be mandatory for any socket libraries. With Windows Vista having a dual stack I believe IPv6 is something everyone should be preparing for. This is the only showstopper for me. I don't want to see a ton of IPv4-centric applications made as they can be a pain to make version agnostic. Talking about IPv6, I would love to see some utility functions for resolving+opening+connecting via host/port and host/service in a single operation. This would encourage a future-proof coding style and is something almost all client applications would use. I dislike how it forces manual thread management - I would be much happier if the demuxer held threads internally. Because threading is important to get maximum performance and scalability on many platforms, the user is now forced to handle pooling if he wants that. On Windows 2000+ it is common to use the built-in thread pool which will increase/decrease the amount of threads being used to get maximum cpu usage with IO Completion Ports. Which brings me to the next thing: the timers should be using the lightweight timer queues which come with win2k. These timer queues also have the advantage of using the built-in thread pool. Async connecting does not use ConnectEx on platforms which support it. This isn't such a big issue, but it's still a disappointment. ASIO lacks one important feature, async disconnects. I don't have experience in *nix, but in Windows creating sockets is expensive and a high perf app can get a significant benefit by recycling them. A minor issue, but I'm not liking the names of the _some methods. It would be better to just document the fact that it might not read/write everything you give it instead of forcing it down the user's throat every time they want to use it. As for documentation, it is fair. It is a bit loopy at times because of the basic_* templates. I don't expect normal usage will care very much about implementation, so perhaps these can be seperated from the main documentation. I see no problems beyond that. -- Cory Nelson http://www.int64.org