On 2015-10-19 19:42, Paul Koning wrote:
On Oct 19, 2015, at 12:17 PM, Johnny Billquist <b...@update.uu.se> wrote:
On 2015-10-19 16:32, Paul Koning wrote:
On Oct 19, 2015, at 3:42 AM, Pontus Pihlgren <pon...@update.uu.se> wrote:
Interesting. I thought Tthe DECserver 550 was merely the big brother in
the terminal server line. But it looks like it is essentially a
PDP-11/53 with 1.5MW of ram, you need new boot roms though. Pretty nice.
It's been a while, but I think it may be a member of the "pluto" family. The
original plan for terminal servers was that they would run CTERM. But the initial Pluto
terminal server was incredibly slow, not surprising given how complex that protocol is.
So an AD project was started which created LAT, originally also in a PDP-11 processor
(perhaps even the same one, I forgot). And that turned out to be so superior in practice
that it ended up being the main product instead of the original plan. But we still have
CTERM as a leftover from all this.
Yeah, that should be PLUTO.
It's based on RSX, and talks LAT. I never knew that they considered using CTERM
(a horrible protocol).
Oh yes... and I think the original PLUTO was an 11/23, which would certainly
explain why it had performance issues.
CTERM was an attempt to wrap a single protocol around the terribly inconsistent
semantics of the terminal drivers in all the DEC operating systems, and to
export as much as possible to the server end. In other words, the goal of the
protocol was to be line oriented as much as possible. That meant, for example,
exporting the command line editing machinery to the server. That doesn't seem
so bad until you realize that the server has to be told a whole lot about what
is going on at the client in order to do that. The eventual goal was to have
not just command line mode but also other modes, like screen editing mode
(think distributed EDT). That's why there are two layers, with the foundation
layer common to all modes, and Cterm the first of the modes to be defined.
Some example of the complexities: the ability to define what characters are
line edings; immediate vs. delayed echo; command line completion in TOPS-20;
and so on.
When the dust settled, the 36 bit machines were starting to disappear around
this time, and management was trying to do similar things to PDP11s in general
and non-RSX in particular, so CTerm ended up being really just a ridiculously
complex way of doing what the old VMS terminal protocol did just as well.
An interesting way to describe it.
I've always looked at CTERM as an RPC service that essentially have all
the functions of the VMS terminal driver. Makes it easy to implement in
VMS, as you have a 1:1 mapping. Makes it horrible for everyone else,
since other systems do not have the same functionality in the terminal
driver, and now have to implement all the remote procedure calls of the
VMS terminal driver, and somehow map that into how the native terminal
driver works...
Johnny
