Re: tcp urgent data

"David A. Borman" <dab@berserkly.cray.com> Wed, 29 September 1993 18:32 UTC

Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa09755; 29 Sep 93 14:32 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa09751; 29 Sep 93 14:32 EDT
Received: from venera.isi.edu by CNRI.Reston.VA.US id aa25503; 29 Sep 93 14:32 EDT
Received: from cray.com (timbuk.cray.com) by venera.isi.edu (5.65c/5.61+local-13) id <AA02862>; Wed, 29 Sep 1993 11:24:54 -0700
Received: from frenzy.cray.com by cray.com (4.1/CRI-MX 2.19) id AA23024; Wed, 29 Sep 93 13:24:51 CDT
Received: by frenzy.cray.com id AA21898; 4.1/CRI-5.6; Wed, 29 Sep 93 13:25:52 CDT
Date: Wed, 29 Sep 1993 13:25:52 -0500
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: "David A. Borman" <dab@berserkly.cray.com>
Message-Id: <9309291825.AA21898@frenzy.cray.com>
To: kurt@rsvl.unisys.com
Subject: Re: tcp urgent data
Cc: end2end-interest@isi.edu, ietf-hosts@isi.edu

> Kurt,
> From HYS1@rs_hcomm.rsvl.unisys.com Wed Sep 22 14:24:19 1993
> To: ietf-hosts@ISI.EDU, end2end-interest@ISI.EDU
> From: "Kurt Matthys"  <HYS1@rs_hcomm.rsvl.unisys.com>
> Date:         22 Sep 93 14:17:01 CST
> Subject:      tcp urgent data
> Reply-To: kurt@rsvl.unisys.com
> Priority: normal
> X-Mailer:     Pegasus Mail v2.3 (R5).
> 
> 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, dab@cray.com