[boost] [asio] Library Review

From: Ronald Garcia (garcia_at_[hidden])
Date: 2005-12-25 14:31:22

I have reviewed ASIO by browsing some of the documentation and working
through the tutorial.  What follows are my comments on the library.

Regarding the Tutorial:

Some of the tutorial material seems too low-level with respect to the
facilities available from the C++ Standard Library.  Why the use of
char arrays, strdup, and strlen?  Furthermore,
is strdup a standard C++ function?  I do not think it is standard C.
I would like to see an interface for reading/writing that supports
iterators if that makes sense. It would also be nice to be able to
read from a socket into an std::string.  If that is possible, then it
is not obvious from the tutorial.

Based on the daytime tutorial, I am concerned that not enough
high-level functionality has been added to the library.  The daytime
examples still have the flavor of using unix sockets.  I think that
this low-level functionality is critical to flexibility (and perhaps
performance), but I would like to be able to quickly construct simple
network applications as well.

Just for some perspective, here's a tcp daytime server written in the
TCL scripting language:

-----<snip>-----
#!/bin/sh

# Standard Trick \
     exec tclsh $0 ${1+"$@"}

proc serveMe {handle addr port} {
   puts $handle [clock format [clock seconds]]
   close $handle
}

set sk [socket -server serveMe 13]

vwait forever
-----<snip>-----

and here's a tcp datetime client:

-----<snip>-----
#!/bin/sh

# Standard Trick \
     exec tclsh $0 ${1+"$@"}

if { $argc != 1} {
   puts stderr "client <host>"
   exit 1
}

set sk [socket [lindex $argv 0] 13]

puts -nonewline [read $sk]
-----<snip>-----

I would like to see an interface at this coarse-grain a level of
functionality as well (using the analogous Modern C++ idioms of course).

I did not find the Timer 5 example (Using boost threads) to be very
compelling.  Granted the examples are meant to give a flavor of the
library interface, but it may be more compelling to defer
multi-threading to the daytime server, perhaps forking a new thread on
each connection.  This would probably more closely resemble a real use
of the facility.  I suspect that something more would need to be done
to demonstrate synchronization.

I am also curious if the library could provide synchronous networking
(which asio supports contrary to the library's name) through an
iostreams-like interface as well.

Demuxer:
It appears that any application that uses asio must have one and only
one demuxer object floating around.  If that is the case, then perhaps
it would be wise to model demuxer after std::cout: a global object
that is implicitly constructed and destructed and available to any
translation unit that includes the relevant header.

Demuxer appears to have a more general use than merely
i/o.  In fact it appears that demuxer could be generally applicable to
other asynchronous event handling that might occur in a C++
application (Graphical User Interface come immediately to mind).
Existing libraries for GUI's have their own event loop systems.  Two
issues to consider are:

1) Might future libraries that require asynchrony piggyback off of
    ASIO's demultiplexing facilitites (For example a C++ GUI library,
    etc).

2) How can one interleave asio's demultiplexing facilities with other
    existing event-based libraries.  I'm afraid I have not had time to
    investigate whether and how this can be done in asio currently.
    But some applications will require mixing asio into some other
    master event loop. Something of like demuxer::run_one_event() would
    be a good start.

Documentation:
The reference documentation seems to be quite good.  I do not see
documentation for the default class types (such as demuxer) written
without reference to the underlying policies involved.  It would be
very helpful to basic users of the library to have higher-level
documentation available in addition to the detailed lower-level
documentation.  There appear to be some gaps in the documentation on
first view (No documentation of the Demuxer_Service concept (modeled
by demuxer_service).

Code Comments:

It was necessary for me to make the following changes to the library
in order to prevent warnings and to compile under OS X (Panther/10.3):

OS X 10.3 does not define EV_OOBAND.  To compile the programs, I had
to supply a definition to kqueue_reactor.hpp:

#define EV_OOBAND EV_FLAG1

It is not clear to me that this is the proper fix.

Furthermore, it was necessary for me to supply some casts in
socket_ops.hpp to prevent warnings:

recv_bufs[i].iov_len = static_cast<int>(b[i].size);
recv_bufs[i].iov_base = static_cast<caddr_t>(b[i].data);

...

send_bufs[i].iov_len = static_cast<int>(b[i].size);
send_bufs[i].iov_base = static_cast<caddr_t>(b[i].data);

Cheers,
ron