1

When you're dealing with socket IO using BeginReceive/EndReceive, the callback is invoked by an IOCP thread.

Once you're done receiving you need to process the data.

  • Should you do it on the callback's calling thread?
  • Or should you run the task using the ThreadPool.QueueUserWorkItem

Normally samples do the work on the callback thread, which is a little bit confusing.

If you're dealing with several hundred active connections, running the processing on the IOCP thread ends up with a process with hundreds of threads. Would ThreadPool help limiting the number of concurrent threads?

John Saunders
  • 160,644
  • 26
  • 247
  • 397
pablo
  • 6,392
  • 4
  • 42
  • 62

2 Answers2

2

I don't know that there's a generic 'right answer' for everyone - it will depend on your individual use case.

These are some things to consider if you do consider going down the ThreadPool path.

Is Out of Order / Concurrent message processing something you can support?

If Socket A receives messages 1, 2, and 3 in rapid succession - they may end up being processed concurrently, or out of order.

.NET has per-CPU thread pools, if one CPU runs out of work, it may 'steal' tasks from other CPUs. This may mean that your messages might be executed in some random order.

Don't forget to consider what out-of-order processing might do to the client - eg if they send three messages which require responses, sending the responses out of order may be a problem.

If you must process each message in order, then you'll probably have to implement your own thread pooling.

Do you need to be concerned about potential Denial of Service?

If one socket suddenly sends a swarm of data, accepting all of that for processing may clog up internal queues and memory. You may have to limit the amount of un-processed data you accept.

  • The socket will receive messages from different clients, open a connection with each. The point of the async is to avoid having one thread bind to each connection. – pablo Mar 18 '12 at 20:50
  • Yes, I understand that. My point was that you have no control over the order-of-execution for ThreadPool tasks. So, if you choose to use the ThreadPool (or implment your own) you'll have to consider how you deal with out-of-order and/or parallel execution of tasks. –  Mar 19 '12 at 09:55
0

IOCP threads has meant for serving IO operations. if your work executed by iocp callback can be long running or incures locks or other facilities that my block execution, you'd better hand it of to a worker thread.

TakeMeAsAGuest
  • 957
  • 6
  • 11