- Boost - lists.boost.org

[asio] Formal review.
by Dick Bridges 31 Dec '05

31 Dec '05

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

2 1

asio review
by marcoh77＠freenet.de 31 Dec '05

31 Dec '05

- What is your evaluation of the design? The design looks quite good. There are some points I don't realy like, e.g. that there are no high level classes. The use for _simple_ network workings is too complex. It seems as if the instance user needs too much knowledge to start with asio. - What is your evaluation of the documentation? For a first release in boost it's good. But for the future there should be some more informations for network beginners like me. The first five tutorials shows how complex the library is because the examples have nothing to do with networking. It's realy strange and discourage for a beginner to use asio if he want to start with it. Although the tutorials are understandable. - What is your evaluation of the potential usefulness of the library? The asio library is very usefull and mainly _necessary_ for the C++ community. boost is the right organisation to push a network lib and to improve asio. For the future it's important to make asio more interesting for network beginners and simple network working. I think asio is a realy good base. - Did you try to use the library? With what compiler? Did you have any problems? I tried asio with the tutorial examples. I used it with VC++7.1 and everyting worked well. It looks like there is a mistake in the asio introduction, that said that you need only the headers of boost. But with the asio tutorials with the timers you need to build the boost.date_time library. I don't know if it's only for the VC++ users, but I needed in the first example the date_time library and not only the headers. But this is not a technical mistake. - How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? I have worked with the tutorial for one or to hours. - Are you knowledgeable about the problem domain? I'm a beginner in networking and used to this day only high level networking library like for webservice calls and like this. Do you think the library should be accepted as a Boost library? Be sure to say this explicitly so that your other comments don't obscure your overall opinion. Yes it should be accepted! Best regards Amin Kharchi PS: Sorry for my bad english. "Jetzt Handykosten senken mit klarmobil - 14 Ct./Min.! Hier klicken" www.klarmobil.de/index.html?pid=73025

2 1

asio review
by Scott Harris 31 Dec '05

31 Dec '05

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 asios 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

2 1

[Test] Many failures on gcc-3_3-darwin
by Douglas Gregor 31 Dec '05

31 Dec '05

There's an example here: http://tinyurl.com/azrrh It's some kind of multiple definition problem. Perhaps a missing "inline" somewhere? ld: multiple definitions of symbol __ZN5boost9unit_test92_GLOBAL__N__ZGVZN5boost9unit_test9ut_detail24auto_ test_unit_registrar13curr_ts_storeEvE4inst13unit_test_logE /Volumes/scratch/dgregor/BoostRegressionTesting/results/bin/boost/ libs/test/build/libboost_test_exec_monitor.a/gcc-3_3-darwin/debug/ libboost_test_exec_monitor-gcc33-d-1_34.a(framework.o) definition of __ZN5boost9unit_test92_GLOBAL__N__ZGVZN5boost9unit_test9ut_detail24auto_ test_unit_registrar13curr_ts_storeEvE4inst13unit_test_logE in section (__DATA,__data) /Volumes/scratch/dgregor/BoostRegressionTesting/results/bin/boost/ libs/test/build/libboost_test_exec_monitor.a/gcc-3_3-darwin/debug/ libboost_test_exec_monitor-gcc33-d-1_34.a(results_collector.o) definition of __ZN5boost9unit_test92_GLOBAL__N__ZGVZN5boost9unit_test9ut_detail24auto_ test_unit_registrar13curr_ts_storeEvE4inst13unit_test_logE in section (__DATA,__data) ld: multiple definitions of symbol __ZN5boost9unit_test92_GLOBAL__N__ZGVZN5boost9unit_test9ut_detail24auto_ test_unit_registrar13curr_ts_storeEvE4inst17results_collectorE /Volumes/scratch/dgregor/BoostRegressionTesting/results/bin/boost/ libs/test/build/libboost_test_exec_monitor.a/gcc-3_3-darwin/debug/ libboost_test_exec_monitor-gcc33-d-1_34.a(framework.o) definition of __ZN5boost9unit_test92_GLOBAL__N__ZGVZN5boost9unit_test9ut_detail24auto_ test_unit_registrar13curr_ts_storeEvE4inst17results_collectorE in section (__DATA,__data) /Volumes/scratch/dgregor/BoostRegressionTesting/results/bin/boost/ libs/test/build/libboost_test_exec_monitor.a/gcc-3_3-darwin/debug/ libboost_test_exec_monitor-gcc33-d-1_34.a(results_collector.o) definition of __ZN5boost9unit_test92_GLOBAL__N__ZGVZN5boost9unit_test9ut_detail24auto_ test_unit_registrar13curr_ts_storeEvE4inst17results_collectorE in section (__DATA,__data) /Volumes/scratch/dgregor/BoostRegressionTesting/results/bin/boost/ libs/test/build/libboost_test_exec_monitor.a/gcc-3_3-darwin/debug/ libboost_test_exec_monitor-gcc33-d-1_34.a(results_reporter.o) definition of __ZN5boost9unit_test92_GLOBAL__N__ZGVZN5boost9unit_test9ut_detail24auto_ test_unit_registrar13curr_ts_storeEvE4inst17results_collectorE in section (__DATA,__data) /Volumes/scratch/dgregor/BoostRegressionTesting/results/bin/boost/ libs/test/build/libboost_test_exec_monitor.a/gcc-3_3-darwin/debug/ libboost_test_exec_monitor-gcc33-d-1_34.a(unit_test_suite.o) definition of __ZN5boost9unit_test92_GLOBAL__N__ZGVZN5boost9unit_test9ut_detail24auto_ test_unit_registrar13curr_ts_storeEvE4inst17results_collectorE in section (__DATA,__data) Doug

