24.4 TCP Out-of-Band Data Recap
All our examples using out-of-band data so far
have been trivial. Unfortunately, out-of-band data gets messy when
we consider the timing problems that may arise. The first point to
consider is that the concept of out-of-band data really conveys
three different pieces of information to the receiver:
-
The fact that the
sender went into urgent mode. The receiving process can be notified
of this with either the SIGURG signal or with
select. This notification
is transmitted immediately after the sender sends the out-of-band
byte, because we saw in Figure 24.11 that TCP
sends the notification even if it is stopped by flow control from
sending any data to the receiver. This notification might cause the
receiver to go into some special mode of processing for any
subsequent data that it receives.
-
The
position of the out-of-band byte,
that is, where it was sent with regard to the rest of data from the
sender: the out-of-band mark.
-
The actual
value of the out-of-band byte.
Since TCP is a byte stream protocol that does not interpret the
data sent by the application, this can be any 8-bit value.
With TCP's urgent mode, we can think of the URG
flag as being the notification, the urgent pointer as being the
mark, and the byte of data as itself.
The problems with this concept of out-of-band
data are that: (i) there is only one TCP urgent pointer per
connection; (ii) there is only one out-of-band mark per connection;
and (iii) there is only a single one-byte out-of-band buffer per
connection (which is an issue only if the data is not being read
inline). We saw with Figure 24.12 that an
arriving mark overwrites any previous mark that the process has not
yet encountered. If the data is being read inline, previous
out-of-band bytes are not lost when new out-of-band data arrives,
but the mark is lost.
One common use of out-of-band data is with
rlogin, when the client interrupts the program that it is
running on the server (pp. 393鈥?94 of TCPv1). The server needs to
tell the client to discard all queued output because up to one
window's worth of output may be queued to send from the server to
the client. The server sends a special byte to the client, telling
it to flush all output, and this byte is sent as out-of-band data.
When the client receives the SIGURG signal, it just reads
from the socket until it encounters the mark, discarding everything
up through the mark. (Pages 398鈥?01 of TCPv1 contain an example of
this use of out-of-band data, along with the corresponding
tcpdump output.) In this scenario, if the server sent
multiple out-of-band bytes in quick succession, it wouldn't affect
the client, as the client just reads up through the final mark,
discarding all the data.
In summary, the usefulness of out-of-band data
depends on why it is being used by the application. If the purpose
is to tell the peer to discard the normal data up through the mark,
then losing an intermediate out-of-band byte and its corresponding
mark is of no consequence. But if it is important that no
out-of-band bytes be lost, then the data must be received inline.
Furthermore, the data bytes that are sent as out-of-band data
should be differentiated from normal data since intermediate marks
can be overwritten when a new mark is received, effectively mixing
out-of-band bytes with the normal data. telnet, for
example, sends its own commands in the normal stream of data
between the client and server, prefixing its commands with a byte
of 255. (To send this value as data then requires two successive
bytes of 255.) This lets it differentiate its commands from normal
user data, but requires that the client and server process each
byte of data looking for commands.
|
