Re: [boost] Re: Re: Network library: What we have until now

From: Scott Woods (scottw_at_[hidden])
Date: 2005-04-13 18:50:32

----- Original Message -----
From: "Edward Diener" <eddielee_at_[hidden]>
To: <boost_at_[hidden]>
Sent: Thursday, April 14, 2005 4:57 AM
Subject: [boost] Re: Re: Network library: What we have until now

> Caleb Epstein wrote:
> > On 4/13/05, Don G <dongryphon_at_[hidden]> wrote:
> >> I also believe that non-blocking is an I/O only thing; it is not
> >> needed for connect or accept.
> >
> > Not sure about the need for a non-blocking accept, but a non-blocking
> > connect is a must-have.
>
> While a non-blocking connect is a must-have I think a non-blocking accept
is
> essential also. A server needs to be just as responsive to other things
> happening as a client. One might need to pause or stop the server
> completely, depending on the meaning given to each, and a server might be
> accepting connections on more than one endpoint. Without a non-blocking
> accept, both these general possibilities become impossible and one ends up
> with a single end-point server which must be killed to end the process,
> which I do not think scales well in today's world of network programming.
>

Asynchronous listen, accept and connect please. Network activity is innately
asynchronous and a design for *the* network library that veers away from
that
is precluding what is more natural.

A hybrid of async (e.g. accept) and sync (e.g. connect) also results in a
more complex set of classes+templates. Especially when compared with a
design
where the lowest (i.e. base) class related to clients and servers is one and
the
same. Both ends of a connection-oriented service issue network requests
(connect or listen) and subsequently wait for establishment. This
commonality
of operation can be exploited nicely.

For those still wanting synchronous behaviour (there are perfectly good
reasons
I'm sure ;-) this can still be achieved over the top of async. The same
cannot be
said for the reverse.

These points are relevant to I/O of course.