Socket errors in IOCP and resource release processing methods

The author of this article: Sodme
Source of this article: Http://blog.csdn.net/sodme
Disclaimer: This article can be reproduced without the consent of the author, copy, dissemination, but any reference to this article must retain the author, source and the statement of the bank information. Thank you.

Objective:
Error handling and socket release is a major difficulty in IOCP programming. This paper attempts to discuss and find the solution to this difficult problem which is often encountered in IOCP design, in fact, the solution described in this paper not only applies to IOCP, but also applies to the network model of Epoll and other server programming, and the prerequisite is: to comprehend the essence of this kind of processing method.

Body:
One of the challenges that you often encounter when using IOCP development is the error associated with socket-related buffer releases, which is usually caused by a delete operation on the same pointer multiple times. For example, when performing wsasend or WSARecv returns a pending error message, we are going to handle this error, and usually we think of doing both:
A. Release buffer data used by this operation (if not released may cause memory leaks);
B. Closes the socket used by the current operation.
On the other hand, we might also do the same thing with the Get function (GetQueuedCompletionStatus), when the Get function returns a value of false. In this case, the problem arises when the same buffer is repeatedly released.

There are several ways to solve these problems:
1. Use reference counting mechanism for data buffer;
2. The release operation is linearized on the Clientsock object design mechanism.
Regarding these two methods, any kind if wants to elaborate clearly, perhaps the length will be longer, the author does not have the patience and the energy to each each detail one way, this only chooses the 2nd kind of plan the key step and the core idea to share with everybody.

As you can see from the previous description of the problem, the reason for multiple releases might be that we repeated the release operation while performing the send and receive operations and the return value of the Get function was false.  Naturally, we would have thought, would it be okay to combine these two releases into one release?  Yes, there is no problem with this idea. But to make this idea can become a reality, it needs to be in the design mechanism of this idea to support certain.

First, we assume that the corresponding release and shutdown operations are uniformly performed when the Get function returns.

If a non-pending error occurred while performing the wsasend operation (IO operation in progress), and if we do not release the resource, at least let IOCP know the error and the buffer pointer when the error occurs when the get returns. The way to notify IOCP is to use the Post function (PostQueuedCompletionStatus) to throw a message to the IOCP with a special flag that can be represented by the second argument of the Get function, that is, the number of bytes transmitted.  You can select any value that cannot be found, such as any negative number that is not equal to its initial value. Of course, it's OK if you pass simple handle data or single IO data. The buffer pointer that is wrong, we have to pass the simple handle data or single IO data. However, from the entire buffer management mechanism, I do not recommend such a discrete buffer mechanism, my suggestion is: send and receive buffers or data queues with the corresponding Clientsocket object binding, the release of the operation is written in the object's destructor, This frees the buffers when the Clientsocket object is released.

OK, so there are three situations in the GET function that need to perform the release logic:
1. The return value of Get is false;
2. Transmit byte number is 0;
3. Received the error type message that we post just now.

After all the release operations are placed in the Get function, the handling of the release operation is more uniform. Of course, in order to achieve true linearization and metaprogramming, the final execution logic of the release operation also requires locking the release code to achieve a thread mutex (of course, if you have multiple worker threads open).