LPWSPRECV callback function (ws2spi.h)
The LPWSPRecv function receives data on a socket.
Syntax
LPWSPRECV Lpwsprecv;
int Lpwsprecv(
[in] SOCKET s,
\[in\, out\] LPWSABUF lpBuffers,
[in] DWORD dwBufferCount,
[out] LPDWORD lpNumberOfBytesRecvd,
\[in\, out\] LPDWORD lpFlags,
[in] LPWSAOVERLAPPED lpOverlapped,
[in] LPWSAOVERLAPPED_COMPLETION_ROUTINE lpCompletionRoutine,
[in] LPWSATHREADID lpThreadId,
[out] LPINT lpErrno
)
{...}
Parameters
[in] s
A descriptor identifying a connected socket.
\\[in\\, out\\] lpBuffers
A pointer to an array of WSABUF structures. Each WSABUF structure contains a pointer to a buffer and the length of the buffer, in bytes.
[in] dwBufferCount
The number of WSABUF structures in the lpBuffers array.
[out] lpNumberOfBytesRecvd
A pointer to the number of bytes received by this call.
\\[in\\, out\\] lpFlags
A pointer to flags that specify the way in which the call is made.
[in] lpOverlapped
A pointer to a WSAOverlapped structure (ignored for nonoverlapped structures).
[in] lpCompletionRoutine
Type: _In_opt_ LPWSAOVERLAPPED_COMPLETION_ROUTINE
A pointer to the completion routine called when the receive operation has been completed (ignored for nonoverlapped structures).
[in] lpThreadId
A pointer to a WSATHREADID structure to be used by the provider in a subsequent call to WPUQueueApc. The provider should store the referenced WSATHREADID structure (not the pointer to same) until after the WPUQueueApc function returns.
[out] lpErrno
A pointer to the error code.
Return value
If no error occurs and the receive operation has completed immediately, LPWSPRecv returns zero. Note that in this case the completion routine, if specified, will have already been queued. Otherwise, a value of SOCKET_ERROR is returned, and a specific error code is available in lpErrno. The error code WSA_IO_PENDING indicates that the overlapped operation has been successfully initiated and that completion will be indicated at a later time. Any other error code indicates that no overlapped operations was initiated and no completion indication will occur.
| Error Code | Meaning |
|---|---|
| The network subsystem has failed. | |
| Socket is not connected. | |
| (Blocking) call was canceled through LPWSPCancelBlockingCall. | |
| Blocking Windows Sockets call is in progress, or the service provider is still processing a callback function. | |
| The connection has been broken due to keep-alive activity detecting a failure while the operation was in progress. | |
| The lpBuffers parameter is not totally contained in a valid part of the user address space. | |
| The descriptor is not a socket. | |
| MSG_OOB was specified, but the socket is not stream-style such as type SOCK_STREAM, OOB data is not supported in the communication domain associated with this socket, or the socket is unidirectional and supports only send operations. | |
| Socket has been shut down; it is not possible to receive through LPWSPRecv on a socket after LPWSPShutdown has been invoked with how set to SD_RECEIVE or SD_BOTH. | |
| Windows NT: Overlapped sockets: there are too many outstanding overlapped I/O requests. Nonoverlapped sockets: The socket is marked as nonblocking and the receive operation cannot be completed immediately. | |
| Message was too large to fit into the specified buffer and (for unreliable protocols only) any trailing portion of the message that did not fit into the buffer has been discarded. | |
| Socket has not been bound (for example, with LPWSPBind) or the socket is not created with the overlapped flag. | |
| Virtual circuit was terminated due to a time-out or other failure. | |
| Virtual circuit was reset by the remote side. | |
| Socket s is message oriented and the virtual circuit was gracefully closed by the remote side. | |
| An overlapped operation was successfully initiated and completion will be indicated at a later time. | |
| Overlapped operation has been canceled due to the closure of the socket. |
Remarks
LPWSPRecv is used on connected sockets or bound connectionless sockets specified by the s parameter and is used to read incoming data. The socket's local address must be known. This may be done explicitly through LPWSPBind or implicitly through LPWSPAccept, LPWSPConnect, LPWSPSendTo, or LPWSPJoinLeaf.
For connected, connectionless sockets, this function restricts the addresses from which received messages are accepted. The function only returns messages from the remote address specified in the connection. Messages from other addresses are (silently) discarded.
For overlapped sockets LPWSPRecv is used to post one or more buffers into which incoming data will be placed as it becomes available, after which the Windows Sockets SPI client-specified completion indication (invocation of the completion routine or setting of an event object) occurs. If the operation does not complete immediately, the final completion status is retrieved through the completion routine or LPWSPGetOverlappedResult.
If both lpOverlapped and lpCompletionRoutine are null, the socket in this function will be treated as a nonoverlapped socket.
For nonoverlapped sockets, the lpOverlapped, lpCompletionRoutine, and lpThreadId parameters are ignored. Any data that has already been received and buffered by the transport will be copied into the supplied user buffers. For the case of a blocking socket with no data currently having been received and buffered by the transport, the call will block until data is received. Windows Sockets 2 does not define any standard blocking timeout mechanism for this function. For protocols acting as byte-stream protocols the stack tries to return as much data as possible subject to the supplied buffer space and amount of received data available. However, receipt of a single byte is sufficient to unblock the caller. There is no guarantee that more than a single byte will be returned. For protocols acting as message-oriented, a full message is required to unblock the caller.
Whether or not a protocol is acting as byte-stream is determined by the setting of XP1_MESSAGE_ORIENTED and XP1_PSEUDO_STREAM in its WSAPROTOCOL_INFO structure and the setting of the MSG_PARTIAL flag passed in to this function (for protocols that support it). The relevant combinations are summarized in the following table (an asterisk (*) indicates that the setting of this bit does not matter in this case).
| XP1_MESSAGE_ORIENTED | XP1_PSEUDO_STREAM | MSG_PARTIAL | Acts as |
|---|---|---|---|
| not set | * | * | byte stream |
| * | set | * | byte stream |
| set | not set | set | byte stream |
| set | not set | not set | message oriented |
The supplied buffers are filled in the order in which they appear in the array pointed to by lpBuffers, and the buffers are packed so that no holes are created.
The array of WSABUF structures pointed to by the lpBuffers parameter is transient. If this operation completes in an overlapped manner, it is the service provider's responsibility to capture this array of pointers to WSABUF structures before returning from this call. This enables Windows Sockets SPI clients to build stack-based WSABUF arrays.
For byte stream-style sockets (for example, type SOCK_STREAM), incoming data is placed into the buffers until the buffers are filled, the connection is closed, or internally buffered data is exhausted. Regardless of whether or not the incoming data fills all the buffers, the completion indication occurs for overlapped sockets. For message-oriented sockets (for example, type SOCK_DGRAM), an incoming message is placed into the supplied buffers, up to the total size of the buffers supplied, and the completion indication occurs for overlapped sockets. If the message is larger than the buffers supplied, the buffers are filled with the first part of the message. If the MSG_PARTIAL feature is supported by the service provider, the MSG_PARTIAL flag is set in lpFlags and subsequent receive operation(s) can be used to retrieve the rest of the message. If MSG_PARTIAL is not supported but the protocol is reliable, LPWSPRecv generates the error WSAEMSGSIZE and a subsequent receive operation with a larger buffer can be used to retrieve the entire message. Otherwise, (that is, the protocol is unreliable and does not support MSG_PARTIAL), the excess data is lost, and LPWSPRecv generates the error WSAEMSGSIZE.
For connection-oriented sockets, LPWSPRecv can indicate the graceful termination of the virtual circuit in one of two ways, depending on whether the socket is a byte stream or message oriented. For byte streams, zero bytes having been read indicates graceful closure and that no more bytes will ever be read. For message-oriented sockets, where a zero byte message is often allowable, a return error code of WSAEDISCON is used to indicate graceful closure. In any case a return error code of WSAECONNRESET indicates an abortive close has occurred.
The lpFlags parameter can be used to influence the behavior of the function invocation beyond the options specified for the associated socket. That is, the semantics of this function are determined by the socket options and the lpFlags parameter. The latter is constructed by using the bitwise OR operator with any of the following values.
| Value | Meaning |
|---|---|
| MSG_PEEK | Peeks at the incoming data. The data is copied into the buffer but is not removed from the input queue. This flag is valid only for nonoverlapped sockets. |
| MSG_OOB | Processes Out Of Band (OOB) data. |
| MSG_PARTIAL | This flag is for message-oriented sockets only. On output, indicates that the data supplied is a portion of the message transmitted by the sender. Remaining portions of the message will be supplied in subsequent receive operations. A subsequent receive operation with MSG_PARTIAL flag cleared indicates end of sender's message. As an input parameter, MSG_PARTIAL indicates that the receive operation should complete even if only part of a message has been received by the service provider. |
If an overlapped operation completes immediately, LPWSPRecv returns a value of zero and the lpNumberOfBytesRecvd parameter is updated with the number of bytes received and the flag bits pointed by the lpFlags parameter are also updated. If the overlapped operation is successfully initiated and will complete later, LPWSPRecv returns SOCKET_ERROR and indicates error code WSA_IO_PENDING. In this case, lpNumberOfBytesRecvd and lpFlags are not updated. When the overlapped operation completes the amount of data transferred is indicated either through the cbTransferred parameter in the completion routine (if specified), or through the lpcbTransfer parameter in LPWSPGetOverlappedResult. Flag values are obtained either through the dwFlags parameter of the completion routine, or by examining the lpdwFlags parameter of WSAGetOverlappedResult.
Providers must allow this function to be called from within the completion routine of a previous LPWSPRecv, LPWSPRecvFrom, LPWSPSend or LPWSPSendTo function. However, for a given socket, I/O completion routines cannot be nested. This permits time-sensitive data transmissions to occur entirely within a preemptive context.
The lpOverlapped parameter must be valid for the duration of the overlapped operation. If multiple I/O operations are simultaneously outstanding, each must reference a separate overlapped structure. The WSAOverlapped structure is defined in its own reference page.
If the lpCompletionRoutine parameter is null, the service provider signals the hEvent member of lpOverlapped when the overlapped operation completes if it contains a valid event object handle. The Windows Sockets SPI client can use LPWSPGetOverlappedResult to wait or poll on the event object.
If lpCompletionRoutine is not null, the hEvent member is ignored and can be used by the Windows Sockets SPI client to pass context information to the completion routine. A client that passes a null lpCompletionRoutine and later calls WSAGetOverlappedResult for the same overlapped I/O request may not set the fWait parameter for that invocation of WSAGetOverlappedResult to TRUE. In this case the usage of the hEvent member is undefined, and attempting to wait on the hEvent member would produce unpredictable results.
It is the service provider's responsibility to arrange for invocation of the client specified–completion routine when the overlapped operation completes. Since the completion routine must be executed in the context of the same thread that initiated the overlapped operation, it cannot be invoked directly from the service provider. The Ws2_32.dll offers an asynchronous procedure call (APC) mechanism to facilitate invocation of completion routines.
A service provider arranges for a function to be executed in the proper thread and process context by calling WPUQueueApc, which was used to initiate the overlapped operation. This function can be called from any process and thread context, even a context different from the thread and process that was used to initiate the overlapped operation.
WPUQueueApc takes as input parameters a pointer to a WSATHREADID structure (supplied to the provider through the lpThreadId input parameter), a pointer to an APC function to be invoked, and a context value that is subsequently passed to the APC function. Because only a single context value is available, the APC function itself cannot be the client specified–completion routine. The service provider must instead supply a pointer to its own APC function that uses the supplied context value to access the needed result information for the overlapped operation, and then invokes the client specified–completion routine.
The prototype for the client-supplied completion routine is as follows.
void CALLBACK
CompletionRoutine(
IN DWORD dwError,
IN DWORD cbTransferred,
IN LPWSAOVERLAPPED lpOverlapped,
IN DWORD dwFlags
);
The CompletionRoutine parameter is a placeholder for a client-supplied function name. dwError specifies the completion status for the overlapped operation as indicated by lpOverlapped. The cbTransferred parameter specifies the number of bytes received. dwFlags contains information that would have appeared in lpFlags if the receive operation had completed immediately. This function does not return a value.
The completion routines can be called in any order, but not necessarily the same order in which the overlapped operations are completed. However, the posted buffers are guaranteed to be filled in the same order in which they are supplied.
Note
All I/O initiated by a given thread is canceled when that thread exits. For overlapped sockets, pending asynchronous operations can fail if the thread is closed before the operations complete. See ExitThread for more information.
Requirements
| Requirement | Value |
|---|---|
| Minimum supported client | Windows 10 Build 20348 |
| Minimum supported server | Windows 10 Build 20348 |
| Header | ws2spi.h |
See also
Feedback
Coming soon: Throughout 2024 we will be phasing out GitHub Issues as the feedback mechanism for content and replacing it with a new feedback system. For more information see: https://aka.ms/ContentUserFeedback.
Submit and view feedback for