Xref: utzoo comp.sys.ibm.pc:19739 comp.sys.mac:20952 comp.sys.amiga:23312 comp.sys.atari.st:11645
Path: utzoo!utgpu!attcan!uunet!husc6!rutgers!aramis.rutgers.edu!athos.rutgers.edu!hedrick
From: hedrick@athos.rutgers.edu (Charles Hedrick)
Newsgroups: comp.sys.ibm.pc,comp.sys.mac,comp.sys.amiga,comp.sys.atari.st
Subject: Re: Boycott Apple Again -- Now about Suns
Message-ID: 
Date: 29 Sep 88 09:39:10 GMT
References: <358@island.uu.net> <626@mace.cc.purdue.edu> <12196@steinmetz.ge.com> <989@aluxp.UUCP>
Organization: Rutgers Univ., New Brunswick, N.J.
Lines: 42

I don't know why we're discussing bugs in Berkeley Telnet on this
newsgroup, but the fact that ^C doesn't stop output in telnet is not
peculiar to the Sun implementation.  Since the same problem is likely
to occur with micro implementations, and people are beginning to use
PC's of various kinds as virtual terminals over the network, it is
probably worth noting at least briefly what is going on.  When you
open a virtual terminal connection using telnet (the official virtual
terminal protocol for TCP/IP), there are typically delays in getting
control characters to take effect.  The most obvious delays are when
you try to pause output using ^S, or stop it completely using ^O, ^C
or whatever your OS uses.  Most TCP implementations do lots of
buffering of data, in order to improve throughput and decrease
overhead.  When you do something like ^C, the host may immediately
stop generating output, but there may be several pages of data already
in flight in various pieces of the networking software.  In order to
stop output more quickly, telnet has something called "sync," which
allows the host to clear all that buffered output.  It isn't perfect,
but with good software on both ends, the runover can be kept down to a
few lines.  The problem is that a lot of TCP/IP implementations are
based on Berkeley code, and Berkeley didn't implement sync in 4.2 BSD.
(Most Unix vendors' TCP/IP code until very recently was based on 4.2.)
In order for sync to work, both ends must implement it.  4.3 BSD
implements it on the server end but not the user end.  I think 4.3
Tahoe may have added user end support as well.  (Just server end means
that if you use a 4.3 system as a host, and your PC or terminal server
does sync, things will work.  But if you telnet out of the 4.3 system,
things won't work, since it isn't in the user telnet.)  Depending upon
which VMS implementation you used and how old the software is, there's
a good chance that your VMS host didn't do sync.  There is another
program for doing virtual terminal connections, called rlogin.  It
transfers a bit more information about the status of the terminal.  So
it allows stopping and starting to work somewhat more quickly.
Although this was initially invented by Berkeley for Unix, many other
implementations now support rlogin (including both PC and VMS
implementations).  So if you want output to stop quickly, you might
try rlogin.  However if you are buying TCP/IP software, I also suggest
checking to see whether it implements telnet sync, since telnet is
still more widely available than rlogin.

[May I suggest that this is not an appropriate set of newsgroups in
which to air everything you've ever tried to do on a Sun and not had
work correctly.]