Winsock Event Select Model

[Richard Andrew x64]

My question is: How long must my WSABUF buffers remain valid after calling WSASend while using the WSAEventSelect model? Background:

Quote:

An FD_WRITE network event is recorded when a socket is first connected with a call to the connect, ConnectEx, WSAConnect, WSAConnectByList, or WSAConnectByName function or when a socket is accepted with accept, AcceptEx, or WSAAccept function and then after a send fails with WSAEWOULDBLOCK and buffer space becomes available.

So this means that I can call WSASend successfully until it returns WSAEWOULDBLOCK. But how do I know determinitively when it's OK to delete the buffers that I used in the calls to WSASend?

The difficult we do right away... ...the impossible takes slightly longer.

[jeron1]

MSDN:

The FD_WRITE event is handled slightly differently. An FD_WRITE message is posted when a socket is first connected with connect or WSAConnect (after FD_CONNECT, if also registered) or accepted with accept or WSAAccept, and then after a send operation fails with WSAEWOULDBLOCK and buffer space becomes available. Therefore, an application can assume that sends are possible starting from the first FD_WRITE message and lasting until a send returns WSAEWOULDBLOCK. After such a failure the application will be notified that sends are again possible with an FD_WRITE message.

From this (the last sentence specifically), I'm guessing that you're good to go the upon receipt of the first FD_WRITE after receiving WSAEWOULDBLOCK.

"the debugger doesn't tell me anything because this code compiles just fine" - random QA comment "Facebook is where you tell lies to your friends. Twitter is where you tell the truth to strangers." - chriselst

[Richard Andrew x64]

That's what I thought at first, too. But upon further examination, one learns that if you don't send enough data to trigger a WSAEWOULDBLOCK response, then you never receive another FD_WRITE notification! In other words, the FD_WRITE event is recorded upon connect, and then only if you receive a WSAEWOULDBLOCK. That's why I think this is so vague. Thanks for your response.

The difficult we do right away... ...the impossible takes slightly longer.

[Lost User]

Hi, The array of WSABUF[] structures pointed to by the lpBuffers parameter is transient data. You can even use build stack-based WSABUF[] arrays. If WSASend() returns successfully then the underlying transport has made a copy of your buffer. Best Wishes, -David Delaune

[jeron1]

Something this basic should really be documented, lord knows I couldn't find anything (which is not to say that it doesn't exist) that decribes this. I did find some wording on this[^] non-MSDN page, which talks about what happens to your buffer in reponse to a Send() call. No, it's not from the horses mouth, but it does make sense, at least to me.

Quote:

When an application makes a send call, if there is sufficient buffer space, the data is copied into the socket's send buffers, the call completes immediately with success, and the completion is posted. On the other hand, if the socket's send buffer is full, then the application's send buffer is locked and the send call fails with WSA_IO_PENDING. After the data in the send buffer is processed (for example, handed down to TCP for processing), then Winsock will process the locked buffer directly. That is, the data is handed directly to TCP from the application's buffer and the socket's send buffer is completely bypassed.

Hope it helps.

"the debugger doesn't tell me anything because this code compiles just fine" - random QA comment "Facebook is where you tell lies to your friends. Twitter is where you tell the truth to strangers." - chriselst

[Richard Andrew x64]

I would hope that's the case, but what about what it says in the documentation for the LPWSABUF parameter in WSASend:

Quote:

For a Winsock application, once the WSASend function is called, the system owns these buffers and the application may not access them. This array must remain valid for the duration of the send operation.

See? It says they must remain valid throughout the send "operation." Not just the function call, but the entire send operation which may take a long time depending upon network conditions. Is that how you interpret this? Thanks for your expertise.

The difficult we do right away... ...the impossible takes slightly longer.

[Richard Andrew x64]

Thank you, that does help. :-)

The difficult we do right away... ...the impossible takes slightly longer.

[Lost User]

Hi,

For a Winsock application, once the WSASend function is called, the system owns these buffers and the application may not access them. This array must remain valid for the duration of the send operation.

What this is saying is that your buffer must remain valid for the duration of the the WSASend() call. Once the function has returned successfully you may delete the buffers. Best Wishes, -David Delaune P.S. You have mail.

[Richard Andrew x64]

Thank you, thank you! :-D

The difficult we do right away... ...the impossible takes slightly longer.