|
Boost : |
From: Dick Bridges (dbridges_at_[hidden])
Date: 2005-12-30 20:26:26
I vote to accept asio into boost.
<design>
I'm very impressed by the design philosophy. This is the only
network library I've encountered that let me implement
application-level framing (RTP development) *and* simple TCP-based
message-passing within the same framework using the same API.
I think the threading model chosen will scale very well to the new
generation of multiple-CPU architectures that are beginning to
appear on, for example, the (Intel) desktop *and* in the "ARM-rest". ;)
<aside>
Although I can understand some of the objections to requiring explicit
assignment of the demuxer for "synchronous" applications, the meaning
of "synchronous" seems [to me] to become a little vague in the presence
of multiple CPUs each providing multiple execution units. I hope we
don't
loose the existing ability to allocate 'blocked' and non-blocking
threads
among demuxers to minimize thread synchronization operations.
</aside>
demuxer -> io_service[S] seems to be a beneficial change. No
preference on singular vs. plural.
</design>
<implementation>
I did not spend a great deal of time evaluating the implementation
except to verify that it seemed to implement the design. Based
on my reading of the other reviews, the details are best left to
those much more familiar with c++ than I.
One argument in favor of the implementation might be made on the
basis of the number of changes that were made during the review
itself. The initial implementation had to have been pretty well
thought out to be able to make that many changes "on the fly".
</implementation>
<documentation>
The documentation is adequate. (I am not a fan of Doxygen.) The
tutorials provide a nice exposition of the basic concepts and,
along with a few short "trips" into the reference documents, allowed
me to easily replace an existing networking library with asio (and
simplify the code in the process).
I would like to see "handwritten" reference documentation. I have
no evidence but I believe it tends to be clearer and more complete
than comments from the code - even when written by the same person.
</documentation>
<potential_usefulness>
Extremely useful for IP networks and other asynchronous block devices.
(IMHO questions regarding *how* iostream-like support could be supported
should be proceeded by justifying *why* iostream-like support should be
supported.)
Suggestion1: a little syntactic sugar that provides the ability to
reset() an un-expired deadline_timer "atomically" without going through
the cancel()/expires_from_now() sequence.
Suggestion2: SCTP support? It's about to appear in both Windows
and Linux and VoIP and/or streaming multimedia will probably
make it fairly important in the next couple of years.
</potential_usefulness>
<library_use>
I substituted asio for existing networking libraries in two production
projects currently being developed and tested for embedded targets.
I had a couple of problems but the author promptly straightened me out.
The answers were, in fact, in the documentation.
Compilers:
arm-softfloat-linux-gnu-g++ (GCC) 3.3.3
g++ (GCC) 3.4.4 20050721 (Red Hat 3.4.4-2)
</library_use>
<problem_domain_knowledge>
Fairly knowledgeable. Mostly "handwritten" network programming in
Windows 3.x through XP (I was a MCSE/MCSD); UNIX SVR4; Solaris 7, 8 9;
and now Linux. A copy of "Stevens" is never very far away.
</problem_domain_knowledge>
Regards,
Dick Bridges
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk