Advanced TCP Server Design - looking for expert advice

rootshell

I am thinking of creating a set of open source classes that would encompass the client and server aspects of most high level TCP protocols such as telnet, ssl, http, ftp, etc etc using Qt

Looking for opinions on the CORRECT way to design the TCP server. Obviously the server code will need to make threads at some point, should I be looking toward a QThreadpool design, or go the QtConcurrent route (uses QThreadPool under the hood), or possibly use the asynchronous calls from QTCPServer and deal with the threads directly.

I would make a base class (TCPServer), and then inherit for each protocol.

The end goal here is to have a set of classes that can be included in a project and "just work" so the programmer does not have to know the details, does not care about how it works, they just call something like

HTTPServer *server = new HTTPServer();
server->setRoot("/var/www");
server->setMaxConnections(1000);

Each connection to the server would be threaded - I am learning toward QtConcurrent as I have read it will automatically utilize the CPU cores and some other really cool features. The more I think about it, the more I think the connections don't need to be threaded, but rather the IO operations used in the connection need to be - possibly a case for QtConcurrent?

Looking for some expert advice, tips, or general direction

ckakman

Hi,

I am not an expert in server-side programming but here are some suggestions for you to consider:

A new thread for each connection does not scale. Is not necessary, since QTcpSocket is asynchronous by design. Even a single thread can probably handle hundreds of TCP connections. So start with a single-threaded design.
QtConcurrent is suitable for CPU-bound or fire-and-forget kind of workloads. QThreadPool is a better tool for objects interacting with outside world and with the rest of the application. But as stated above and below, start with and stick to a single-threaded design.
If scalability becomes an issue, say, to handle thousands of connections ("C10K Problem":http://en.wikipedia.org/wiki/C10k_problem), still stick to a single-threaded design and consider launching multiple server processes. Put the server processes behind a reverse-proxy such as HAProxy or Nginx.
Use threads, if unavoidable, for other kind of tasks, such as logging, DB access, file processing etc. Prefer async messaging. Consider caching to reduce latencies.

rootshell

Thanks, that was actually pretty insightful :)

mrdebug

I love to use threads and I know that the other people not.
I have written some tcp based components (http server and client and smtp sender objects) using threads because for me is very important to have a synchronized situation.
For me the threads way is very appreciated if a synchronized situation is needed. Obviously is hard instead of event approach.