Windows Sockets: Blocking

This article and two other related articles explain some issues in Windows Sockets programming. This article describes blocking. Other issues include Windows Sockets: byte sorting and Windows Sockets: conversion string.

If you use the CAsyncSocket class or derive from it, you need to manage these issues on your own. If you use a CSocket class or derive from it, it is managed by MFC. Blocking

The socket can be in blocking mode or non-blocking mode ". In blocking (or synchronous) mode, the function of the socket does not return until it can complete its own operations. This is called "blocking" because the socket called by the function cannot perform any operation before it returns the call-it is blocked. For exampleReceiveThe call of a member function may take any long time to complete, because it needs to wait for the application to be sent (UseCSocketOr useCAsyncSocke). IfCAsyncSocketWhen the object is in the non-blocking mode (Asynchronous Operation), the call will immediately return, and the current error code (you can use the GetLastError member function to retrieve) isWSAEWOULDBLOCKIt indicates that, due to the mode, the call will be blocked if it is not returned immediately. (CSocketNever returnWSAEWOULDBLOCK. This class blocks your management .)

In 32-bit operating systems (such as Windows 95 or Windows 98) and 16-bit operating systems (such as Windows 3.1), socket behavior is different. Unlike 16-bit operating systems, 32-bit operating systems use preemptible multi-task processing technology and provide multi-thread running methods. In a 32-bit operating system, the socket can be placed in a separate auxiliary thread. The socket in the thread can be blocked without interfering with other activities in the application, and does not have to spend computing time on blocking. For information on multi-threaded programming, see the article multi-threaded programming.

Note:In multi-threaded applications, you can useCSocketTo simplify the program design, without affecting the user interface response. By processing user interaction in the main thread andCSocketAnd separate these logical operations. In non-multithreading applications, these two activities must be merged into a single thread for processing. This usually means thatCAsyncSocketTo process communication requests or rewrite them as neededCSocket: OnMessagePendingTo process user operations during a long synchronization activity.

The rest of the discussion targets programmers with 16-bit operating systems:

GenerallyCAsyncSocketAvoid blocking operations, but use asynchronous operations. For example, in an asynchronous operationReceiveAfter receivingWSAEWOULDBLOCKThe error code starts at that moment and you will waitOnReceiveThe member function is called to notify you that you can read it again. Use the appropriate callback notification function (such as OnReceive) of the callback socket to complete asynchronous calls.

In Windows, blocking calls are considered incorrect. By default, CAsyncSocket supports asynchronous calls, and you must use callback to notify yourself to manage blocking. On the other hand, the CSocket class is synchronous. It extracts Windows messages and manages blocking for you.

For more information about blocking, see the Windows Sockets specification. For more information about the "On" function, see Windows Sockets: Socket notification and Windows Sockets: derive from the socket class.

For more information, see:

• Windows Sockets: CAsyncSocket class
• Windows Sockets: Use a socket with an archive
• Windows Sockets: Background
• Windows Sockets: streaming socket
• Windows Sockets: Data PACKET socket