Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!ucbvax!opus.cray.com!dab
From: dab@opus.cray.com (Dave Borman)
Newsgroups: comp.protocols.tcp-ip
Subject: Re:  TELNET Buffering Woes
Message-ID: <8905021751.AA03292@oliver.cray.com>
Date: 2 May 89 17:51:38 GMT
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The Internet
Lines: 76

> My terminal server (an ungerman -bass NIU card) is configurable
> to understand special Telnet commands. i.e. I can set it up
> so that when the user types a ^C the server will send a interupt
> process with a "PUSH" or urgent flag. This is not to say that
> the terminal server knows to stop output until it receives another
> flag from the server.
>
> I observe with a packet monitor that the INTERUPT PROCESS is sent
> and data keeps coming (for miniutes). Would this be considered
> normal ? Does the terminal client have to handle all this or
> should the server function on the host at least flush a few characters ?
>
> Ralph Nicovich
> Cal Poly State University, SLO


Let's take the simple case, a terminal connected to a machine, running
telnet to another machine.  When data is being sent from an application
through a telnet connection, there are several places where output can
be buffered:
	1) in the terminal driver on the server machine, waiting
	   for the telnet deamon to read it.
	2) In the telnet deamon itself
	3) In the kernel, on the socket queue for the telnet connection,
	   waiting to go out.
	4) On the client, in the kernel, on the socket queue, waiting
	   for the client telnet to read the data
	5) In the terminal output queue on the client.

Probably the most complete and quickest method of flushing data in a
TELNET stream would be:
	1. Client sends IAC IP, IAC DM, IAC AO, IAC DO TIMING-MARK.
	   The IAC DM is the Telnet "Synch", and is sent in urgent mode.
	   The IAC AO is sent just for good measure.
	2. Client begins to throw away output.  The terminal output queue
	   is flushed (#5 above), and we then continue reading from the
	   TCP connection and throwing away data (#4 above) scanning the
	   data looking for TELNET commands.
	3. Servers gets put into urgent mode, and starts flushing input,
	   looking for interesting commands, or end of urgent data.
	4. Server get IAC IP, and generates an interrupt.  The interrupt
	   should cause the operating system to flush the data in the
	   output queue of the terminal (#1 above).  The deamon should
	   toss any data it has read from the terminal but not processed
	   yet (#2 above), and toss any data that it has buffered up to
	   write to the socket, but has not written yet. (Also #2 above.
	   Flushing the output side could be tricky, because there may
	   be TELNET commands already imbedded in the output buffer that
	   we still need to send...)  Possibly the telnet deamon could
	   tell the kernel to toss any data that it has buffered up but
	   has not sent yet over the telnet connection, (#3 above) but
	   this would not be wise because you would lose any TELNET
	   commands that happened to be in that section of data.
	5. Server gets IAC DM, and goes out of urgent mode.
	6. Server gets IAC AO, and does most of the stuff already
	   mentiond in step 4.
	7. Server gets IAC DO TIMING-MARK, and sends IAC WILL/WONT
	   TIMING-MARK.
	8. Client goes into urgent mode, scanning for TELNET special
	   characters.  Since we are already throwing away data, this
	   doesn't really change anything.
	9. Client gets IAC DM, and goes out of urgent mode.  Client
	   still throws away output.
	10.Client gets IAC WILL/WONT TIMING-MARK and resumes normal
	   terminal output.

So, the bottom line is that the server side should flush any data
data buffered in #1 and part of #2 before it ever gets sent. You
can't do anything about #3, that data has to go across the telnet
connection.  Item #4 and #5 should be cleaned out by the client
side.

Hopefully this answers the questions about flushing the output
stream on a Telnet connection.

		-Dave Borman, dab@cray.com