Path: utzoo!attcan!uunet!lll-winken!ncis.llnl.gov!helios.ee.lbl.gov!pasteur!ucbvax!decwrl!labrea!rutgers!aramis.rutgers.edu!geneva.rutgers.edu!hedrick From: hedrick@geneva.rutgers.edu (Charles Hedrick) Newsgroups: comp.dcom.lans Subject: Re: Ethernet terminal servers Message-ID: Date: 21 Jan 89 02:32:18 GMT References: <6556@fluke.COM> <13718@cup.portal.com> Organization: Rutgers Univ., New Brunswick, N.J. Lines: 73 Here are some advantages and disadvantages of a terminal server compared with directly connected terminals and modems. I'm thinking of TCP/IP's telnet protocol, but similar considerations should be true of other network technology. 1) If you are in a changing environment it's easier to plan. All terminal lines go directly to a terminal server and stay there. When you change computers, you don't have to move people from the old one to the new one, nor do you have to move people from one to another when their tasks change and they start using a different one. 2) There is only one kind of asynch interface to worry about. Every machine has a slightly different definition of RS232, with different handling of modem lines, grounding, etc. So our terminals people are saved from having to know about the details of all of them. 3) Many machines have substandard RS232 support. The terminal server does a better job. 4) If your primary machine is down, you can go play on another one. If you're directly connected, you lose. Before terminal servers, people typically had switches on their desk to connect them to one of several machines. This is no longer needed. 5) The telnet implementations on the terminal server is typically better than the telnet implementation in many hosts. 6) In public terminal rooms and for dialups, you get much better utilization. If terminals and modems are tied to a machine, they can only be used by people with an account on that machine. Sure, they can telnet elsewhere, but they have to be able to log into the first place to start with. 7) If you go through a multiuser system, your response time will be affected by the load on that system. So you now have to worry about the load on two systems, not just one. 8) If lots of people telnet from the machine they are wired to to others, you're using your hosts as terminal servers. They are probably more expensive per user than a real terminal server, and probably not as good. There are disadvantages as well: 1) You become critically dependent upon the state of your network. You had better have good network support. This is a non-trivial consideration. Rutgers puts a lot of effort into our network, both hardware and software. 2) You become critically dependent upon the quality of the software on your hosts that handles incoming connections. If it is substandard, you have to be able to fix it, or use "milking machine" configurations. 3) Every user goes through at minimum two computers: the real one and the terminal server. So there is more that can fail. This depends upon how often people use the same machine. If they typically use different ones, then they'll have to telnet out of their primary machine, and they are dependent upon two machines anyway. Normally terminal servers are rather simple pieces of hardware and are quite reliable. 4) Some "out of band" terminal functions become harder. The classic ones are ^S/^Q and clearing the output buffer. Rlogin and telnet both have provisions to deal with these problems. If you have good implementations on both the terminal server and host, the connection feels just about like a hardwired lines. If not, things can be unpleasant. ^S/^Q can be handled completely. Either use rlogin or use the new remote flow control option in telnet. Clearing the output buffer when the user types ^C, ^O, etc., can be done reasonably, but even with good implementations you'll get a few extra lines of output before they take effect.