Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!decvax!ucbvax!YALE.ARPA!LEICHTER-JERRY From: LEICHTER-JERRY@YALE.ARPA.UUCP Newsgroups: mod.computers.vax Subject: Re: using LAT Message-ID: <8701162012.AA16487@ucbvax.Berkeley.EDU> Date: Fri, 16-Jan-87 15:13:07 EST Article-I.D.: ucbvax.8701162012.AA16487 Posted: Fri Jan 16 15:13:07 1987 Date-Received: Sat, 17-Jan-87 01:40:26 EST Sender: daemon@ucbvax.BERKELEY.EDU Reply-To: Organization: The ARPA Internet Lines: 86 Approved: info-vax@sri-kl.arpa > BTW, why would you want it? I can understand using LAT between dif- > ferent kinds of systems, but VMS to VMS, CTERM should do better. There is a great deal more overhead in using CTERM because it goes through all of the standard DECnet protocol layers. LAT uses its own ethernet protocol type value and bypasses all of this. That's why DEC implemented LAT for the terminal servers. Of course, if you use LAT, the host must be on the same ethernet. Can't get through a router. In principle, what you say is true. In practice, do you have any evidence for it? The difference in protocol complexity actually used over an Ethernet is not all that great; the actual load offered is small compared to capacity (so that differences are likely to be lost in the noise even if there are any); and, in any case, it all depends on what you are doing. Let's take a simple case: Typing a 30-character command line to VMS. With LAT, echoing is done by the VMS system, and given user typing speeds, each character typed will be transmitted in its own packet, and each echo likewise. That's around 60 packets. With CTERM, on the other hand, the local system handles echoes, deletions, and so on, sends nothing until the entire line is collected, then sends all 30 characters in one packet. So which is "more efficient"? VMS and CTERM share a model of terminal interaction that is actually quite complex and sophisticated. The more the application involved uses the more sophisticated parts of the model (field editing and so on), the bigger the advantage CTERM has. CTERM loses out when it is reduced to imitating LAT, either because the application uses the interface at a very low level (char- acter at a time, application echoing) or because it is being used between systems that don't share this model - RSTS and Unix systems, for example. (Actually, in this case you have to trade off efficiency and "transparency" - fidelity in reproducing the non-matching system's interaction model). BTW, you might think that screen editors would fall into the very-low-level class; but most typing in screen editors occurs at the ends of lines, and modern screen editors are generally clever enough to recognize this and simply ask for as many characters as will fit on the line, with the OS (on the remote system) doing the echoing (and waking up the application if a control key is struck, for example). In fact, most decent terminals today have an insert mode, which allows this kind of input to be done even in mid-line, in many cases. LAT was designed to be efficient for terminal servers, which connect a bunch of terminals to a relatively small number of hosts. Each packet between a server and a host has space for data for multiple terminal sessions; the LAT protocol gains efficiency when it can actually pack such data together. Con- versely, the "single session from a single host to a single host" is the worst configuration for the LAT protocol - though it will work. Using the LAT protocol instead of CTERM wins: - If you are using applications that use very low level interfaces to the terminal driver; - If you want to talk to systems with incompatible terminal interac- tion models, and you insist on complete transparency; - If you want to talk to systems that don't have DECnet (via "reverse LAT" connections); - If you want to build a terminal server which supports multiple terminals, wants to talk to all kinds of hosts - and runs on a machine without DECnet support, as building LAT support is simpler than building DECnet support. CTERM PROBABLY wins in other cases - though I'd still like to see someone measure this, rather than just speculate. The actual VMS LAT implementation also has one major advantage over the actual VMS CTERM implementation: An LTA can be disconnectable (or connect to a pre- viously disconnected process), while an RTA cannot. This has nothing to do with the protocols or their relative efficiencies - it reflects an (unfortu- nate) series of VMS design decisions. Finally, one suggestion I saw for why LAT would be better is that SET HOST only supports one session, while terminal servers support multiple sessions. This, however, is an issue quite independent of the protocol used. It would be quite possible to write an LTPAD that only supported on session, and it would also be quite possible to write an RTPAD that supported many. (In fact, back in V3 days, I actually saw such a beast - it was a hacked up version of RTPAD that ran 4 sessions. Rather unreliable, though, as it was derived from an early, buggy version of RTPAD and didn't benefit from numerous later revi- sions. Long gone, now.) -- Jerry -------