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 ;-)
I would agree, a connection manager is a poor name. The writing and reading of requests seems to fit more of a producer/consumer relationship. In many ways neither the client nor the server really care about the connection. Their only real interest in in the request.
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.
Can't say much about the C++ side. Unfortunately I never had the joy of doing any real work in C/C++ :)
Ideally a single blocking operation that returned when the next request is available would be best. My knowledge of NIO is pretty minimal, but it seems like this should be an option.
Mike
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
