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
- tcp urgent data Kurt Matthys
- Re: tcp urgent data Bob Braden
- Re: tcp urgent data David A. Borman
- Re: tcp urgent data Kurt Matthys
- Re: tcp urgent data Mike Karels
- Re: tcp urgent data minshall