Advantage of Synchronous vs asynchronous in TCP socket connection

Question

I'm currently learning C# coming from a java background. To get my feet wet I decided to make a simple SMTP mail application. And I learned very quickly that C# offers support for both Synchronous and Asynchronous sockets.

From what I can see, there is no real advantage to using a synchronous socket vs an asynchronous since the latter doesn't block and therefor doesn't require you to create a new thread each time. There also doesn't seem to be a noticeable overhead to using one or the other.

So my question is this, is there an advantage to using a synchronous socket or is it better to just stick with asynchronous in most cases?

Solution 1

Either mechanism will work. The main difference is that synchronous implies either blocking a thread that would otherwise do other useful things, or dedicating a thread to each connection. Either way, this does not scale very well. For simple applications with few or just one active connection, it might be okay.

But for any scenario where you need to handle any significant number of concurrent connections, the asynchronous APIs are the only ones that provide adequate performance. Also, in any interactive scenario (i.e. where you have to deal with user input and output), the asynchronous approach is more easily integrated with the user interface. That's especially true now that we have async and await in C#.

Solution 2

Async IO saves threads. A thread consumes (usually) 1MB of stack memory. This is the main reason to use async IO when the number of concurrent outstanding IO operations becomes big. According to my measurements OS scalability is not a concern until you get into the thousands of threads.

The main disadvantage is that it requires more development effort to make the same application work at the same level of reliability.

I have written about this tradeoff at length. Also: Should we switch to use async I/O by default?

It is objectively wrong advice to recommend to always use async IO.

Solution 3

Independently of the programming language you are using, suggesting only async sockets is a bad advice. It is true that all problems can be solved using async, but not all (e.g. 100'000 connections) can be solved using synchronous ones. But most of the time, problems tend to be simpler (<100 connections).

In my experience, (mediocre) programmers tend to get lost in the mess they are creating using async sockets, whereas handling a sync socket in a separate thread is simple, understandable and more maintainable. Creating a thread under Windows is costly, assuming a proper operating system, it is much less overhead (5 us on x86 / Linux). Also it doesn't take 1 MB of RAM for a thread (at least not with a native program), but rather a few kb for stack and state (registers).

On top, a lot of people argue that synchronous socket programming is slower, but that's not always true. Context switches (to other threads) have a cost, but async socket interfaces are also not cheap for the operating system kernel.

As always: chose the solution that best fits the situation.