Windows IO methods

First, the summary

Winsock provides both socket mode and socket I/O models, which control the I/O behavior on a socket. Where the socket pattern is used to determine the behavior of those Winsock functions when called with a socket. On the other hand, the socket model describes how an application manages and processes the I/O on a socket.

Winsock provides two socket modes: locked and non-locked.

Winsock provides the V socket model: These models include select (selection), WSAAsyncSelect (asynchronous selection), WSAEventSelect (event selection), Overlapped I/O (overlapped I/O), and completion Port (completion ports), and so on.

Two, Socket mode

Windows Sockets perform I/O operations in two modes: locked and non-locked. In lockdown mode, the Winsock functions that perform operations (such as send and recv) wait until the I/O operation is complete and do not immediately return to the program (return control to the program). In the non-locking mode, the Winsock function returns immediately anyway.

2.1 Lock mode

Calling any of the Winsock APIs on a locked socket may be a good fat long or short wait time. The following code snippet is an example.

If no data is in the "Pending" state, then the RECV function may never return. This is due to the statement that it is possible to return only if something is read back from the input buffer of the system!

In order to prevent the lack of data, there are many reasons for the lack of data, such as network failure, client problems and so on. At this point we can translate the application into a read thread, a compute thread. Two threads share a data buffer, which is implemented by synchronizing objects, such as an event or mutex.

One drawback to a locked socket is that it is difficult for an application to communicate through multiple, connected sockets at the same time. Using the method described above, we can modify the application so that it assigns a read thread to each of the connected sockets, and a data processing thread. While this will still add some overhead, it is certainly a viable option. The only drawback is that the scalability is very poor, I would like to deal with a large number of sockets at the same time, it is difficult to start.

2.2 Non-latching mode

The following shows a socket and sets it to non-locking mode

Three, Socket IO model

The Windows operating system provides selection (select), asynchronous Selection (WSAAsyncSelect), event selection (WSAEventSelect), overlapped I/O (Overlapped I/O), and completion ports (completion port) A total of five I/O models. Each model is suitable for a specific application scenario. Programmers should be very clear about their application needs, and take into account the scalability and portability of the program and other factors, make their own choices.

3.1 Select model

The Select (selection) model is the most common I/O model in Winsock. It is called the "select Model" because its "central idea" is to use the Select function to achieve the management of I/O. With the Select function, we determine whether there is data on the socket, or whether the data can be written to a socket.

The function prototypes for select are as follows:

The first parameter is often ignored, and the other three fd_set parameters are,

One for checking readability (Readfds), one for checking for writable (WRITEFDS), and the other for exception data (EXCEPFDS).

Where the Readfds collection includes sockets that meet any one of the following conditions:
There is data to read in.
The connection has been closed, re-erected, or aborted.
If l i s t e N is called and a connection is being established, a C c e p t function call succeeds.
The Writefds collection includes sockets that meet any one of the following conditions:
There is data to be sent.
If the processing of a non-locking connection call has been completed, the connection succeeds.
The Excepfds collection includes sockets that meet any one of the following conditions:
If the processing of a non-locking connection call has been completed, the connection attempt fails.
There is out-of-band (OOB) data available for reading.

The last parameter, timeout, corresponds to a pointer that points to a timeval structure that determines how long the select waits for the I/O operation to finish.

At the same time, Winsock provides the following macro operations for processing and checking fd_set:

3.2 Asynchronous selection

Winsock provides a useful asynchronous I/O model. With this model, the application can receive network event notifications based on Windows messages on a socket. The specific practice is to call the WSAAsyncSelect function after the good one socket is under construction. The model, which first appeared in the 1.1 version of Winsock, was designed to help application developers face some of the earlier 16-bit Windows platforms, such as Windows for Workgroups, to adapt to their "backward" multitasking messaging environment. Applications can still benefit from this model, especially when they are managed with a standard Windows routine (often referred to as "WndProc") for window messages. The model has also been adopted by Microsoft Foundation Class (Microsoft Basic class, MFC) object CSocket. (Excerpt from the eighth chapter of Windows networking Programming).

