Xref: utzoo comp.protocols.tcp-ip:4989 comp.dcom.lans:1970 comp.unix.questions:9917
Path: utzoo!utgpu!water!watmath!clyde!att!rutgers!apple!bionet!uwmcsd1!marque!uunet!mcvax!cernvax!cgch!cgcha!whna
From: whna@cgcha.uucp (Heinz Naef)
Newsgroups: comp.protocols.tcp-ip,comp.dcom.lans,comp.unix.questions
Subject: TCP/IP terminalservers and BREAK(/^C)
Keywords: TCP/IP, telnet, rlogin, BREAK, ^C, UNIX
Message-ID: <711@cgch.UUCP>
Date: 25 Oct 88 08:51:01 GMT
Sender: news@cgch.UUCP
Lines: 24

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?

Thanks in advance for any comments.

Regards,
Heinz Naef, c/o CIBA-GEIGY AG, R-1032.5.58, P.O.Box, CH-4002 Basel, Switzerland
UUCP: cgch!whna - Internet: whna%cgch.uucp@uunet.uu.net
BITNET: whna%cgch.uucp@cernvax.bitnet