BSD:sockets::SVID:(what?)

[Doug McCallum]

In article <5252 at june.cs.washington.edu> ka at june.cs.washington.edu (Kenneth Almquist) writes:
...
>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

This is definitely a deficiency of sockets, but I would assume that
it is the ambiguity of what URGent data means in TCP that resulted in
little support.  TCP URGENT does not correspond with out of band.  It
is an entirely different beast.

>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

Urgent is still needed.  The intent of urgent is not to push the data to
the user (the PUSH bit does that) but to indicate that data be treated
differently.  In order to implement the TELNET protocol (and even rlogin))
properly requires urgent data support in the TCP sense and not in the TLI
expedited data sense.

>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.

But that is how TCP specifies urgent data - it indicates the end of
the urgent data and not the beginning or length.

>
>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
...
>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.

While you can simulate TLI expedited data, it still doesn't give TLI a
way to use TCP urgent data in the way TCP urgent data is intended to
be used.  You really want the urgent data to be inline with normal
data but have an indication that is truly out of band of where the
urgent data ends in the data stream.  Sockets gives you this by
letting a program query whether there is urgent data (out of band in
socket terms) in the data stream or get a signal whenever there is.
The program can also read the out of band data explicitly or let it be
read as part of the data stream.  TLI only generates a signal when data
arrives at an empty Stream head which means you might not get a signal
when expedited data arrives.

The result is that it is difficult to implement a true TELNET
implementation with just the facilities provided in TLI.  Pulling it
completely out of band and sending it upstream before other data
doesn't work since you lose the position information which is just as
important as the fact that there is urgent data in the stream.
Leaving it in place but not signalling the process in some way that
urgent data exists means you don't find it until you read it which
means that you have lost the function that it is used for in TELNET.

Emulating something else doesn't buy you anything since no non-TLI
implementations will be using your emulation.