Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    text
    copied!<p>I"ve been working with <code>AcceptEx</code> and IOCP, and I never-ever saw such a problem.</p> <p>About your code. It's hard to say what's wrong exactly in it, since it's not complete. But I'm pretty sure the problem is there.</p> <p>One problem that I see is that the 3rd parameter you supply to <code>AcceptEx</code> is a <strong>local</strong> buffer. This is wrong, because this buffer should remain valid for the duration of the accept operation. What you did may easily lead to the stack memory corruption of whatever.</p> <p>But your "spurious accept" problem is probably caused by something else. And I suspect that I know what's the problem. Let me guess:</p> <ol> <li>You use the same IOCP for both listening and accepted (client) socket. This is reasonable, there's no need to have more than 1 IOCP.</li> <li>When you dequeue a completion from the IOCP - you automatically cast it to <code>WORK_ACCEPT</code> and call <code>HandleAcceptedConnection</code>. Don't you?</li> </ol> <p>If so - the problem is obvious. You call the <code>WSARecv</code> on the client socket. It completes, and the completion is queued the the IOCP. You fetch it, however you treat it as a completed accept. You cast it to <code>WORK_ACCEPT</code>, which looks junky (simply becase it is <strong>not</strong> a <code>WORK_ACCEPT</code> structure).</p> <p>If this is the case - you <strong>must</strong> add a way to distinguish different completion types. For instance you may declare a base struct (from which all the completions would inherit), which would have a type member, which will identify the completion type.</p>
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload