[boost] asio review

From: Scott Harris (harris_s_at_[hidden])
Date: 2005-12-30 17:45:23

Chris,

Sorry for the late response.   A delivery and the flu got in the way.

---  evaluation of the design ---
The design documentation is well written.
How should a boost user deal with porting synchronous I/O code between
platforms?  Should asio be expanded or will a separate library mix
well with asio?  This has already received a lot of attention.

---  evaluation of the implementation ---
Looks good.  I did not make a thorough investigation.

---  evaluation of the documentation ---
= tutorial =
The tutorial was a good introduction to the library.
= examples =
It is not straightforward how the Service example eventually calls the
log method.
Maybe an explanation of this would help the reader bring it all
together in their mind.

= references =
The "Size_IO_Control_Command concept" needs a better description.

There are other concepts that have nondescriptive descriptions:
IPv4_Address_Socket_Option, Integer_Socket_Option,
Boolean_Socket_Option, ...

For example, is the user of asio supposed to just know the
requirements of the "Stream concept." or should some of the
requirements that define the stream concept be stated in its
description?  Or is the list of types and member functions the
requirements of the concept?

I do not like to be picking on the documentation like this because it
is very well written.  I think that the design and tutorial are great
at introducing a user to the library.  I just think that a few
sentences of description (requirements) of a concept will help the
reader understand each concept more quickly.

---  evaluation of the potential usefulness of the library ---

I think that Boost needs a library that addresses the goals stated in
asio’s rationale.  The lack of synchronous I/O support makes the
library less useful than it might be.

--- Did you try to use the library?  ---
answer: no

--- How much effort did you put into your evaluation?
Answer: I read all of the documentation.

--- Are you knowledgeable about the problem domain?
Answer: I have about 10 years of active use of C++ using TCP and UDP
on multiple platforms (including Linux, Solaris and Windows).  Most of
it has been using ACE and its Reactor but I have also implemented
using the Proactor (asynch I/O).

--- Do you think the library should be accepted as a Boost library?
I think that asio should be expanded to support a synchronous/reactive
I/O as well as its current asynchronous support.  If the intent is to
do so then I believe the library should be accepted.

Since performance is often a consideration in networking code, I do
not think that synchronous support should be built on top of
asynchronous capabilities.  My experience with asynchronous I/O vs
synchronous I/O  (ACE_Proactor vs ACE_Reactor on Windows 2000 across 8
machines on a gigabit network in an application of 1000+ simulation
objects) was that I needed to have > 200 pending I/Os for the Proactor
to out perform the Reactor.  This implies that the problem space must
include large number of non-dependent asynchronous reads and writes
for asynchronous I/O to outperform a reactive approach.  My experience
is that most applications do not have that many parallel I/O
operations.

Regards,
  Scott