Re: tcp urgent data

[Kurt Matthys <[e-mail]>]

> > I am wondering if there is a standard, approved way to handle tcp
> > urgent data when an rfc793 compliant host is communicating with an
> > RFC 1122 compatible host.    If the 793 host is sending, the 1122
> > host thinks that there is more urgent data than there really is.  The
> > problem here is that Telnet is supposed to keep looking for the IAC
> > DM after running out of urgent data.  The DM will be in the
> > penultimate byte of urgent data as far as the 1122 host is concerned.
> > Telnet will look at the last byte of what it thinks is urgent data,
> > see that it is not a DM, and continue discarding input.  This is not
> > good.
> >
> > One way to handle the situation is for the 1122 TCP to lie to Telnet,
> > saying that there is one less urgent byte than TCP thinks there is.
> > This will work whether the 1122 host is communicating with a 793 host
> > or a 1122 host.  This sounds like a kludge to me, and is esthetically
> > not pleasing as TCP is now lying to the applications.   Can someone
> > shed some light on this for me?
>
> No, you don't want TCP to lie to Telnet.  You want Telnet to lie
> to TCP...
>
> Think about the application, and what it will do.  RFC 854 says:
>
>          The Synch is sent via the TCP send operation with the Urgent
>          flag set and the DM as the last (or only) data octet.
> and:
>          If TCP indicates the end of Urgent data before the DM is found,
>          TELNET should continue the special handling of the data stream
>          until the DM is found.
>
> If the IAC DM is sent as:
> seq# 101    IAC
> seq# 102    DM
>
> Then the correct urgent pointer would be seq#102.  The incorrect
> urgent pointer would be seq#103.  If a correct TCP got the packet
> from an incorrect TCP, it would continue to have urgent notification
> after the IAC DM was read, and would thus keep reading, looking for
> another IAC DM.
>
> If an incorrect TCP got the packet from a correct TCP, it would get
> to the end of the urgent notification before reading the DM.  But
> the rules say to keep reading until an IAC DM is found, so it will
> read the next byte, find the DM, and properly terminate the Synch.
>
> So, if the Telnet application sends the IAC as the last byte of
> urgent data, rather than the DM, then it doesn't matter whether
> the telnet is running on top of a correct or an incorrect TCP.
> Correct to correct, and incorrect to incorrect will have the
> Urgent terminate 1 byte early.  Incorrect to correct will appear
> to have the urgent terminate at the right point.  Correct to
> incorrect will have the urgent terminate 2 bytes early.  In all
> cases, since the urgent notification terminates before or at
> the DM, the telnet application will do the right thing.
>
> Of course, if the application knows that it is running on
> a correct TCP, it can send send the urgent data normally.
> If it know that it is running on an incorrect TCP, it can
> send one less byte as urgent data, and assume that when it
> reads urgent data that there is really one more byte of
> urgent data than what TCP says.
>
>         -David Borman, [e-mail]
>

Dave,

Thanks for the info.  I still have some questions though.  Your
solution works fine for Telnet if you have control over the
end sending the urgent data.  It also works if you are sending two or
more bytes of urgent data.  It doesn't seem to work if only one byte
of urgent data is being sent and Telnet is not being used, or if you
only have control over the receiving end.

With your solution, if an application on an incorrect host wants to
send only one byte of urgent data, it will tell TCP that it wants to
send zero bytes of urgent data.  TCP will probably not send
anything.  The same application on a correct host would tell TCP to
send one byte of urgent data but an incorrect host receiving it would
think that there are no urgent bytes even though the urgent flag is
set.

I am interested in the case where I don't have control over all the
sending ends (they are existing applications), Telnet is not being
used, and only one byte of urgent data is being sent in each
direction.  Any ideas?

BTW, did the BSD code ever change to do urgent data correctly?  I
understand that USL also did it incorrectly.  Did they ever change?
What kind of a market does a correct implementation have?  What
percent of the implementations out there will it interoperate with?
What are the prospects in the long run?  I can see where it would be
difficult for any vendor that supplies an incorrect TCP to change
since his implementation would not even interoperate with old
versions of his implementation.

Kurt


----------------------------------------------------------------------
Kurt Matthys
Unisys Corp                       Tel:    [phone]
M.S. 4123                         Fax:    [phone]
P.O. Box 64942                    email:  [e-mail]
St. Paul, MN 55164 0942
----------------------------------------------------------------------