Hi Edward, --- Edward Diener wrote:

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.

But an async interface provides this capability. You say something like async_accept(call_here_for_a_connection) and proceed with life. If the callback must occur on a given thread, that is a different concern. I have been suggesting that this situation be handled by a purely async library that handles a queue of boost::function<> objects, so instead of blocking on select, you block on the queue. For scaling, one really needs to consider threads in order to take advantage of multiple processors. To gain this benefit in a single-threaded server, one would have to have multiple processes. It can be done, but I think the multi-threaded single process would scale better. Not to say that I have gathered any hard statistics to prove my assertion. :) This is the approach I have taken for scalability in the proposal I posted. Best, Don __________________________________ Do you Yahoo!? Yahoo! Small Business - Try our new resources site! http://smallbusiness.yahoo.com/resources/