See an example of IOCP on CodeProject online http://www.codeproject.com/KB/IP/iocp_server_client.aspx
In the solution to the WSAENOBUFS problem, use a wsarecv that uses 0 buffers to unlock
Author Web page translation: Wsaenobufs The problem is often difficult to find by intuition, because when you first see it you may think it is a memory leak error. Assuming that you have developed your completion port server and that it is running well, but when you stress test it suddenly found that the server was aborted without processing any requests, if you are lucky you will soon find that because of the wsaenobufs error and affect all this. whenever we overlap to commit a send or receive operation, the specified sending or receiving buffer is locked. When a memory buffer is locked, it cannot be paged from physical memory. The operating system has a limit of the maximum number of locks, and once the lock limit is exceeded, a wsaenobufs error is generated. If a server submits a very many overlapping receive on each connection, the limit will change as the number of connections increases. If a server can pre-estimate the maximum number of concurrent connections that may occur, the server can post a receive with 0 buffers on each connection. Because when you commit an operation without a buffer, there is no memory locked. With this approach, when your receive operation event finishes returning, the data for the socket's underlying buffer will remain intact and not read into the buffer of the receive operation. At this point, the server can simply call the non-blocking recv will be present in the socket buffer to read all the data, until recv back to WSAEWOULDBLOCK . This design is ideal for servers that can sacrifice data throughput for huge concurrent connections. Of course, you also need to be aware of how to make the client's behavior as much as possible to avoid impacting the server. In the previous example, when the receive operation of a 0 buffer is returned, uses a non-blocking recv to read the data in the socket buffer, if the server can now anticipate that there will be an outbreak of data flow, then consider posting one or more receive at this time to replace non-blocking recv for data reception. (This is much better than using 1 default 8K buffers to receive them.) Source provides a simple and practical solution to wsaenobuf errors. We performed a 0-byte buffered asynchronous Wsaread (...) (see onzerobyteread (..)). When this request is complete, we know that there is data in the TCP/IP stack, and then we execute several asynchronous Wsaread (...) with maximumpackagesize buffering. To read and solve the WsaenObufs problem. However, this workaround reduces the throughput of the server.
Summarize:
Workaround One:
A receive operation with an empty buffer is posted, and when the operation returns, a non-blocking recv is used to read the real data. Therefore, in each connection to the completion port, a cyclic operation is required to continuously commit the receive operation of the empty buffer. Workaround Two:
After a few receive operations that normally contain buffers are posted, the receive operation is then started to cycle through an empty buffer. This ensures that they are returned in order of delivery, so that we can always unlock the locked memory. The problem is: in the OnInitialize method triggered by the customer's connection, the author delivers azerobyteread (pcontext,poverlapbuff);//0 buffering WSARecv
and a few aread (PContext)//have length of WSARecv, that 0 bytes of nature is unlocked, but have the length of the unlocked it? How to solve if unlocked!
Who is the expert to answer!
Solutions»
About Zero byte WSARecv (), specifically see for yourself <<network programming for Microsoft Windows>>, see the applicable environment and conditions, etc., do not hearsay.
It is best to post only one wsarecv at a time, otherwise there will be many problems, such as packet chaos.
Know the reason, the upstairs is not correct, send a WSARECV using 0 buffer to unlock, so about the socket cache all unlocked
