On Thu, 15 Dec 2005 14:57:18 -0500, "Arkadiy Vertleyb" <vertleyb@hotmail.com> wrote:
Thus limiting your #simultaneous connections to the number of threads in your thread pool. You can do better by doing all the parsing, request splitting, etc. in a async-using main acceptor thread and handing off smaller bits of work to the threads in the pool. That way you can exploit the fact that some threads may finish some parts of a given request early, and may be available to serve other connections.
Thus serving the same connection from different threads? I just don't happen to like how this would impact the processing algorithm...
You can do what I do, which is to always service the same connection from the same thread. Since my clients can pipeline requests, I don't want requests to be handled out of order. Assigning a connection to a thread in the thread pool is an easy way to solve that problem. Packets are read and parsed in the communications thread, and I send out smaller units of work to the thread pool. From the handlers that are executed in the thread pool I can queue up reply packets to be sent by the communications thread. This way I can connect thousands of clients and keep them connected all day, and service them all simultaneously from a very small number of threads. I could even do everything in one thread if I wanted to. I've done thread-per-connection servers as well, and to be honest I think an async design is easier to work with. If you have a good framework like asio, it can actually end up being cleaner. (At least to my eyes.) -- Be seeing you.