6 May
2020
6 May
'20
8:54 p.m.
On May 5, 2020, at 10:45 PM, Thomas DeBellis
<tommytimesharing at gmail.com> wrote:
Paul,
Thanks for the doc; I'll be giving it a careful look through. Where might I pick up
a copy of DNTERM?
It is a DECnet/Linux application; you should be able to find it in those sources.
It is a true statement that the Tops-20 NRT server is
little more than a character stream. Like I said, it's very close to Telnet without
the IAC's and option negotiations. For my future purposes (handling a security
concern with the Tops-20 FAL architecture), it is perfect.
I remembered some more about CTERM; it appears to implement a concept called break masks.
Under Tops-20, if you are doing something that needs to handle characters specially, one
alternative is to turn off echo, swallow a character and then determine what to do. This
was used in some Tops-10 video based 'SYSTAT'ing programs that I am aware of.
However, this means you're doing a context switch on every blessed character. And so
are 90 other people, which is Bad. It's way too much overhead. A break mask means
that you can have the monitor swallow and echo characters and determine when to return
control to the user program. This was worked on enough so that TEXTI% actually had
something called an 'EMACS' mode, specifically to support this.
I don't recall whether this was pushed out to the front end; hard to say. The VT100
really handed it to the front end.
There were some early attempts towards break masks in some Telnet options; host
controlled local echoing and some such. I don't remember the RFC, but it is quite
old.
I don't remember whether LAT will handle a break mask; if it could, then that's
great--the LAT host worries about gobbling characters and when to send a packet to the
host. That's far more efficient.
LAT knows nothing about terminal driver semantics; it merely implements a raw data stream
in both directions. But it combines data for several terminals into a single Ethernet
packet if it can, and it has some holdoff to try to collect multiple characters arriving
back to back. So it knows that the terminals are used by humans who won't notice
delays well below 100 ms.
On the subject of context switching for every character, that's certainly tricky but
if you plan for it from the beginning you can make it work unusually well. A case in
point is the PLATO system, which in 1976 had up to 600 logged-in terminals connected to a
pair of CDC 6500 small mainframe computers. Those were graphics terminals, highly
interactive; typically about 50% of keystrokes required application action (rather than
simply echoing while collecting a line's worth of input). It worked very well, with
delays almost always low enough that you wouldn't notice. One reason it worked is
that the swapping was doing to/from high speed bulk core memory, at 600 Mbit/s. So while
the application context was perhaps 200-300 words, moving that takes only 40-50
microseconds.
I modified SETHOST to have an additional entry point
to force 4.2 behavior; meaning using two separate forks for input and output instead of
handing the whole thing off to the monitor with MTOPR%. This was so I could use SYSDPY to
see the actual scheduler tests that the forks were waiting for; that's not as easy
when the whole thing is in the monitor.
So RSX and VMS accept the connection and both the client (me) and the remote wind up
waiting. As soon as I type a character, I get thrown off, so I would imagine that there
is some additional negotiations to be done. I'm hesitant to try this on RSTS as
somebody is going to need to restart the NRT server.
NRT is pretty simple; on connection, it reads a configuration message, but only looks at
the first byte to see what the remote system is. That's enough for it to blat about
it not being to either Tops-10 or Tops-20. The other stuff is completely ignored; I
don't see evidence of any configuration being sent. I guess those other bytes are
what I should be looking at. Maybe they'll be in your doc?
Yes, and they are critical. The OS type is just information, but at offset 6 you'll
find the protocol ID, which tells you which of the four protocols to speak. If you ignore
that you will certainly get wrong results. See the doc I sent.
paul