Boost logo

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