humtech@ucschu (Mark Frost) (07/09/88)
We are having difficulty with Telnet 2.1 for the Mac. Our primary use for it is to use our UNIX machine (ISI V16) via our Kbox. Our problem is this: Control Characters (specifically the most often used ones like ^C, ^S and ^Q) don't seem to work. Well, actually they sort of work. If I see a lot of text streaming across the screen and I hit ^S to halt the flow or even ^C to interrupt, nothing happens until at least 4 or 5 more screensfull of text go by and then MAYBE ^S or ^C will take effect. Most of the time the stuff that I scroll past is less than 5 pages, so a ^C or ^S will not ever have a chance to work. In this sense it seems as if they don't work at all. Our regular terminals don't have this problem. I don't totally understand the way that information is sent back and forth between the Mac-Kbox-UNIX, but it seems to me that these characters shouldn't take anywhere near that amount of time to work (when they do). I looked in the Telnet documentation and found no reference to any problem like this, and I didn't see a reference to this problem in the "bugs" section either. Has anyone else had similar problems? Your help is greatly appreciated... Mark Frost (humtech@ucschu.UCSC.EDU) Robbie:"Yes, Miss?" Altaira:"Where have you been, I've beamed and beamed..."
sbm@PURDUE.EDU (07/12/88)
What you have described is a common problem with remote login
across networks. The process on the remote machine produces output
which is buffered and sent in packets across a slow network to a process
on the local machine which buffers the output until the even slower
output device can print it. Remember that CPUs are very fast in
relation to I/O; by the time you see the output on the local machine
(the Mac), it is possible that the process on the remote machine has
finished its output and exited.
The reason for the "mushy" ^S, ^Q, and ^C is that they are not
interpreted locally, but sent to the remote machine, where the output
you are seeing is ancient history. I don't know the particulars of
AppleTalk, except that, at 230 Kbaud, it is extremely slow as networks
go, but the solution is considered messy, because it requires treating
^S and ^Q as special cases instead of just sending all characters
verbatim to the remote machine.
Steve Munson
sbm@Purdue.EDU
sbm@Purdue.CSNET
----------krauskpf@uxe.cso.uiuc.edu (07/17/88)
The TCP/IP protocol allows for the current window size of unacknowledged data to be sent before any sort of pause will occur. NCSA Telnet can be configured with window sizes of 512 to 4096 bytes, so this can be quite a problem. Some implementations use TCP's urgent data to signal stream controls in front of user data, but nothing I would call a standard. Instead of that, we have tried to put some helpful commands in the user interface. In version 2.1 you will find that Command-S (Suspend Network) is a local "scroll-lock" feature that will replace Ctrl-S, only it works locally. In version 2.2 you will find not only Suspend Network, but Jump Scroll which allows you to skip over those 4-10 pages of text without waiting for it to scroll by. Tim Krauskopf NCSA timk@ncsa.uiuc.edu
tjh+@ANDREW.CMU.EDU (Tom Holodnik) (07/17/88)
Mark Frost writes:
"Our problem is this: Control Characters (specifically the most often used ones
like ^C, ^S and ^Q) don't seem to work. Well, actually they sort of work. If I
see a lot of text streaming across the screen and I hit ^S to halt the flow or
even ^C to interrupt, nothing happens until at least 4 or 5 more screensfullof
text go by and then MAYBE ^S or ^C will take effect."
My guess is that it's not the version of telnet from NCSA at fault;
this behavior is true for most (if not all) varieties of telnet clients, and
pttys on Unix. This would have to do with how well OOB (out of band) signal
handling is performed, I think. Some do it well, others do not.
This doesn't help you much, I know. The answer is that there isn't a
good answer, apart from using "more" on your Unix machine.
Tom