BSD:sockets::SVID:(what?)

[Kenneth Almquist]

> These are mostly nits, but sockets have these capabilities and I've
> hit them all while trying to port applications from a socket
> environment to TLI.  The one case that TLI doesn't even have even
> close to the mechanism that sockets have is in the case of TCP urgent
> data.  This almost maps to expedited data, but expedited data is
> in-band.  There is no way to signal the process that this data has
> appeared in the data stream until it reaches the front of the Stream
> head.  Sockets provide a signal for async notification and an ioctl to
> query.  It makes it difficult to use urgent data for things like data
> stream flushing if you can't detect the urgent data until you read it.

TLI includes support for "out of band" data which has priority over
normal data.  My streams manual is back in New Jersey, so I can't check
whether it provides notification via signals, but some sort of support
for this feature is there.  It is not usable with TCP because the TCP
protocol does not include a facility to permit out of band data.

The urgent data pointer in TCP is intended to allow all the data written
up to a given point to be made available to the receiver as soon as
possible.  The Berkeley sockets facility, unlike TLI, does not allow
the user to determine whether the underlying protocol supports out of
band data.  Probably for that reason, the Berkeley TCP implementation
includes limited support for out of band data.  The idea they used is
that since their implementation of TCP makes all data available to the
receiver as soon as it arrives, the intended function of the urgent data
pointer is not needed with their implementation.  They therefore decided
that, when the user specifies that a block of data is to be made available
to the user as soon as possible, the last byte of the block should be
treated as out of band data.  This is a poor way to implement out of band
data.  In particular flow control on normal data will also hold back the
"out of band" data, which destroys one of the main reasons for having
out of band data in the first place.

It is not hard to implement out of band data on top of TCP.  Multiplex
the out of band and regular data onto a single TCP connection using some
scheme to allow you to distinguish between the two.  Make your program
read data as the data arrives, using SIGPOLL.  The out of band data can
be processed directly inside your signal handler for SIGPOLL, while in
band data can be put on a queue.  Reading the data when it arrives will
keep the flow control in TCP from going into effect.  Implement your own
flow control for in band data only by acknowledging in band data as it
is processed.

An alternative is to use two TCP connections, one for in band data and
the other for out of band data.  In any case, there is in my view little
justification for using nonstandard extensions to TCP to get out of band
data since this feature can be build (with a few deficiencies relating
to retransmission) on top of standard TCP.
						Kenneth Almquist