----- Original Message ----- From: "Edward Diener" <eddielee@tropicsoft.com> To: <boost@lists.boost.org> 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@yahoo.com> 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.