WSAEventSelect

Article
11/18/2015

A version of this page is also available for

4/8/2010

This function specifies an event object to be associated with the supplied set of FD_XXX network events.

Syntax

int WSAEventSelect(
  SOCKET s,
  WSAEVENT hEventObject,
  long lNetworkEvents
);

Parameters

s
[in] Descriptor identifying the socket.

hEventObject
[in] Handle identifying the event object to be associated with the supplied set of FD_XXX network events.

lNetworkEvents
[in] Bitmask that specifies the combination of FD_XXX network events in which the application has interest.

Return Value

The return value is zero if the application's specification of the network events and the associated event object was successful. If an error occurs, the value SOCKET_ERROR is returned, and a specific error number can be retrieved by calling the WSAGetLastError function.

As in the case of the select function, WSAEventSelect will frequently be used to determine when a data transfer operation (send or receive) can be issued with the expectation of immediate success. Nevertheless, a robust application must be prepared for the possibility that the event object is set and it issues a Windows Sockets call that returns WSAEWOULDBLOCK immediately. For example, the following sequence of operations is possible:

Data arrives on socket s; Windows Sockets sets the WSAEventSelect event object.
The application does some other processing.
While processing, the application issues an ioctlsocket and notices that there is data ready to be read.
The application issues a recv to read the data.
The application waits on the event object specified in WSAEventSelect, which returns immediately indicating that data is ready to read.
The application issues recv which fails with the error WSAEWOULDBLOCK.

The occurrence of the network event is recorded, the corresponding bit is set in the internal network event record, and the associated event object is signalled. No further action is taken for the network event until the application makes the function call that implicitly re-enables the setting of the event and signals the associated event object.

Network event	Re-enabling function
FD_READ	recv, recvfrom, WSARecv, or WSARecvFrom.
FD_WRITE	send, sendto, WSASend, or WSASendTo.
FD_OOB	recv, recvfrom, WSARecv, or WSARecvFrom.
FD_ACCEPT	accept (Windows Sockets) or WSAAccept unless the error code returned is WSATRY_AGAIN indicating that the condition function returned CF_DEFER.
FD_CONNECT	None.
FD_CLOSE	None.
FD_ROUTING_ INTERFACE_CHANGE	WSAIoctl with command SIO_ROUTING_INTERFACE_CHANGE.
FD_ADDRESS_ LIST_CHANGE	WSAIoctl with command SIO_ADDRESS_LIST_CHANGE.

Any call to the re-enabling routine, even one that fails, results in re-enabling of recording and signaling for the relevant network event and event object.

For FD_READ, FD_OOB, and FD_ACCEPT network events, network event recording and event object signaling are level-triggered. This means that if the re-enabling routine is called and the relevant network condition is still valid after the call, the network event is recorded and the associated event object is set. This allows an application to be event-driven and not be concerned with the amount of data that arrives at any one time. Consider the following sequence:

A transport provider receives 100 bytes of data on socket s and causes ws2.dll to record the FD_READ network event and set the associated event object.
The application issues recv(s, buffptr, 50, 0) to read 50 bytes.
The transport provider causes ws2.dll to record the FD_READ network event and sets the associated event object again because there is still data to be read.

With these semantics, an application need not read all available data in response to an FD_READ network event — a single recv in response to each FD_READ network event is appropriate.

The FD_ROUTING_INTERFACE_CHANGE and FD_ADDRESS_LIST_CHANGE events are considered edge-triggered as well. A message will be posted exactly once when a change occurs after the application has requested the notification by issuing WSAIoctl with SIO_ROUTING_INTERFACE_CHANGE or SIO_ADDRESS_LIST_CHANGE correspondingly. Other messages will not be forthcoming until the application re-issues the IOCTL and another change is detected since the IOCTL has been issued.

If a network event has already happened when the application calls WSAEventSelect or when the re-enabling function is called, a network event is recorded and the associated event object is set as appropriate. For example, consider the following sequence:

An application calls listen.
A connectrequest is received but not yet accepted.
The application calls WSAEventSelect specifying that it is interested in the FD_ACCEPT network event for the socket. Due to the persistence of network events, Windows Sockets records the FD_ACCEPT network event and sets the associated event object immediately.

The FD_WRITE network event is handled slightly differently. An FD_WRITE network event is recorded when a socket is first connected with connect/WSAConnect or accepted with accept/WSAAccept, and then after a send fails with WSAEWOULDBLOCK and buffer space becomes available. Therefore, an application can assume that sends are possible starting from the first FD_WRITE network event setting and lasting until a send returns WSAEWOULDBLOCK. After such a failure, the application will find out that sends are again possible when an FD_WRITE network event is recorded and the associated event object is set.

The FD_OOB network event is used only when a socket is configured to receive out of band (OOB) data separately. If the socket is configured to receive OOB data inline, the OOB (expedited) data is treated as usual data and the application should register an interest in, and will get an FD_READ network event, not an FD_OOB network event. An application can set or inspect the way in which OOB data is to be handled by using setsockopt (Windows Sockets) or getsockopt (Windows Sockets) for the SO_OOBINLINE option.