2 1

[Date-time] Fix for testing Jamfile?
by Doug Gregor 31 Dec '05

31 Dec '05

It seems that the Jamfile for the date-time regression tests is making GCC 2.95.x regression testing fail with this: /.automount/magrathea/root/home/user3/dgregor/Projects/boost/tools/ build/v1/boost-base.jam:1585: in find-compatible-subvariant *** argument error * rule split-target-subvariant ( target-var properties-var toolset-var variant-var : subvariant ) * called with: ( sv-target sv-properties sv-toolset sv-variant : ) * missing argument subvariant /.automount/magrathea/root/home/user3/dgregor/Projects/boost/tools/ build/v1/boost-base.jam:2032:see definition of rule 'split-target-subvariant' being called /.automount/magrathea/root/home/user3/dgregor/Projects/boost/tools/ build/v1/boost-base.jam:1654: in link-libraries /.automount/magrathea/root/home/user3/dgregor/Projects/boost/tools/ build/v1/boost-base.jam:1857: in generate-dependencies /.automount/magrathea/root/home/user3/dgregor/Projects/boost/tools/ build/v1/boost-base.jam:1964: in subvariant-target /.automount/magrathea/root/home/user3/dgregor/Projects/boost/tools/ build/v1/boost-base.jam:2057: in main-target /.automount/magrathea/root/home/user3/dgregor/Projects/boost/tools/ build/v1/boost-base.jam:1369: in declare-local-target /.automount/magrathea/root/home/user3/dgregor/Projects/boost/tools/ build/v1/testing.jam:64: in boost-test /.automount/magrathea/root/home/user3/dgregor/Projects/boost/tools/ build/v1/testing.jam:552: in run Jamfile:218: in load-jamfiles /.automount/magrathea/root/home/user3/dgregor/Projects/boost/tools/ build/v1/bootstrap.jam:21: in boost-build /.automount/magrathea/root/home/user3/dgregor/Projects/boost/boost- build.jam:16: in module scope The following patch, which I've already applied, seems to fix the problem. However, that USE_DATE_TIME_PRE_1_33_FACET_IO define seems rather strange to me; is that really what was intended for the serialization tests? Doug Index: Jamfile =================================================================== RCS file: /cvsroot/boost/boost/libs/date_time/test/Jamfile,v retrieving revision 1.34 diff -u -r1.34 Jamfile --- Jamfile 28 Nov 2005 13:20:35 -0000 1.34 +++ Jamfile 29 Dec 2005 19:45:26 -0000 @@ -183,6 +183,8 @@ local DATE_TIME_PROPERTIES = <define>BOOST_DATE_TIME_STATIC_LINK <define>BOOST_ALL_NO_LIB <define>USE_DATE_TIME_PRE_1_33_FACET_IO std::locale-support toolset::require-boost-spirit-support ; + local DATE_TIME_DYNAMIC_PROPERTIES = <define>BOOST_ALL_DYN_LINK <runtime-link>dynamic <define>USE_DATE_TIME_PRE_1_33_FACET_IO <define>BOOST_ALL_NO_LIB + std::locale-support toolset::require-boost-spirit-support ; test-suite date_time_serialization :

2 1

[asio] socket_stream noncopyable
by Felipe Magno de Almeida 31 Dec '05

31 Dec '05

