2

I need some guidance on a project we are developing. When triggered, my program needs to contact 1,000 devices by TCP and exchange about 200 bytes of information. All the clients are wireless on a private network. The majority of the time the program will be sitting idle, but then needs to send these messages as quickly as possible. I have come up with two possible methods:

Method 1 Use thread pooling to establish a number of worker threads and have these threads process their way through the 1,000 conversations. One thread handles one conversation until completion. The number of threads in the thread pool would then be tuned for best use of resources.

Method 2 A number of threads would be used to handle multiple conversations per thread. For example a thread process would open 10 socket connections start the conversation and then use asynchronous methods to wait for responses. As a communication is completed, a new device would be contacted.

Method 2 looks like it would be more effective in that operations wouldn’t have to wait with the server device responded. It would also save on the overhead of starting the stopping all those threads.

Am I headed in the right direction here? What am I missing or not considering?

michal.jakubeczy
  • 8,221
  • 1
  • 59
  • 63
Bernie Hunt
  • 306
  • 4
  • 22
  • I would not expect the threading architecture to be the bottleneck but rather the contention with regard to the network adapter(s) and the WLAN in general. Therefore, you should try to contact the clients in such a way that (fruitless) contention and retransmissions are minimized. Pay special attention to your Windows version and the adapter drivers. – Axel Kemper Mar 29 '15 at 21:56

1 Answers1

2

There is a well-established way to deal with this problem. Simply use async IO. There is no need to maintain any threads at all. Async IO uses no threads while the IO is in progress.

Thanks to await doing this is quite easy.

The select/poll model is obsolete in .NET.

usr
  • 168,620
  • 35
  • 240
  • 369