From: Don G (dongryphon_at_[hidden])
Date: 2005-04-13 22:24:26
--- 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.
Do you Yahoo!?
Yahoo! Small Business - Try our new resources site!
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk