Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!ukma!husc6!rutgers!aramis.rutgers.edu!geneva.rutgers.edu!hedrick From: hedrick@geneva.rutgers.edu (Charles Hedrick) Newsgroups: comp.protocols.tcp-ip Subject: Re: TELNET Buffering Woes Message-ID: Date: 3 May 89 03:06:26 GMT References: <8905021526.AA03195@oliver.cray.com> Organization: Rutgers Univ., New Brunswick, N.J. Lines: 54 We've all noticed the problem where you type ^C and output keeps coming for pages. You suggest that the local telnet should interpret the ^C and use timing mark to resynchronize. That sounds plausible, but it has a problem that makes many of us unenthusiastic about using it: the local telnet has to know what interrupt character to use and when to disable it. If you run a program on the host system that uses "raw I/O", you don't want ^C translated into IAC IP. You want the ^C interpreted as a normal character. The proposed linemode telnet will implement the right handshaking between the host and user telnets to make this kind of thing work. But at the moment I don't consider it safe. We do what the telnet spec suggests, which is to use the telnet sync mechanism. I'll describe this for Unix, but it should work similarly on other OS's. you: type ^C local telnet: pass ^C to host like any other character host telnet: pass ^C as input to the job like any other character OS: notice that ^C is an interrupt character. (1) issue interrupt to job (2) notify host telnet that output should be flushed. (This version of telnetd runs the pty in packet mode, so such notification is actually done.) host telnet: flush all output that has been buffered but not yet sent. Put telnet sync into the output. Telnet sync involves an urgent notification, which moves out of band. The next packet sent from the host to the local telnet should have that bit on. local telnet: when it sees urgent, stop output and flush any pending output. This should happen out of band. That is, as soon as a packet with urgent arrives from the network, output queued to the tty driver should be flushed, and new output coming from the network should be ignored. Ignoring continues until the in-band portion of the telnet sync arrives. The disadvantage compared to your proposal is that you will get a bit more extra output after you type ^C. The amount of delay obviously depends upon your network speed. If you are working over a satellite link, you could see *lots* of extra output. For campus environments it's not too bad. The advantage is that the local telnet doesn't have to know how your OS interprets characters. On many OS's there are several characters that should flush output, e.g. ^C, ^O, and ^Y. And programs can disable one or more of them. (Also, it is possible for programs to invoke the clear output function themselves, without any particular character being typed.) Those of us who use Emacs would certainly not want to see the local telnet turn all three of those characters into an interrupt! My guess is that in a campus environment, your method would work best for half duplex, and this method for full duplex. All of the terminal servers I've seen do implement the local side of telnet sync, so you have to get the host telnet daemon to handle things right. I think we've convinced the right people to get this in 4.4. (In fact it's possible that it is in 4.3 Tahoe.)