Hello, I have some questions that I'm not getting answers from the documentation: Why is socket_stream noncopyable? Is it an expensive class? If it is, why?? How can I create sockets and accept them without using new on them? I'm not being able to figure it out how. Thanks, -- Felipe Magno de Almeida

2 3

A Re: Filesystem I18n comments
by Seb Martel 30 Dec '05

30 Dec '05

> > > > I would welcome a non-throwing iterator as well. Most of our path > > iterating routines are littered with try catches to handle cases that > > aren't truly exceptional. > > Is the litter just to deal with exceptions coming out of directory_iterator > constructors? Or are there other use cases needing excessive try/catch > blocks? It is pretty much all about handling throwing constructors. > > Also, what should the interface to a non-throwing directory_iterator look > like? > > First try - in addition to the current public members, add: > > directory_iterator( const path & ph, std::nothrow_t ); > // Effects (in addition to normal construction): If error occurs, save > errno, and make iterator == the end iterator. > > system_error_type error(); > // Returns 0 if no constructor error, else errno saved by the > constructor This works well, however, pie in the sky, can we consider making the directory_iterator be no_throw by default ? Our catch implementations either logs the error and/or ignores it (pretty much all our current use cases), or pushes up a message to the user signaling the invalid input (only one occurrence of this behavior in our app): skip and move on is our most common scenario. Such a no-throw interface would at least not kill the iteration process in the advent of an error. The grief comes from a dev forgetting to try/catch the errors and the whole process being aborted prematurely and half completed. This usually gives unsatisfactory results for the user. We catch those problems in the QA cycle, but the fix isn't with a logic error, simply oversight from the developer. I would prefer having a reversed situation where the dev has the responsibility to look for errors if the specifications of the use-case requires to. The status quo is to simply try catch all path iterating routines. On a separate note, I ran into fun times with the MAX_PATH limitation on win32 =) The issue is that GetFileAttributesEx (used through fs::exists for one) fails to process anything bigger than MAX_PATH through the ascii interface. Exists would simply return false. This was causing an infinite loop in a routine that was attempting to create a unique filename through repeated tests. The wide version of GetFileAttributeEx supports a 32,767 character limit, on all but windowsME/98 platforms. Can this situation be improved by considering using the wide interface when MAX_PATH considerations kick in? Possibly introduce some asserts, or *gulp* exceptions? Cheers, -seb

1 0

lvalues and rvalues
by Arkadiy Vertleyb 30 Dec '05

30 Dec '05

Hi, What is current state of the art on l-value/r-value detection? (I know Eric made some progress in the past by using the "?" operator). What we have in typeof is quite primitive :-( I think it might be a good idea to eventially factor it out into a separate header file, and reuse, to avoid contradictions between different libs, and provide the single point of maintenance... Regards, Arkadiy

11 22

yet another asio review
by Jose 30 Dec '05

30 Dec '05

I vote YES to accept asio into boost. Below are some general comments, mostly on what I think should be added. Many thanks to Chris for sharing his expertise and continuing to work on this much needed library ! I have an FC4 x86_64 box and have spent several hours using the library and writing basic examples. I have spent many more hours surveying networking libraries and ensuring I wanted to use asio - documentation and examples It would be nice to add some client/server protocol guidelines that help in designing protocols. Something along the lines on what Chris wrote to compare using the reactor pattern vs using the proactor pattern in asio but geared to different protocols characteristics like fixed header vs variable header, line-oriented, .. The documentation could also include some tips on how to handle special cases raised in the list, like throttling .. An HTTP GET client example would be nice. Not a complete example but maybe an skeleton that can be compiled and shows how asio should be used. No doubt this would be the most used example ! - design This is the main reason I became interested in asio. The design is not only sound but also reflects the practical and wide networking experience of the author - implementation I think the library should use Boost.Threads maybe in addition to the current approach. By using Boost.Threads with asio we'll ensure continued feedback/improvements for two libraries that in many cases will be used together - performance While it has been raised that a synch iostreams interface is nice for basic usage, the major value of C++ asio is performance. I think it would be useful to keep some focus on this, maybe by providing a basic client framework to measure server performance. A basic usage for this would be to compare/benchmark different asio server implementations (latency and throughput). Look forward to the new releases !!

1 0

BCCL : Serialization Concept
by nitin motgi 30 Dec '05

30 Dec '05

Hi, Is there something in the pipeline for BCCL to validate the serialization concept. Thank you, Nitin Motgi NITIN . DOT. MOTGI .AT. GMAIL .DOT. COM

4 7