Re: [boost] [network] An RFC posted to the sandbox

From: Caleb Epstein (caleb.epstein_at_[hidden])
Date: 2005-04-13 11:01:39

On 4/12/05, Don G <dongryphon_at_[hidden]> wrote:

> I've posted a zip with an HTML file and an HPP file that describes an
> abstract way to interact with the network. It is intended as a medium
> level interface. By that I mean it is above the socket layer, but
> below buffering/proactor/reactor kinds of thinking. It is really a
> pure C++ way to interact with the primitive concepts of networking.

Overall it looks pretty nice.  A few observations:

* port_t should be unsigned short, not unsigned int

* timeout constructors are inconsistent.  One takes seconds +
microseconds and one takes milliseconds, at least according to the
names of the arguments.

* I wouldn't call the type you pass to the
network::new_{local,broadcast,loopback,}_address method a "url".  It
isn't one.  Perhaps "address_specifier" would be better?  I can
imagine some sort of "stream factory" class with pluggable protocols
(e.g. http, https, ftp, etc) that would take fully qualified URLs to
create new streams, but in this case you're dealing with at most a
hostname and port.

> I believe the code recently posted by Michel André is complementary
> in the sense that it is a way to connect implementation details such
> as stream/datagram with how I/O blocking is performed. That said,
> there is a fundamental difference in what the user of the library
> would see and have to handle. It may just be me, but I am not a fan
> of the coupling created by explicitly connecting multiple I/O objects
> with a dispatcher. This is a tedious prospect. Especially when there
> are limits on the number of such connections a dispatcher can handle
> (such as 64-ish for Windows).

I'd contend that in general, an operating system supplied multiplexing
facility will scale better than one that uses a thread to handle each
connection.   Without some sort of multiplexing facility, how do you
know when a channel is ready for I/O?  It seems that your proposal is
to use a pool of threads to handle async/non-blocking operations, but
I don't see any interfaces defined to control or manage these
operations.  Is that just TBD?

Clearly Windows select and WFMO are not as scalable as UNIX
select/poll/etc, but I'd contend that if one is writing a serious
networking application for Windows, you are going to make use of
*both* of these approaches (>1 instance of WFMO/select and thread
pooling).  In some cases, you may want to do this on UNIX too.

I think the point I am trying to make is that there isn't necessarily
one right answer.  Pools of threads are good for some things, and I/O
multiplexing facilities are good for some things.  And in some cases,
taken both together they are a good thing as well.

-- 
Caleb Epstein
caleb dot epstein at gmail dot com