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.]