In my opinion, WSAAsyncSelect is the simplest kind of Winsock I/O model (it is simply because a main thread is done). Anyone who has written a window class application using the raw Windows API should be able to read it. Here, what we need to do is simply:
1. In the WM_CREATE message handler function, initialize the Windows Socket Library, create a listening socket, bind, listen, and call the WSAAsyncSelect function to indicate that we care about the Fd_accept event that occurs on the listener socket;
2. Customize a message Wm_socket, once an event occurs on the socket (listening sockets and client sockets) We care about, the system calls WndProc and the message parameter is set to Wm_socket;
3. In the message processing function of Wm_socket, the fd_accept, Fd_read and Fd_close events are processed respectively;
4. In the processing function of the window destruction message (WM_DESTROY), we close the listening socket and clear the Windows Socket Library

The following Network Event Type table for the WSAAsyncSelect function gives you a clearer idea of the various network events:

3.3 Event Selection

Winsock provides another useful asynchronous I/O model. Similar to the WSAAsyncSelect model, it also allows applications to receive event-based network event notifications on one or more sockets. For the network events summarized in table 1, which are used by the WSAAsyncSelect model, they can be migrated intact to the new model. In applications developed with the new model, it is also possible to receive and process all those events. The main difference between this model is that network events are delivered to an event object handle, not to a window routine. (Excerpt from the eighth chapter of Windows network Programming)
Let's start by looking at the code and then analyzing it:

The event selection model is also relatively simple and not too complex to implement, and its basic idea is to match each socket to a Wsaevent object and specify which network events to focus on when associating. Once the events (Fd_read and Fd_close) that we are concerned about occur on a socket, the Wsaevent object associated with it is signaled. The program defines two global arrays, a socket group, an array of Wsaevent objects, whose size is maximum_wait_objects (64), and two elements in the array correspond to one by one.
Similarly, the program here does not consider two issues, one is not unconditional call accept, because we support a limited number of concurrent connections. The workaround is to group the sockets by Maximum_wait_objects, each maximum_wait_objects a set of sockets, each assigned a worker thread, or wsaaccept instead of accept. and callback the condition Function that you defined. The second problem is that there is no special treatment for the number of connections 0, and the program has a CPU occupancy rate of 100% when the number of connections is 0. 3.4 Overlapped I/O model

The release of WINSOCK2 allows the socket I/O to have a unified interface with file I/O. We can do socket I/O by using Win32 file manipulation functions ReadFile and WriteFile. As a companion, the overlapped I/O model for common file I/O and the completion port model also apply to socket I/O. The advantages of these models are that they can achieve better system performance, but the implementation is more complex, involving more C language skills. For example, we often use the so-called "trailing data" in the completion port model. 1. Overlapped I/O model implemented with event notification mode

The

This model differs from the other models above in that it uses the asynchronous I/O function WSARecv provided by Winsock2. When calling WSARecv, specify a wsaoverlapped structure, which is not blocked, that is, it returns immediately. Once the data arrives, the hevent in the specified wsaoverlapped structure is signaled. Because the following statement
G_clieventarr[g_itotalconn] = g_pperiodataarr[g_itotalconn]->overlap.hevent;
Causes the Wsaevent object associated with the socket to be signaled, so the wsawaitformultipleevents call operation returns successfully. What we should do now is to call WSAGetOverlappedResult with the same wsaoverlapped structure as the call WSARecv, so that I can get the relevant information such as the number of bytes I am transmitting. After obtaining the received data, send the data intact to the client and then reactivate a WSARECV asynchronous operation. 2. Overlapped I/O model implemented using the completion routine method

Using completion routines to implement overlapped I/O is much simpler than event notification. In this model, the main thread only uses the constant acceptance of the connection; The worker thread determines whether a new client connection is established, if any, activates an asynchronous WSARECV operation for that client socket, and then calls SleepEx to put the thread in a warning wait state so that the i/ o After completion completionroutine can be called by the kernel. If the worker thread does not call SleepEx, the kernel cannot invoke the completion routine after the I/O operation is completed (because the completion routine should be running the same thread as the code that activated the WSARecv asynchronous operation). The implementation code in the
completion routine is simple, it takes out the received data, then sends the data intact to the client, and finally activates another WSARECV asynchronous operation. Note that "trailing data" is used here. When we call WSARecv, the parameter lpoverlapped actually points to a much larger structure per_io_operation_data, which, besides wsaoverlapped, is appended with the structure information of the buffer, It also includes important information such as client sockets. Thus, in the completion routine through the parameter lpoverlapped get not only the wsaoverlapped structure, there is a trailing behind the client socket and receive data buffer and other important information. This kind of C language technique is also used when I introduce the completion port later in this article. 3.5. Complete the Port model

