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
Hi Scott, --- Scott Harris <harris_s@ociweb.com> wrote: <snip>
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.
Although I guess it might make your vote a "no", it is not currently my intent to provide a reactive I/O interface as part of asio. Way back in the early days of asio I did investigate how to implement a reactive socket-is-ready interface, but found that an efficient and portable expression of this interface was not available. The problem is not helped by platforms where there is no reactive interface (Symbian is one example). In fact, asio was born as an idea as the result of a demonstration (based on ACE) that an efficient proactor could be implemented in terms of a reactor. Blocking synchronous I/O is of course still given first class support (i.e. not implemented in terms of async I/O).
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.
I am somewhat surprised, and intrigued, by these results, given that you were running on Windows. Which reactor implementation were you using - WFMO or select? I would guess select if you had to handle > 200 pending I/O requests. I ask because, after adding the custom allocation support during the review, a test run on Windows comparing asynchronous to synchronous I/O for a single socket (meaning only one pending I/O operation at a time) showed negligible difference in performance between them. I intend to spend some time developing a more comprehensive set of performance tests (there are some simple TCP throughput tests in CVS but not included in the boost proposal distribution). It sounds like it would be worthwhile developing equivalent tests using ACE's reactor classes for comparison. I'll also write some tests that use select or overlapped I/O directly to measure the abstraction penalty of asio. Cheers, Chris
participants (2)
-
Christopher Kohlhoff -
Scott Harris