PDA

View Full Version : Server with multiple clients without threads



kernel.roy
8th September 2010, 15:16
Hi all,

I am very new in Qt. i am trying to implement the following link:
http://www.qtcentre.org/wiki/index.php?title=Server_with_multiple_clients_witho ut_threads

But their is no code ....
Can anyone help me for the example....

daemonna
8th September 2010, 15:45
why not use threading? every modern computer support threading and got more than one CPU core.... and PC's of tommorrow gonna have even more cores..

tbscope
8th September 2010, 17:19
Using threads when no threads are needed is a sign of very poor design.

The basic idea is this:
In your server implementation:
* Create a list that keeps track of client sockets
* For each new connection, add the socket to the list
* Connect the useful signals of the socket to a slot in your server implementation
* Signals like readyRead() and disconnected()
* Do not use the waitFor... functions

daemonna
9th September 2010, 13:07
what is poor about using multithreading on multi-core processors??? i guess it's more fear of threading...

Using threads when no threads are needed

if you program real server app, which will run on 8-24 thread CPU (i7, new AMD), NOT using threading is poor decision... simply coz you dont take advantage of HW.

wysota
9th September 2010, 13:20
what is poor about using multithreading on multi-core processors???
Nothing if you have more cores in your machine than processes in your systems + maximum number of clients you handle concurrently. And if you really like synchronizing threads :) But in a general case there is no point in using threading simply because you can.


if you program real server app, which will run on 8-24 thread CPU (i7, new AMD), NOT using threading is poor decision... simply coz you dont take advantage of HW.
Bearing the fact that most of the time all your threads will be doing nothing waiting for network to deliver data to them, you won't be really "taking advantage of HW" - your computer will just spend most of its time context switching between threads and doing bookkeeping. There is simply no advantage in doing networking by itself as multithreaded if you can do it another way. I don't say threads shouldn't be used to do the actual work on behalf of networking clients but not to do networking itself.

Archimedes
9th September 2010, 15:52
I suggest to read this great article "The C10K problem (http://www.kegel.com/c10k.html)", strategies to handle a lot of traffic. It's what your server will do and how much traffic will have that will determine threading or not.

daemonna
9th September 2010, 17:19
I suggest to read this great article "The C10K problem (http://www.kegel.com/c10k.html)", strategies to handle a lot of traffic. It's what your server will do and how much traffic will have that will determine threading or not.

that's it... if you just wanna play, or wanna make server for few users, than dont bother with threads, coz


Bearing the fact that most of the time all your threads will be doing nothing waiting for network to deliver data to them, you won't be really "taking advantage of HW" is actually right.

But if you wanna do (or you're planning to do) serious work for some enterprise (document server, some new form of corporate chat, game server a la "eve-online", than threads are 'MUST HAVE' and you should learn it....

wysota
9th September 2010, 17:37
But if you wanna do (or you're planning to do) serious work for some enterprise (document server, some new form of corporate chat, game server a la "eve-online", than threads are 'MUST HAVE' and you should learn it....

Read my response again :) And trust me, I know how (and most of all when) to use threads.

By the way, I don't think a "chat server" needs to be multithreaded. As for game servers and games themselves, most of them are unfortunately singlethreaded in nature - the networking is done multithreaded but the core is singlethreaded because of synchronization issues. And most of the time network bandwidth is the bottleneck and not the processing power which places multithreaded networking in a dubious position.

And most people do networking in multiple threads simply because they don't have skills, knowledge or tools to do it in a single thread.