Hi Mike, I've had second thoughts about this. See inline.
Michael Becke <[EMAIL PROTECTED]> wrote on 17.01.2005 17:34:37: > - A thread listens for connect operations on a server socket and adds > the opened sockets (connections) to a queue of pending async reads. > - Requests are dispatched from the queue of connections to waiting > threads, which process a single request. So the connection manager on the client side implements a pool, while the connection manager on the server side implements a request queue. To me, "manager" implies a pool, so I would prefer a different name on the server side. But since I'm not a native english speaker, I may be off here. I guess that's why I wrote that we don't need a connection manager on the server side. A request queue is definitely useful ;-) > - Once the request is processed the connection is either closed or > re-queued for further processing. > - The queue/pool of connections is then responsible for closing > connections that either go stale or that haven't been serviced within a > certain period of time. I would expect the connections that are not closed immediately go to a separate set. There they remain until they go stale, time out, or until the first data of the next request is available. Only then will a server connection go back to the request queue. In C or C++, one could try to set up a single blocking operation for all connections on hold. (Was that "select"? It's been too long.) In Java, I would use a polling thread. cheers, Roland
