[boost] [review] Asio formal review.

From: Rene Rivera (grafik.list_at_[hidden])
Date: 2005-12-20 02:02:09

I vote to *not* accept Asio as a Boost library. This is based on some 
specific deficiencies in design/implementation and documentation. Hence 
if those are remedied I would be willing to change my vote.

What is your evaluation of the design?

Fair -- The overall separation of responsibilities is good and provides 
for considerable reuse. And possibly independent use of many of the 
facilities. Unfortunately many of the interactions and dependencies 
between the parts are not clear. In many situation I had to resort to 
reading through the implementation to figure out the various 
connections. Even though I can see how I would use the library in some 
tasks there are others I just don't see how something could be implement 
in an efficient manner. (More below on my specific use case)

What is your evaluation of the implementation?

Good -- For the given design the implementation is clear and easy to 
follow. But because of some particular design choice(s) there are some 
serious performance deficiencies which I would think prevent its use in 
the one area where the library was ostensibly design to be used, high 
performance servers.

What is your evaluation of the documentation?

Insufficient -- Even though I'm a proponent of Dox style automated 
documentation in this case the Dox reference documentation is 
insufficient in describing how the various operations work. The 
supporting design, tutorials, and examples I don't feel provide 
sufficient background to understand how the pieces connect and react 
with each other. Specifically the example code should at minimum explain 
why calls are done. In summary, either the reference docs need to 
improve significantly, or the non-reference docs need to take up the slack.

What is your evaluation of the potential usefulness of the library?

Good -- Even with my concerns about efficiency I can see the use in the 
wider connection based client/server domain where response efficiency is 
a minor concern.

Did you try to use the library?

No.

How much effort did you put into your evaluation? A glance? A quick 
reading? In-depth study?

In-depth -- I read a good portion of the documentation, and various 
parts of the implementation with a particular use case in mind.

Are you knowledgeable about the problem domain?

Yes. I have done some form of networking programming for the past 10 
years. In the form of HTTP handlers, Game multiplayer games, and most 
recently client/server version control system.

Now some details about my use case and my performance concern...

I am looking at Asio to provide the socket handling for one of my 
current projects, the version control system. I'm in the middle of 
rewriting the networking aspect of it from the classic thread per client 
model to an async endpoints and routers star to star virtual LAN 
topology with a custom reliable message protocol based on UDP.

This means that since I'm writing my own router I need the best 
performance I can get. But to give some minimal concrete numbers... 
Given a single gigabit line, a minimal example as a server is likely 
going to have multiple lines, and the most favorable situation of 
handling full 64K UDP packets one would need to handle about 1500 
messages a second (or 2/3 of a millisecond per message). But in practice 
it would have to be faster than that. This means minimizing the most 
expensive steps, i.e. memory allocations.

Currently AFAICT in order to use the async operations asio requires a 
model which allocates a new handler for each message received. This 
might be fine for many situations where those handlers will change from 
message to message. But for my use case I have only one handler that 
needs to get called for *any* message that comes in. In the asio case it 
means that for each message I received it would: remove the handler from 
the demuxer map, call the handler, which would do my custom parsing and 
routing, and push a new async_receive of myself (which creates a new 
handler object and inserts it again into the demux map). This is clearly 
suboptimal, and will result in considerable performance degradation. To 
refer to some concrete code, one can look at the Daytime.6 tutorial 
which does basically that procedure.

Of course it would be awesome if Christopher would come out and tell me 
I'm stoned and point out how to achieve the optimum I need. Barring that 
for me to use Asio for my project I would end up creating patched 
versions of epoll_reactor, kqueue_reactor, reactor_op_queue, 
reactive_sokect_service, and win_iocp_socket_service (maybe more). Such 
hacking of implementation classes to me means a serious design failure.

Here's to hoping I'm wrong ;-)

-- 
-- Grafik - Don't Assume Anything
-- Redshift Software, Inc. - http://redshift-software.com
-- rrivera/acm.org - grafik/redshift-software.com
-- 102708583/icq - grafikrobot/aim - Grafik/jabber.org