Out-of-Band Data in the SPI
A version of this page is also available for
4/8/2010
The service providers that support the out-of-band data (OOB) abstraction for the stream-style sockets must adhere to the semantics in this section. OOB data handling in a protocol-independent manner is described later. Please refer to the Windows Sockets 2 Protocol-Specific Annex (a separate document)for a discussion of OOB data implemented using urgent data in TCP/IP service providers. In the following, the use of WSPRecv also implies WSPRecvFrom.
Protocol Independent–Out-of-Band Data in the SPI
OOB data is a logically independent transmission channel associated with each pair of connected stream sockets. OOB data may be delivered to the user independently of typical data. The abstraction defines that the OOB data facilities must support the reliable delivery of at least one OOB data block at a time. This data block may contain at least one byte of data, and at least one OOB data block may be pending delivery to the user at any one time. For communications protocols which support in-band signaling (that is, TCP, where the urgent data is delivered in sequence with the typical data), the system usually extracts the OOB data from the typical data stream and stores it separately (leaving a gap in the typical data stream). This allows users to choose between receiving the OOB data in order and receiving it out of sequence without having to buffer all the intervening data. It is possible to peek at OOB data.
A user can determine if there is any OOB data waiting to be read using the WSPIoctl(SIOCATMARK) function. For protocols where the concept of the position of the OOB data block within the typical data stream is meaningful (that is, TCP), a Windows Sockets service provider will maintain a conceptual marker indicating the position of the last byte of OOB data within the typical data stream. This is not necessary for the implementation of the WSPIoctl (SIOCATMARK) functionality — the presence or absence of OOB data is all that is required.
For protocols where the concept of the position of the OOB data block within the typical data stream is meaningful an application may prefer to process out-of-band data inline, as part of the typical data stream. This is achieved by setting the socket option SO_OOBINLINE (see section WSPIoctl). For other protocols where the OOB data blocks are truly independent of the typical data stream, attempting to set SO_OOBINLINE will result in an error. An application can use the SIOCATMARK WSPIoctl command to determine whether there is any unread OOB data preceding the mark. For example, it might use this to resynchronize with its peer by ensuring that all data up to the mark in the data stream is discarded when appropriate.
With SO_OOBINLINE disabled (by default), the following actions result:
- The Windows Sockets service provider returns from WSPSelect with the appropriate exceptfds socket set if OOB data is queued on the socket.
- The client can call WSPRecv with MSG_OOB to read the urgent data block at any time. The block of OOB data jumps the queue.
- The client can call WSPRecv without MSG_OOB to read the typical data stream. The OOB data block will not appear in the data stream with typical data. If OOB data remains after any call to WSPRecv, the service provider notifies the client with FD_OOB or through exceptfdswhen using WSPSelect.
- For protocols where the OOB data has a position within the typical data stream, a single WSPRecv operation will not span that position. One WSPRecv will return the typical data before the mark, and a second WSPRecv is required to begin reading data after the mark.
With SO_OOBINLINE enabled, the following actions result:
- FD_OOB messages are not posted for OOB data — for the purpose of the WSPSelect function, OOB data is treated as typical data, and indicated by setting the socket in readfds or by sending an FD_READ message respectively.
- The client may not call WSPRecv with the MSG_OOB flag set to read the OOB data block - the error code WSAEINVAL will be returned.
- The client can call WSPRecv without the MSG_OOB flag set. Any OOB data will be delivered in its correct order within the typical data stream. OOB data will never be mixed with typical data — there must be three read requests to get past the OOB data. The first returns the typical data prior to the OOB data block, the second returns the OOB data, and the third returns the typical data following the OOB data. In other words, the OOB data block boundaries are preserved.