Tcp threaded vs single thread for server program

[kalster]

I am thinking that i need multiple threads for the chat server that i am about to program. is this true. why would i want single thread instead. is there a big difference in how they handle loads?

[ZapB]

First question to ask is why do you need/want to use multiple threads? If one thread will do the job why bother adding the extra complexity?

[kalster]

Good question ZapB.
I have read at a few places on the net that a single thread will slow down when there is lots of connections and that when there is lots of connections attempts with a single thread then some users will get a busy message. is this true?

[ZapB]

To a certain degree that is true. Any thread can only do one thing at a time so if it is busy servicing and existing client then it will not be available to create a new connection for a new client. The sort of questions you should then ask are:

• how many users do you wish/expect/have to support at any one time?
• how long will your thread be blocked when it is servicing a client? Remember that most of the time will likely be spent doing nothing at all except waiting for network traffic.
• is the result of the above going to lead to an unacceptable delay for new connections or servicing existing ones?

If so then yes you may want to think about adding threading in to the picture. If there is no problem, if you only want to allow 2 people to chat for example, then really don't bother.

Let's assume for now that you find you do need to add threading. One way to go about it here would be to keep a thread, the main thread say, purely for handling incoming connection requests. When you get an incoming request you create a new QTcpSocket (or some other object that encapsulates your socket and the logic needed to handle your protocol) and then call QObject::moveToThread() on it to move it to some other worker thread. From that point on, any work involving that socket will be done by the helper thread, leaving the main thread free to handle any concurrent incoming connection requests.

Of course having one worker thread per connection is total overkill for a simple chat server. So what you would usually do is to allocate a number of sockets (or your own objects) to each thread. How you decide upon the number to allocate is application specific but again ask the same sort of questions as you did above to determine that you needed threads in the first place.

With regards to the specifics in the example you posted above. I would split this class into two. One to handle incoming connection requests and another one that can manage the resulting socket and the protocol you want to layer on top of it.

I hope this helps and gives you something to think about. Please feel free to come back with more questions.

[LinusA]

The question is whether you want to focus on programming effort, i.e. on a simple program, or on efficiency / heavy load.

If you want to do the latter, it's probably worth it to look at this older but still excellent article: http://www.kegel.com/c10k.html

Another example on "how to handle multiple network requests" is the reactor pattern: http://en.wikipedia.org/wiki/Reactor_pattern . The Python networking library "Twisted" ( http://twistedmatrix.com/trac/ ) makes heavy use of this pattern. I think a good introduction to the reactor pattern in Twisted is this: http://twistedmatrix.com/documents/current/core/howto/reactor-basics.html

So then you can try to estimate your needs, and decide which design / architecture suits your requirements best.