4.15.9 Notes on transmission of OOB data

In a TCP/IP stream–oriented client/server architecture, the scenario is the following:

 --------------------        ------------
| sending appication |----->| sending OS |
 --------------------        ------------
                                  |
                                  v
 -----------------------     -------------
| receiving application |<--| receving OS |
 -----------------------     -------------

sending ordinary data works as follows:

1. The sending application calls (for example) the send function asking the sending OS to send data to the remote host.
2. The sending OS enqueues the data in a FIFO buffer, which it progressively fragments in packets for delivery.
3. The receiving OS orders and enqueues data from received packets in a FIFO buffer.
4. The receiving application calls (for example) the recv() function to consume chunks of the input data.

sending a single byte of OOB data works as follows:

1. The sending application calls the function send specifying the MSG_OOB flag, asking the sending OS to deliver a single byte of OOB data.
2. The sending OS enqueues the single byte in its FIFO buffer and tags the next outgoing packet to announce future delivery of the OOB byte.
3. The receiving OS orders and enqueues data from received packets in a FIFO buffer; when it detects a tagged packet announcing the OOB byte: it optionally informs the receiving application of its future arrival, signaling an exceptional condition on the socket descriptor, if requested.
4. The sending OS proceeds in sending ordinary data from its FIFO buffer and whenever it reaches the OOB byte: it sends it in a specially tagged packet.
5. The receiving OS orders and enqueues data from received packets in a FIFO buffer; when it detects a tagged packet holding the OOB byte: it makes it available to the receiving application.
6. The receving application calls the function recv specifying the MSG_OOB flag and retrieves the single OOB byte.

If we send the OOB byte with the form:

(px.send sock '#vu8(8) #f MSG_OOB)

the byte 8 will be the OOB byte; if we send the OOB byte with the form:

(px.send sock '#vu8(1 2 3) #f MSG_OOB)

the byte 3, the last in the memory block, will be the OOB byte and the bytes 1 and 2 will be sent as ordinary data; the receiving application must not assume that bytes 1 and 2 will be made available before the OOB byte 3.

When using select to be notified of incoming OOB data: the receiving application must assume that the exceptional condition is notified only once and not persist in further calls to select; for this reason the exceptional condition must be recognised and registered by the application as soon as it is notified by select.

The socket option SO_OOBINLINE allows the OOB byte to be placed in the ordinary data FIFO buffer, so that it can be transparently consumed by a call to read or recv without the MSG_OOB flag.

Notice that the single OOB byte, although limited, can represent 256 symbols in an appropriate alphabet of commands.