The

   finish port model is by far the most complex I/O model. However, if an application needs to manage a large number of sockets at the same time, the best system performance can often be achieved by using this model! Unfortunately, the model is only available for Windows NT and Windows 2000 operating systems. Because of the complexity of the design, you should consider using the "completion port" model only if your application needs to manage hundreds of or even thousands of sockets at the same time, and you want the performance of your application to increase linearly as the number of CPUs installed in the system increases. One basic guideline to keep in mind is that if you are developing high-performance server applications for Windows NT or Windows 2000 and want to serve a large number of socket I/O requests (Web servers are a typical example of this), the I/O completion port model is the best choice! (Excerpt from the eighth chapter of Windows network Programming) The
Complete port model is my favorite model. Although its implementation is more complex (in fact, I think its implementation is much simpler than the overlapped I/O implemented with event notification), but its efficiency is amazing. When I was in T company, I helped colleagues write a performance test program for a mail server, with the completion port model. The results show that the completion port model can achieve very high throughput in the case of multiple connections (tens of thousands), relying on only one or two worker threads. I'll start with the code:

First, talk about the main thread:
1. Create a completion Port object
2. Create worker threads (the number of worker threads here is determined by the number of CPUs, so that the best performance can be achieved)
3. Create a listener socket, bind, listen, and then program into the loop
4. In the loop, I've done several things:
(1). Accept a Client connection
(2). Bind the client socket to the completion port (or call CreateIoCompletionPort, but this time), note that the third argument passed to CreateIoCompletionPort at this point should be a completion key , generally speaking, the program is to pass a simple handle data structure of the address, the simple handle of the database contains information related to the client connection, because we only care about socket handle, so the socket handle as the completion key transfer;
(3). Trigger a WSARecv asynchronous call, this time using "trailing data", so that the buffer used to receive data immediately after the Wsaoverlapped object, in addition to the type of operation and other important information.
In the cycle of worker threads, we
1. Call GetQueuedCompletionStatus to obtain information about this I/O (such as socket handles, bytes transferred, addresses of single I/O data structures, etc.)
2. Find the receive data buffer through a single I/O data structure and send the data intact to the client
3. Triggering a WSARecv asynchronous operation again four. Comparison of five I/O models

I'll compare them in the following ways.
* There is no limit of 64 connections per thread

If you do not redefine the FD_SETSIZE macro in the selection model, you can install 64 sockets per Fd_set by default. Similarly, by the Maximum_wait_objects macro, event selection, overlapped I/O implemented with event notification, has a maximum of 64 connections per thread limit. If the number of connections is thousands, you must group the client sockets so that the complexity of the program is increased.
In contrast, asynchronous selection, overlapping I/O and completion ports implemented with completion routines are not restricted. * Number of threads

In addition to asynchronous selection, other models require at least 2 threads. A main thread and a worker. Similarly, if the number of connections is greater than 64, the number of threads that select the model, event selection, and overlapped I/O implemented with event notifications also increases. * The complexity of implementation

My personal view is that on the difficulty of implementation, asynchronous selection < selection < overlap i/o< Event selection with completion routines < completion port < overlapped I/O performance with event notification

Since the selection model has to reset the read set every time, after the Select function returns to all sockets for each test, I feel that the efficiency is poor; the completion port and the overlapped I/O implemented with the completion routine basically do not involve global data, the efficiency should be the highest, And in the multi-processor case, the completion of the port is higher; event selection and overlapped I/O implemented with event notification are wsawaitformultipleevents in the implementation mechanism, and the sense of efficiency is similar; As for asynchronous selection, it is not good to compare.

So my conclusion is: SELECT < overlap i/o< events with Event notification implementation < Overlapping i/o< completion ports implemented with completion routines

Resources:

1.http://blog.csdn.net/yadong728/article/details/42153579

2. "Windows" Network programming technology

Windows IO methods