The error code in an FD_CLOSE network event indicates whether the socket close was graceful or abortive. If the error code is zero, then the close was graceful; if the error code is WSAECONNRESET, then the socket's virtual circuit was reset. This only applies to connection-oriented sockets such as SOCK_STREAM.

The FD_CLOSE network event is recorded when a close indication is received for the virtual circuit corresponding to the socket. In TCP terms, this means that the FD_CLOSE is recorded when the connection goes into the TIME WAIT or CLOSE WAIT states. This results from the remote end performing a shutdown on the send side or a closesocket. The FD_CLOSE network event is posted after all data is read from a socket. An application should check for remaining data on receipt of FD_CLOSE to avoid any possibility of losing data.

Windows Sockets will record only an FD_CLOSE network event to indicate closure of a virtual circuit. It will not record an FD_READ network event to indicate this condition.

The FD_ROUTING_INTERFACE_CHANGE network event is recorded when the local interface that should be used to reach the destination specified in WSAIoctl with SIO_ROUTING_INTERFACE_CHANGE changes after such IOCTL has been issued.

The FD_ADDRESS_LIST_CHANGE network event is recorded when the list of addresses of the protocol family for the socket to which the application can bind changes after WSAIoctl with SIO_ADDRESS_LIST_CHANGE has been issued.

The following table shows a list of possible error codes.

Error code	Description
WSANOTINITIALISED	A successful WSAStartup call must occur before using this function.
WSAENETDOWN	The network subsystem has failed.
WSAEINVAL	One of the specified parameters was invalid, or the specified socket is in an invalid state.
WSAEINPROGRESS	A blocking Winsock call is in progress, or the service provider is still processing a callback function.
WSAENOTSOCK	The descriptor is not a socket.

Remarks

This function is used to specify an event object, hEventObject, to be associated with the selected FD_XXX network events, lNetworkEvents. The socket for which an event object is specified is identified by the parameter s. The event object is set when any of the nominated network events occur.

This function sets the associated event object and records the occurrence of this event in an internal network event record. An application can use WSAEnumNetworkEvents to retrieve the contents of the internal network event record and thus determine which of the nominated network events have occurred.

WSAEventSelect is the only function that causes network activity and errors to be recorded and retrievable through WSAEnumNetworkEvents. See the description of select to find out how that function reports network activity and errors.

The WSAEventSelect function automatically sets socket s to nonblocking mode, regardless of the value of lNetworkEvents. See ioctlsocket and WSAIoctl for how to set the socket back to blocking mode.

The lNetworkEvents parameter is constructed by using the bitwise OR operator with any of the values specified in the following table.

Value	Description
FD_READ	Wants to receive notification of readiness for reading.
FD_WRITE	Wants to receive notification of readiness for writing.
FD_OOB	Wants to receive notification of the arrival of out of band (OOB) data.
FD_ACCEPT	Wants to receive notification of incoming connections.
FD_CONNECT	Wants to receive notification of a completed connection or multipoint join operation.
FD_CLOSE	Wants to receive notification of a socket closure.
FD_ROUTING_ INTERFACE_CHANGE	Wants to receive notification of routing interface changes for the specified destination.
FD_ADDRESS_ LIST_CHANGE	Wants to receive notification of local address list changes for the address family of the socket.

Issuing a WSAEventSelect call for a socket cancels any previous WSAEventSelect calls for the same socket and clears the internal network event record. For example, to associate an event object with both reading and writing network events, the application must call WSAEventSelect with both FD_READ and FD_WRITE as the following code sample shows.

rc = WSAEventSelect(s, hEventObject, FD_READ|FD_WRITE);

It is not possible to specify different event objects for different network events. The following code will not work because the second call will cancel the effects of the first, and only the FD_WRITE network event will be associated with hEventObject2.

rc = WSAEventSelect(s, hEventObject1, FD_READ);
rc = WSAEventSelect(s, hEventObject2, FD_WRITE); //bad

To cancel the association and selection of network events on a socket, lNetworkEvents should be set to zero, in which case the hEventObject parameter will be ignored.

rc = WSAEventSelect(s, hEventObject, 0);

Closing a socket with the closesocket function also cancels the association and selection of network events specified in WSAEventSelect for the socket. The application, however, still must call WSACloseEvent to explicitly close the event object and free any resources.

The socket created when the accept function is called has the same properties as the listening socket used to accept it. Any WSAEventSelect association and network events selection set for the listening socket apply to the accepted socket. For example, if a listening socket has a WSAEventSelect association of hEventOject with FD_ACCEPT, FD_READ, and FD_WRITE, then any socket accepted on that listening socket will also have FD_ACCEPT, FD_READ, and FD_WRITE network events associated with the same hEventObject. If a different hEventObject or network event is desired, the application should call WSAEventSelect, passing the accepted socket and the desired new information.

Requirements

Header	winsock2.h
Library	Ws2.lib
Windows Embedded CE	Windows CE .NET 4.0 and later
Windows Mobile	Windows Mobile Version 5.0 and later

Share via

WSAEventSelect

Syntax

Parameters

Return Value

Remarks

Requirements

See Also

Reference

Additional resources