The advantage of synchronous and asynchronous in connecting TCP sockets

Question

I am currently learning C # based on the java background. To keep my feet wet, I decided to create a simple SMTP email program. And I quickly found out that C # offers support for both synchronous and asynchronous sockets.

From what I see, there is no real advantage to using a synchronous socket versus an asynchronous socket, since the latter is not blocked and you do not need to create a new stream every time. Also, the overhead for using one or the other does not seem noticeable.

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

Answer 1

Any mechanism will work. The main difference is that synchronous means either blocking the thread, which otherwise could do other useful things, or dedicating the thread to each connection. In any case, it does not scale very well. For simple applications with few or only one active connection, this may be normal.

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

Answer 2

Async IO saves threads. A stream consumes (usually) 1 MB of stack memory. This is the main reason for using async IO when the number of simultaneous I / O operations becomes large. According to my measurements, OS scalability is not a concern until you enter thousands of threads.

The main disadvantage is that to increase the efficiency of the same application requires more development effort.

I already wrote about this compromise. Also: Should we switch to using async I / O by default?

This is objectively incorrect advice to recommend always using async IO.

Answer 3

Regardless of the programming language you use, offering only asynchronous sockets is bad advice. It is true that all problems can be solved using asynchronous, but not all (for example, 100,000 connections) can be solved using synchronous. But in most cases, the problems are usually simpler (& lt; 100 connections).

In my experience, (mediocre) programmers tend to get lost in the mess they create using asynchronous sockets, while processing a synchronizing socket in a separate thread is simple, straightforward, and more convenient to maintain. Creating a thread under Windows is expensive, provided the operating system is correct, it is much less overhead (5 on x86 / Linux). In addition, it does not require 1 MB of RAM for the stream (at least not with the native program), but several kilobytes for the stack and state (registers).

In addition, many argue that synchronous socket programming is slower, but this is not always the case. Context switches (for other threads) come at a cost, but asynchronous socket interfaces are also expensive for the operating system kernel.

As always: I chose the solution that best suits the situation.