[boost] [asio] my review

From: Cory Nelson (phrosty_at_[hidden])
Date: 2005-12-12 06:14:17

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