Why would an Overlapped call to recv return ERROR_NO_MORE_ITEMS(259)?

I did a few tests with an I/O-Completion port and winsock sockets. I encountered, that sometimes after I received data from a connection and then adjacently call WSARecv again on that socket it returns immediately with the error 259 (ERROR_NO_MORE_ITEMS).

I am wondering why the system flags the overlapped transaction with this error instead of keeping the recv call blocking/waiting for incoming data.

Do You know what´s the sense of this ?

I would be glad to hear about your thoughts.

Edit: Code

do
    {
        OVERLAPPED* pOverlapped = nullptr;
        DWORD dwBytes = 0; ULONG_PTR ulKey = 0;

        //Dequeue a completion packet
        if(!m_pIOCP->GetCompletionStatus(&dwBytes, &ulKey, &pOverlapped, INFINITE))
            DebugBreak();

        //Evaluate
        switch(((MYOVERLAPPED*)pOverlapped)->WorkType)
        {
        case ACCEPT_OVERLAPPED_TYPE:
            {
                //cast
                ACCEPT_OVERLAPPED* pAccept = (ACCEPT_OVERLAPPED*)pOverlapped;

                //Associate the newly accepted connection with the IOCP
                if(!m_pIOCP->AssociateHandle((HANDLE)(pAccept->pSockClient)->operator SOCKET(), 1))
                {
                    //Association failed: close the socket and and delte the overlapped strucuture

                }

                //Call recv
                RECV_OVERLAPPED* pRecvAction = new RECV_OVERLAPPED;
                pRecvAction->pSockClient = pAccept->pSockClient;
                short s = (pRecvAction->pSockClient)->Recv(pRecvAction->strBuf, pRecvAction->pWSABuf, 10, pRecvAction);
                if(s == Inc::REMOTECONNECTION_CLOSED)
                {
                    //Error stuff
                }


                //Call accept again (create a new ACCEPT_OVERLAPPED to ensure overlapped being zeroed out)
                ACCEPT_OVERLAPPED *pNewAccept = new ACCEPT_OVERLAPPED;
                pNewAccept->pSockListen = pAccept->pSockListen;
                pNewAccept->pSockClient = new Inc::CSocket((pNewAccept->pSockListen)->Accept(nullptr, nullptr, pNewAccept));

                //delete the old overlapped struct
                delete pAccept;
            }
            break;
        case RECV_OVERLAPPED_TYPE:
            {
                RECV_OVERLAPPED* pOldRecvAction = (RECV_OVERLAPPED*)pOverlapped;
                if(!pOldRecvAction->InternalHigh)
                {
                    //Connection has been closed: delete the socket(implicitly closes the socket)
                    Inc::CSocket::freewsabuf(pOldRecvAction->pWSABuf);      //free the wsabuf
                    delete pOldRecvAction->pSockClient;
                }
                else
                {
                    //Call recv again (create a new RECV_OVERLAPPED)
                    RECV_OVERLAPPED* pNewRecvAction = new开发者_Python百科 RECV_OVERLAPPED;
                    pNewRecvAction->pSockClient = pOldRecvAction->pSockClient;
                    short sRet2 = (pNewRecvAction->pSockClient)->Recv(pNewRecvAction->strBuf, pNewRecvAction->pWSABuf, 10, pNewRecvAction);



                    //Free the old wsabuf
                    Inc::CSocket::freewsabuf(pOldRecvAction->pWSABuf);
                    delete pOldRecvAction;

                }

Cutted error checkings...

The Recv-member-function is a simple wrapper around the WSARecv-call which creates the WSABUF and the receiving buffer itself (which needs to be cleaned up by the user via freewsabuf - just to mention)...

---

It looks like I was sending less data than was requested by the receiving side. But since it´s an overlapped operation receiving a small junk of the requested bunch via the TCP-connection would trigger the completion indication with the error ERROR_NO_MORE_ITEMS, meaning there was nothing more to recv than what it already had.