Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!uunet!seismo!rutgers!ames!sdcsvax!ucbvax!ETN-WLV.EATON.COM!mcc From: mcc@ETN-WLV.EATON.COM (Crockett) Newsgroups: comp.protocols.tcp-ip Subject: Re: TELNET ELF Message-ID: <8708081946.AA01449@etn-wlv.eaton.com> Date: Sat, 8-Aug-87 15:46:04 EDT Article-I.D.: etn-wlv.8708081946.AA01449 Posted: Sat Aug 8 15:46:04 1987 Date-Received: Sun, 9-Aug-87 12:00:58 EDT Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 38 Sorry for not responding earlier to your message, John. I fully intend to have a robust implementation under IAS; however, I want to be sure that I understand what TELNET is doing and what it expects. There are some IAS processes that a user could invoke during a TELNET session that utilize , , or as line terminators. What the process will do is dependent upon which line terminator is used. I would prefer not to change any of these processes to distinguish between a local terminal and a TELNET terminal or to prohibit the use of these processes to a TELNET terminal. At the moment we have a crude brute force TELNET port which suffers due to archtectural differences between UNIX and IAS and will produce an unacceptable system load in the target application system environment. Our current TELNET port is based on one of our vendors upper layer protocol support package for his TCP/IP board level implementation for an Ethernet interface. It's attrocious! The code looks okay until you notice '/*' and '*/' surrounding rather significant portions of code. When linked to our 4.3bsd gateway machine, we found that it lies about its ability to perform some of the options. Unlike Unix, VMS, RSX-11M (11M PLUS), etc. which have device and pseudo drivers that are integrated into the operating system; IAS has independent tasks referred to as handlers to support devices and pseudo devices. The thought was to split "telnetd" into one portion that was to listen for and accept connections and to integrate the remainder of it with the pseudo terminal handler which significantly reduces the number of context switches that would be required to pass data between the Ethernet interface handler, telnetd, and pseudo terminal handler. I could go off and do whatever I please since the rest of the world won't be permitted access to the network until a "secure" gateway can be developed but it seemed nicer to plan for the future when there will be a common backbone for all the networks. Merton Campbell Crockett