Path: utzoo!attcan!uunet!lll-winken!lll-tis!helios.ee.lbl.gov!pasteur!ucbvax!GAAK.LCS.MIT.EDU!map
From: map@GAAK.LCS.MIT.EDU (Michael A. Patton)
Newsgroups: comp.protocols.tcp-ip
Subject: TCP/IP terminalservers and BREAK(/^C)
Message-ID: <8810281551.AA20641@gaak.LCS.MIT.EDU>
Date: 28 Oct 88 15:51:37 GMT
References: <8810272051.AA06701@oliver.cray.com>
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The Internet
Lines: 34


   Date: Thu, 27 Oct 88 15:51:29 CDT
   From: dab%opus.CRAY.COM@uc.msc.umn.edu (Dave Borman)

   To fix a telnet client so that you can flush output when you type ^C
   is really not very hard, and can be done without modifying the telnet
   server.  When the client sends the IAC IP (sent when the user types ^C,
   or whatever the interrupt character is (What? your telnet doesn't send
   IAC IP? Well, since you're changing it anyway, add a user option to say
   what character should be translated to IAC IP)), also send a IAC DO
   TIMING-MARK.  You then proceed to throw away all data until you see a
   IAC WILL/WONT TIMING-MARK, at which point you resume output.  All telnet
   servers should respond to the DO TIMING-MARK, regardless if they support
   it or not (if they don't, then you have a real brain-dead telnetd
   implementation, even 4.2 responds).

Except that the client end can't possibly have enough information
about what is and isn't going to cause output to be flushed, only the
server end (and maybe the user if they know the insides of the server)
can know that.  You can't expect a user to type magic commands
frequently so for this scheme to work you need to add new options in
TELNET to allow the server to tell you every time this changes.  These
will have the same implementation problem that GA had (see parallel
discussion) where the server process can't get at the information.
All in all, I think this suggestion only makes the problem harder to
solve right.  Given the underlying TCP functionality, I think the
original Abort Output (AO) is the best we're going to do, except for
the problem of implementing it in some cases.

	Mike Patton, Network Manager
	Laboratory for Computer Science
	Massachusetts Institute of Technology

Disclaimer: The opinions expressed above are a figment of the phosphor
on your screen and do not represent the views of MIT, LCS, or MAP. :-)