I didn't mean "what the thread should do" but rather "how the thread should do it" -- design, not purpose.

You have to start by thinking -- "if I was the thread, how would I achieve the task, what would I need and why". Then you should think of each of the procedures the same way, just in more detail until you have the whole concept in your head of even on paper (this way you won't forget about anything). Then you can start thinking about the implementation itself (meaning, what modules of the environment I use will fit best to what I want to do).

Because as for now I don't see a reason to use threads at all... I would just hold the connections in some data structures and connect appropriate signals to custom slots and implement everything in an event driven way. But, of course, I don't know the nature of requests that are to be handled. Depending on what they are to be and how are they to be handled, it could be better to use threads.