The first case is called a synchronous or blocking session. In other words, the program is "blocked" until the request for data has been satisfied. When the remote system does write some data on the socket, the read operation will complete and execution of the program will resume. The second case is called an asynchronous or non-blocking session, and requires that the application recognize the error condition and handle the situation appropriately. Programs that use non-blocking sockets typically use one of two methods when sending and receiving data. The first method, called polling, is when the program periodically attempts to read or write data from the socket (typically using a timer). The second, and preferred method, is to use what is called asynchronous notification. This means that the program is notified whenever a socket event takes place, and in turn can respond to that event. For example, if the remote program writes some data to the socket, an event is generated so that program knows it can read the data from the socket at that point.
With Visual Studio .NET, it is recommended that most applications using blocking (synchronous) sessions. However, it should be noted that blocking sockets can introduce some special problems in single-threaded applications. The blocking function will allow the application to continue processing messages from the operating system. Because messages are being processed, this means that the program can be re-entered at a different point with the blocked operation suspended on the program's stack. For example, consider a program that attempts to read some data from the socket when a button is pressed. Because no data has been written yet, it blocks and the program begins processing system messages. The user then presses a different button, which causes code to be executed, which in turn attempts to read data from the socket, and so on.
To resolve the general problems with blocking sockets, the Windows Sockets standard states that there may only be one outstanding blocked call per thread of execution. This means that applications that are re-entered will encounter errors whenever they try to take some action while a blocking function is already in progress. It is recommended that worker threads be created to manage each client session, with each thread owning a specific instance of the class being used. This resolves the potential conflict between multiple blocking sessions in the same thread, and will improve the performance of the application overall.
The only time that non-blocking (asynchronous) sessions are recommended are with single-threaded applications with a user interface that the user must interact with as the network operation is being performed. It should be noted that there is additional overhead involved with asynchronous sessions which can negatively impact the overall performance of the application. When possible, a multi-threaded solution using worker threads to handle the client session in the background is preferred.
In summary, there are three general approaches that can be taken when building an application with the control in regard to blocking or non-blocking sockets:
If you decide to use a non-blocking session in your application, it’s important to keep in mind that you must check the return value from every read and write operation, since it is possible that you may not be able to send or receive all of the specified data. Frequently, developers encounter problems when they write a program that assumes a given number of bytes can always be written to, or read from, the socket. In many cases, the program works as expected when developed and tested on a local area network, but fails unpredictably when the program is released to a user that has a slower network connection (such as a serial dial-up connection to the Internet). By always checking the return values of these operations, you insure that your program will work correctly, regardless of the speed or configuration of the network.