Asynchronous vs. Synchronous Socket for Several Sockets In Potentially Thread Intensive Application

Question

I'm writing a relatively large application for my company on Compact Framework 2.0 for a Windows CE device, and I'm working with a single CPU core.

Without getting into details, non-socket related work can, at worst case timing, have 10 or so threads running simultaneously.

This in mind, I'm using sockets for the first time in anything more than a small test application. This larger application will potentially be talking to 7 different ports on the same IP address (example with an obviously false IP, 1.2.3.4:4000, 1.2.3.4:4001, 1.2.3.4:4002, etc.), thus using 7 different socket objects.

Compact Framework 2, 1 CPU core, around 10 non-socket threads in a worst case scenario, and 7 sockets to program send capability and continuous receiving (to process/respond ASAP) for all of them.

I've been considering if asynchronous socket programming would only get me in trouble, with the default max number of threads being 25 (per core) for Compact Framework 2.0, and essentially how "clever" I have to get.

What are your recommendations? Asynchronous or synchronous socket programming, and any particular additional details you'd suggest, or if I am worrying about nothing.

Answer 1

As your device surely has limited memory and because .NET thread stacks consume 1MB of memory by default (committed, not just reserved) I think you should go with async IO because it does not block thread. Only your callbacks/continuations get posted on the thread-pool. There are few thread-pool threads so memory usage due to stacks is lower.

Remember, that async IO is mostly about not blocking threads, thereby saving on memory and OS handles. It is not about lower CPU cost (the opposite is true according to my benchmarking with network IO).

Answer 2

I always recommend asynchronous sockets over synchronous sockets. Depending on the underlying subsystem, asynchronous sockets may not use any additional threads. Most of the time, using synchronous sockets requires manually creating threads to avoid blocking the UI (if you have one).

Having something else manage asynchrony is much easier than having to manage your own threads.

Whatever asynchronous sockets do won't impact the .NET thread pool