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
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?
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
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk