You wouldn't want to start any number of threads with TBB, but on the other hand TBB's main ideasare deliberately unfair for the sake of throughput, and one or two of your clients wouldn't be too happy about that, so you have to work around that, as follows:
I would have a dedicated thread assemble data into complete messages and then either enqueue tasks for them (depending on how the more-or-less FIFO behaviour of the schedule for those works out in practice) or feed them into a concurrent_queue (don't block inside a TBB task waiting for more messages, though), in both approaches going round-robin over the set of connections, subject to throttling policy. The second approach is fairer both because the concurrent_queue is stricter (absolutely FIFO instead of approximately FIFO, butthe schedulerwould be only approximate for the sake of better performance, so...) and because it won't give priority to new messages (enqueued tasks) over helping out with other messages (stealing work has a lower priority, unless that's what you want of course), but it is slightly more complicated to set up and only worth it if fairness is crucial.
That should get you started, I think, unless you actually do have priorities to contend with. Of course I'm interested to hear about ready examples, better ideas, ... The TBB Book has some things that could help, but I should have another look myself to see how much (the packet processing example comes to mind), and it may not have anything with task enqueueing in it yet (unless my copy is just outdated).
