WSARecv

This function receives data from a connected socket.

int WSARecv(
  SOCKET s,
  LPWSABUF lpBuffers,
  DWORD dwBufferCount,
  LPDWORD lpNumberOfBytesRecvd,
  LPDWORD lpFlags,
  LPWSAOVERLAPPED lpOverlapped,
  LPWSAOVERLAPPED_COMPLETION_ROUTINE lpCompletionRoutine
);

Parameters

• s
  [in] Descriptor identifying a connected socket.
• lpBuffers
  [in, out] Pointer to an array of WSABUF structures. Each WSABUF structure contains a pointer to a buffer and the length of the buffer.
• dwBufferCount
  [in] Number of WSABUF structures in the lpBuffers array.
• lpNumberOfBytesRecvd
  [out] Pointer to the number of bytes received by this call if the receive operation completes immediately.
• lpFlags
  [in, out] Pointer to flags.
• lpOverlapped
  [in] Pointer to a WSAOVERLAPPED structure (ignored for nonoverlapped sockets).
• lpCompletionRoutine
  [in] Pointer to the completion routine called when the receive operation has been completed (ignored for nonoverlapped sockets).

Return Values

If no error occurs and the receive operation has completed immediately, this function returns zero. In this case, the completion routine will have already been scheduled to be called once the calling thread is in the alertable state. If an error occurs, a value of SOCKET_ERROR is returned, and a specific error code can be retrieved by calling the WSAGetLastError function. 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 the overlapped operation was not successfully initiated and no completion indication will occur.

The following table shows a list of possible error codes.

Remarks

This function provides functionality over and above the standard recv function in the following three important areas:

• It can be used in conjunction with overlapped sockets to perform overlapped receive operations.
• It allows multiple receive buffers to be specified, enabling a scatter/gather type of I/O.
• The lpFlags parameter is both an input and output parameter, allowing applications to sense the output state of the MSG_PARTIAL flag bit. However, the MSG_PARTIAL flag bit is not supported by all protocols.

This function 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. For server applications, this is usually done explicitly through bind (Windows Sockets) or implicitly through the accept (Windows Sockets) or WSAAccept function. Explicit binding is discouraged for client applications. For client applications, the socket can become bound implicitly to a local address through the connect (Windows Sockets), WSAConnect, or sendto, WSASendTo function.

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, WSARecv is used to post one or more buffers into which incoming data will be placed as it becomes available, after which the application-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 the WSAGetOverlappedResult function.

If both lpOverlapped and lpCompletionRoutine are NULL, the socket in this function will be treated as a nonoverlapped socket.

For nonoverlapped sockets, the blocking semantics are identical to that of the standard recv function and the lpOverlapped and lpCompletionRoutine parameters are ignored. Any data that has already been received and buffered by the transport will be copied into the supplied user buffers. In 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. Winsock does not define any standard blocking time-out 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 the 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 following table summarizes the relevant combinations, (an asterisk (*) indicates that the setting of this bit does not matter in this case).

The supplied buffers are completed 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 these WSABUF structures before returning from this call. This enables applications 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 the internally buffered data is exhausted. Regardless of whether 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 underlying service provider, the MSG_PARTIAL flag is set in lpFlags and subsequent receive operations will retrieve the rest of the message. If MSG_PARTIAL is not supported but the protocol is reliable, WSARecv 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 WSARecv generates the error WSAEMSGSIZE.

For connection-oriented sockets, WSARecv can indicate the graceful termination of the virtual circuit in one of two ways that depend on whether the socket is byte stream or message-oriented. For byte streams, zero bytes having been read (as indicated by a zero return value to indicate success, and an lpNumberOfBytesRecvd value of zero) 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 failure with an 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 following table shows the values used with the bitwise OR operator to construct the lpFlags parameter.

The MSG_PARTIAL flag is not supported by the default Windows CE .NET provider. For message-oriented sockets, the MSG_PARTIAL bit is set in the lpFlags parameter if a partial message is received. If a complete message is received, MSG_PARTIAL is cleared in lpFlags. In the case of delayed completion, the value pointed to by lpFlags is not updated. When completion has been indicated, the application should call WSAGetOverlappedResult and examine the flags indicated by the lpdwFlags parameter.

Overlapped Socket I/O

**Note   **For Windows CE, avoid specifying completion routines for overlapped I/O operations. Because Windows CE does not support asynchronous procedure calls (APCs), which occur in the calling thread, the OS has to spin a thread for each call that specifies a completion routine. With one thread create per function call, using completion routines with overlapped I/O can quickly become very memory-consuming. Using events is recommended instead.

If an overlapped operation completes immediately, WSARecv returns a value of zero and the lpNumberOfBytesRecvd parameter is updated with the number of bytes received and the flag bits indicated by the lpFlags parameter are also updated. If the overlapped operation is successfully initiated and will complete later, WSARecv 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 WSAGetOverlappedResult. Flag values are obtained by examining the lpdwFlags parameter of WSAGetOverlappedResult.

The WSARecv function can be called from within the completion routine of a previous WSARecv, WSARecvFrom, WSASend, or WSASendTo function. For a given socket, I/O completion routines will not be nested. This permits time-sensitive data transmissions to occur entirely within a pre-emptive 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 WSAOVERLAPPED structure.

If the lpCompletionRoutine parameter is NULL, the hEvent parameter of lpOverlapped is signaled when the overlapped operation completes if it contains a valid event object handle. An application can use the WSAGetOverlappedResult function to wait or poll on the event object.

If lpCompletionRoutine is not NULL, the hEvent parameter is ignored and can be used by the application to pass context information to the completion routine. A caller that passes a non-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 parameter is undefined and attempting to wait on the hEvent parameter would produce unpredictable results.

The transport providers allow an application to invoke send and receive operations from within the context of the socket I/O completion routine and guarantee that for a given socket, I/O completion routines will not be nested. This permits time-sensitive data transmissions to occur entirely within a pre-emptive context.

The following syntax shows the prototype of the completion routine.

void CALLBACK CompletionRoutine(
  IN DWORD dwError, 
  IN DWORD cbTransferred, 
  IN LPWSAOVERLAPPED lpOverlapped, 
  IN DWORD dwFlags
);

CompletionRoutine is a placeholder for an application-defined or library-defined function name. The dwError parameter specifies the completion status for the overlapped operation as indicated by lpOverlapped. The cbTransferred parameter specifies the number of bytes received. The dwFlags parameter contains information that would have appeared in lpFlags if the receive operation had completed immediately. This function does not return a value.

Returning from this function allows invocation of another pending completion routine for this socket.

Requirements

OS Versions: Windows CE .NET 4.0 and later.
Header: Winsock2.h.
Link Library: Ws2.lib.

 Last updated on Saturday, April 10, 2004

© 1992-2003 Microsoft Corporation. All rights reserved.