Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!usc!wuarchive!kuhub.cc.ukans.edu!caen!hellgate.utah.edu!fcom.cc.utah.edu!npd.novell.com!newsun!donp
From: donp@na.excelan.com (don provan)
Newsgroups: comp.protocols.tcp-ip
Subject: Re: LAT vs telnet
Message-ID: <1991May2.193450.25144@novell.com>
Date: 8 May 91 10:15:56 GMT
Sender: news@novell.com (
Lines: 29

The News Manager)
Nntp-Posting-Host: na
Reply-To: donp@novell.com (don provan)
Organization: Novell, Inc., San Jose, California
References: <1991May2.012159.23962@megadata.mega.oz.au>
Date: Thu, 2 May 1991 19:34:50 GMT

In article <1991May2.012159.23962@megadata.mega.oz.au> andrew@megadata.mega.oz.au (Andrew McRae) writes:
>My real question is: If the concept of LAT is good enough, and the
>advantages great enough, why doesn't someone define a protocol that
>does the same job, but is part of TCP/IP; in other words a local telnet
>protocol.

From my point of view, networking is rapidly moving away from the
primitive terminal-to-mainframe connectivity that spawned LAT.  It
makes little sense to develop an optimized protocol for what is now an
obsolete application.

When LAT was developed, DEC and its customers had a very large
investment in terminal-to-mainframe technology.  That made LAT
economical, both finacially, because it saved money for customers by
allowing them to get more mileage out of their terminals, and
technologically, because there were enough terminal-to-mainframe
packets flying around to allow session multiplexing optimizations.

I don't think there's ever been any where near as much terminal
traffic on TCP/IP networks, and there's destine to be much less in the
future.  Consequently, a LAT-like protocol in the TCP/IP suite
wouldn't be cost effective when compared to telnet.
							don provan
							donp@novell.com