Boost logo

Boost :

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,
> but
> I still doubt very much that asynchronous approach would have been
> better).

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
> think
> 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
equally) :-)

> Besides nobody yet convinced me that socket should depend on
> demultiplexer.

It does not. The real reason it depends on demuxer is that it contains the
socket service.
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, gregod at, cpdaniel at, john at