Path: utzoo!yunexus!geac!syntron!jtsv16!uunet!lll-winken!lll-lcc!ames!pasteur!ucbvax!RADC-LONEX.ARPA!jam
From: jam@RADC-LONEX.ARPA
Newsgroups: comp.protocols.tcp-ip
Subject: Re:  TCP/IP terminalservers and BREAK(/^C)
Message-ID: <8810271350.AA02013@radc-lonex.arpa>
Date: 27 Oct 88 13:50:37 GMT
Article-I.D.: radc-lon.8810271350.AA02013
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The Internet
Lines: 52

> From: mcvax!cernvax!cgch!cgcha!whna@uunet.uu.net  (Heinz Naef)
> 
> Assume a VT-100-type terminal accessing a UNIX host in the following ways:
> (1) via a TCP/IP terminalserver networked with the target host
> (2) via an asynchronous line interface integrated in the target host
> 
> There is a significant difference in how a BREAK (CTRL-C) condition is
> handled:
> In case (1) the terminalserver (3Com/Bridge LS/1, Cisco xSM) continues to
> empty its buffer towards the terminal.
> In case (2) the output to the terminal stops immediately.
> 
> On a UNIX system, try to cat /usr/dict/words with the two attachments
> described above. In case (1) tens, hundreds of pages will be displayed
> after hitting BREAK (or ^C), which is considered a problem of acceptance.
> 
> What is the reason of this different behavior? Would there be no way to
> "rollback" the current buffer's worth of packets upon receiving a BREAK
> and just flush the buffer?

	This is something that probably you will never see fixed.
	On an async line the ^C gets back to the host almost at
	once.  On slow lines you can sometimes see a few extra
	characters pumped out before everything stops.

	Terminal servers use telnet (in most cases) to handle the
	connection to the host computer.  Since the data is flowing
	over the network a lot more of it can be queued up in packets
	while your ^C is trying to get back to the host.  The telnet
	protocol does not explicitly recognize ^C, and has no
	mechanisim for flushing following incomming packets after
	it is typed.

	But think about this:

	What if the user changed the interrupt character?  The protocol
	would have to be informed of the character change.  Also, special
	characters (like ^C) often depend on the operating system.  What
	types of special characters exist for different systems might
	make telnet a nightmare!

	But more important, if telnet would start flushing packets after
	it saw a ^C, what would tell it to stop?  Now the telnetd on
	the host would have to notice the interrupt, and send some kind
	of trailing sequence to the the remote telnet to stop flushing.

	I'm not saying it can't be done.  In fact, it might be a good
	idea (re: the rlogin v.s. telent discussion).  But it probably
	won't be anytime in the near future.


Sorry to be discouraging!
Joel