From: Eugene Alterman (eugalt_at_[hidden])
Date: 2005-12-14 18:53:33
"Arkadiy Vertleyb" <vertleyb_at_[hidden]> wrote in message
> All I was trying to say is that, as a potential client of the library
> (everybody does some networking now and then), I tried to map it to one of
> the tasks I had in the past. I happen to have solved that task by using
> synchronous operations + multiple threads (maybe because it is the most
> intuitive way for a not very experienced network programmer, which I am,
> I still doubt very much that asynchronous approach would have been
If you are using socket API or a C++ library that just provides simple
wrapper classes for socket API a thread per conection approach is of course
the most intuitive. The problem is that it does not scale well.
> So, when I am evaluating a "Networking Library", and see that it clearly
> consideres one approach to networking inferior to the other one, and I
> they both are equaly important, that means that I am in fundamental
> disagreement with the library author on the subject, and makes me wonder
> whether this is the networking library I would like to see in Boost.
One approach is inferior to the other and they are both important (but not
> Besides nobody yet convinced me that socket should depend on
It does not. The real reason it depends on demuxer is that it contains the
Otherwise demultiplexer could have been passed as an argument only when
performing asynchronous operations.
> The fact that it "has been proven to work well" is "not enough of an
> excuse", IMO. Otherwise this review would not make any sense.
> I totally appreciate the fact that the library has a lot of positive
> reviews, and, as you say, proven to work well. All I want is that the
> synchronous approach to networking was given enough attention, and added
> cleanly rather than as a fast fix -- a wrapper around asynchronous stuff.
It is not.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk