jle@ece-csc.UUCP (Jamie Evans) (10/12/88)
I am currently interested in purchasing a tcp/ip terminal server for the department here at Virginia Tech. We currently have a network consisting of a DEC 3500 and 2000 running Ultrix, 30 Macintosh A/UX systems, a Sun and numerous AT&T pcs. We would like to have a tcp/ip terminal server for our terminal room and to allow faculty to call in from home. I am interested in any vendor information/prices/contacts that anyone could offer. I am currently accessing USENET from NC State so if you have any suggestions of what servers are better than others, suggestions, etc. please let me know. I can be reached via e-mail at jle@vtopus.cs.vt.edu, through Applelink via U60 or by phone at 703-961-6931. Thanks in advance.... -Jamie Evans- Director of Computing CS Department Virginia Tech
ron@ron.rutgers.edu (Ron Natalie) (10/13/88)
The two leaders, in my opinion, are ENCORE and CISCO. They seem to trade back and forth as to functionality. The ENCORE probably provides more user facilities (like the ability to get parts of EMACS in the terminal servers). CISCO wins out on the fact that you can put 96 lines in a single box. This is handy for large scale central modem banks or bign terminal rooms (the big box turns out to be much cheaper than several of the smaller ones). There are other units available from Bridge, UB, Micom, Xyplex, and Develcon. These are probably lagging slightly behind the leaders in general niceness and bang for the buck. -Ron
haas@wasatch.UUCP (Walt Haas) (10/18/88)
I've been evaluating terminal servers and am not too pleased with the results so far. The application I have in mind is a little different from the usual- I want to put a TCP/IP/Ethernet server back-to-back with a Zenith Z-LAN NCU so that users of the Z-LAN network can access Ethernet machines and vice versa. Therefore the TCP/IP server must simultaneously provide both modem control and hardware flow control in both directions. This rules out use of the cisco ASM and the Encore Annex, sigh, both of which look like good boxes in most other respects. 3com/Bridge loaned me a CS/1 for evaluation and it does the modem and flow control fine. Unfortunately it doesn't support rlogin and refuses to ping a multihomed host (like, for example, cs.utah.edu). I talked to the software support guy at 3com/Bridge about this and his reply was that they had no plans to support rlogin, and you shouldn't give two IP addresses to the same host (!). So from that I think we can safely say that they can't support their software. Incidentally I wrote their President a letter asking him to please get onto the Internet so I wouldn't have to play telephone tag for a week at a time to talk to his guys. He never replied to the letter. Right now I have a Micom/Interlan NTS-100 downstairs to evaluate. Their literature says it supports rlogin but I can't fin any sign of rlogin in the actual firmware - plus there are a slew of obvious bugs. Probably I just got an old copy of the firmware but their tech support guys aren't returning phone calls - at least not with any degree of rapidity. I know somebody on the net posts from Interlan - it seems, however, that this is not known to their management, or at least is not thought of as a way to support customers, because the local rep has been beating on them to improve the accessibility of their support and he reports that Micom/ Interlan management isn't even aware that this channel exists. So would all you folks with brilliant ideas about how to solve this problem mind coming out of the woodwork with your bright ideas? Thanks in advance -- Walt Haas haas@cs.utah.edu utah-cs!haas
kwe@bu-cs.BU.EDU (kwe@bu-it.bu.edu (Kent W. England)) (10/19/88)
In article <417@wasatch.UUCP> haas@wasatch.UUCP (Walt Haas) writes: >I've been evaluating terminal servers and am not too pleased with the results >so far. The application I have in mind is a little different from the usual- >I want to put a TCP/IP/Ethernet server back-to-back with a Zenith Z-LAN NCU >so that users of the Z-LAN network can access Ethernet machines and >vice versa. Therefore the TCP/IP server must simultaneously provide both >modem control and hardware flow control in both directions. This rules out >use of the cisco ASM and the Encore Annex, sigh, both of which look like >good boxes in most other respects. > >So would all you folks with brilliant ideas about how to solve this >problem mind coming out of the woodwork with your bright ideas? > You are right about the products: those that do good telnet and rlogin don't understand serial lines and those that understand serial lines (like U-B, Sytek, ...) don't do rlogin, domain name, etc very well. I think part of the problem is trying to minimize the number of pins supported. The vendors want to use just four or five signals when we need eight (but not always all at the same time). Using eight signals only allows six circuits on a 50 pin telco connector. Using six or fewer signals lets you put eight circuits on a 50 pin telco. I don't think a lot of the hardware design goes much beyond those decisions. It's my opinion that, at a minimum, your serial interface needs to support a connect/disconnect hardware handshake and a ready/clear flow control handshake. connect/disconnect is usually dtr/dsr or dtr/cd. Hardware flow control is usually rts/cts. But no matter; you can always remap the flow control or conn/disconn signals to other pins on your punchdown or in your RJ/DB adaptor. The point is that you need the functionality of handshaking upon connect and disconnect (how many of you have systems that don't close sessions when the modem line is dropped?) and you need hardware flow control sometimes (you always need flow control, either soft or hard). Of course, you need three data signals. That's seven or eight signals depending on whether dsr and cd have different characteristics. I can get along without ring indicator, speed, and busy out, but there are those who will have difficulty without those signals. Could we at least agree on the need for connect/disconnect and hardware flow control handshaking? If they could give us that much we could build most of our terminal clusters and modem pools and host front ends. Of course, there will be problems with "normally on" versus "normally off" and toggle times (oops, the vax missed the toggle, sorry your session is still open), but that's why we have to get away from RS232 eventually. Kent England, Boston University
sean@cadre.dsl.PITTSBURGH.EDU (Sean McLinden) (10/19/88)
In article <417@wasatch.UUCP> haas@wasatch.UUCP (Walt Haas) writes: >Right now I have a Micom/Interlan NTS-100 downstairs to evaluate. Forget it! We have one of these (obtained from Black Box) and the software is ancient. Their implementation of telnet is poor and they don't support two way ports (which would allow you to dial in or out). You have to disable the modem talk modes because they interfere with the telnet protocol (when will somebody fix this). Most of all, the support (which used to be quite good with this company), really stinks. What would be ideal is a server which had downloadable software and a standard cpu (like a 68000), which would allow you to write your own code and load it. That way you could support SUPDUP, telnet, ROSE, or any old protocol that you like. In the meantime, get LSI-11s and do it yourself. Sean McLinden Decision Systems Laboratory
dyer@arktouros.MIT.EDU (Steve Dyer) (10/19/88)
May I suggest that people remove comp.unix.aux from their followups
to this subject, since there's little here to do with A/UX.
---
Steve Dyer
dyer@arktouros.MIT.EDU
dyer@spdcc.COM aka {harvard,husc6,ima,bbn,m2c,mipseast}!spdcc!dyerkeith@tarantula.spider.co.UK (Keith Mitchell) (10/21/88)
I am surprised to hear that the provision/non-provision of rlogin on terminal servers is a major issue. It seems to me that while rlogin does have some advantages over telnet, it is a protocol designed specifically for use between Unix systems. Terminal servers are usually not Unix systems, and so some of the assumptions which rlogin makes tend to break down. The two main advantages of rlogin over telnet are probably that of authentication and passing across of terminal type. For client use it is possibly reasonable to build these into a non-Unix system. However, when using the server as a milking machine, these advantages are lost, there being no defined mechanism for passing authentication and terminal type information across the serial lines. In any case, I have yet to see a Unix system with rlogin which does not support telnet too. Telnet also has the advantage of being an officially defined and well-documented protocol, which is more than can be said for rlogin. One approach is of course to have a terminal server which runs Unix, but I suspect supporting Unix (hardware, licensing etc) puts the per-box cost up enough that rather more lines are needed to keep the per-line cost down. Having to fit all these lines onto one server has the side-effect of restricting the number of control signals provided on each line. With SpiderPort, we go for a small, cheap unit with a smaller number (10) of lines, but with full bi-directional hardware flow and modem control signals on each line. We did not go for rlogin support, largely for the reasons detailed above. On the other hand, if rlogin's a big issue with users, and we've missed something, then I'd be interested to hear what. Keith Mitchell Spider Systems Ltd. Spider Systems Inc. 65 Bonnington Road 12 New England Executive Park Edinburgh, Scotland Burlington, MA 01803 +44 31-554 9424 +1 (617) 270-3510 keith@spider.co.uk keith%spider.co.uk@uunet.uu.net keith@uk.co.spider ...!uunet!ukc!spider!keith
haas@wasatch.UUCP (Walt Haas) (10/22/88)
In article <417@wasatch.UUCP>, I wrote: > 3com/Bridge loaned me a CS/1 for evaluation and it does the modem and flow > control fine. Unfortunately it doesn't support rlogin and refuses to ping > a multihomed host (like, for example, cs.utah.edu). I talked to the > software support guy at 3com/Bridge about this and his reply was that they > had no plans to support rlogin, and you shouldn't give two IP addresses > to the same host (!). So from that I think we can safely say that they > can't support their software. The reaction to this posting was quite interesting! Firstly I received a number of messages from 3com/Bridge people expressing concern that I did not feel I was getting the quality of support that they tried to provide. Clearly they are working hard to provide good support. However many people who responded did not understand what I expected rlogin to do, so let me clarify what it does in the cisco and Encore products. The user does *not* log in to the terminal server, the user merely specifes use of the rlogin protocol instead of the TELNET protocol. Rlogin has the advantage of making the terminal server much more transparent than a server running TELNET. Rlogin is the protocol of choice for users who have a choice. > Incidentally I wrote their President a letter asking him to please get > onto the Internet so I wouldn't have to play telephone tag for a week > at a time to talk to his guys. He never replied to the letter. Several people provided uucp paths to Bridge and/or 3com, but none knew of a username or alias set up to receive requests for service. One respondent said that their request to get connected to the Internet was being held in some sort of queue, but they expected to be connected soon. > Right now I have a Micom/Interlan NTS-100 downstairs to evaluate. Their > literature says it supports rlogin but I can't fine any sign of rlogin > in the actual firmware - plus there are a slew of obvious bugs. Probably > I just got an old copy of the firmware but their tech support guys aren't > returning phone calls - at least not with any degree of rapidity. The local rep finally got the current firmware out of them after two tries. I have it downstairs now and it does have some rlogin support, but there still seem to be a few problems. Perhaps I just haven't learned to configure it correctly yet. > I know somebody on the net posts from Interlan ... It was interesting to note that there was no response from Micom/Interlan protesting that they try hard to give good service. This is consistent with the way they don't answer phone calls. Be happy, don't worry -- Walt Haas haas@cs.utah.edu utah-cs!haas
hedrick@geneva.rutgers.edu (Charles Hedrick) (10/25/88)
The primary reasons for wanting rlogin in a terminal server are: - sending terminal type for hosts that don't yet support that via telnet (i.e. 4.2 based instead of 4.3 based) - better handling of ^S, ^O, etc. Rlogin has as provision for toggling local handling of things like ^S. When you enter emacs or something else where that is inappropriate, the host sends a message telling the terminal server to stop handling those things locally. Thus rlogin sessions tend to feel more transparent than telnet sessions. One can do better with telnet than is normally done by implementing telnet sync properly, but rlogin is still a bit more transparent. And of course more existing telnetd's don't generate telnet sync, so in practice rlogin is a big win for sites that don't want to put up their own telnetd. I don't know whether this is a big deal or not, but people who are very sensitive to how the terminal interface behaves may think so.
henry@utzoo.uucp (Henry Spencer) (10/25/88)
In article <10591.8810211408@brahma.cs.hw.ac.uk> keith@tarantula.spider.co.UK (Keith Mitchell) writes: >In any case, I have yet to see a Unix system with rlogin which does not >support telnet too. Telnet also has the advantage of being an officially >defined and well-documented protocol, which is more than can be said for >rlogin. One unfortunate problem is that Berkeley rlogin is definitely a better implementation than Berkeley telnet. If you compare sources, it's fairly obvious that rlogind is probably derived from telnetd, but various fixes and improvements in rlogind have not found their way back into telnetd. At least, not in the Sun sources that we have (VAXen are a vanishing breed around here and I don't have any convenient way to check out the current Berkeley sources). -- The dream *IS* alive... | Henry Spencer at U of Toronto Zoology but not at NASA. |uunet!attcan!utzoo!henry henry@zoo.toronto.edu
swb@DAINICHI.TN.CORNELL.EDU (Scott Brim) (10/25/88)
The telnet protocol being worked up in the IETF should be able to benefit from experiences with telnet, rlogin, supdup and more, and solve a bunch of these problems.
backman@interlan.UUCP (Larry Backman) (10/27/88)
In article <426@wasatch.UUCP> haas@wasatch.UUCP (Walt Haas) writes: > >> I know somebody on the net posts from Interlan ... > >It was interesting to note that there was no response from Micom/Interlan >protesting that they try hard to give good service. This is consistent >with the way they don't answer phone calls. > [] Keep those letters coming folks... We are now InterLAN, Inc; I have been feeding this sequence of postings to the new person in charge of support. His name is Steve Young, I thhink you can reach him at this machine (young@interlan) Larry Backman
efb@suned1.UUCP (Everett F. Batey II) (10/27/88)
Couldn't let be mention of the NTS100 TELNET / rlogin SERVERS. They do when
the rep finally gets you the current ROM pack. Then the puke from the factory
says you have to return it or pay for it again .. sure come see me .. and the
company attorney .. It works for me with modem inbound .. not so well but use-
able for outbound .. not UUCP. We have been pretty stable for nearly a year.
For outbound services you want only one service class per server as best I can
tell. They take some getting used to. Think I would prefer to LAT from a
DEC Server to a telnet capable VAX if dollars weren't binding condition.
MY QUESTION. We are on a site with a 192... address assigned. That is across
a MILnet gateway. To use my telnet / rlogin servers, must I consume some of
those 254 addresses? Is there a network legal way to be on another net number
in the 255.255.255. upper 24 bits? Which my local hosts can see and still
get helped NS from my local domain internal name server?
WHAT does every one else with multiple hosts and servers on a local ethernet
gatewayed to ARPA / Internet do to preserve host addresses with servers? Do
your servers telnet to folks across the gateway? We are still a way from
connected and I would appreciate some planning help .. thanks /Ev/
--
The_Main_User (So Calif SunLUG | Vta-SB-SLO-DECUS)
efb@elroy.JPL.Nasa.Gov sun!tsunami!suned1!efb efbatey@nswses.arpa
Statements, Opinions ... MINE ... NOT those of my US Employer lars@ACC-SB-UNIX.ARPA (Lars J Poulsen) (11/01/88)
> Date: 27 Oct 88 06:22:53 GMT > From: suned1!efb@elroy.jpl.nasa.gov (Everett F. Batey II) > Organization: NSWSES, Port Hueneme, CA > Subject: Re: tcp-ip terminal servers > References: <337@thor.wright.EDU>, <417@wasatch.UUCP> > > MY QUESTION. We are on a site with a 192... address assigned. That is across > a MILnet gateway. To use my telnet / rlogin servers, must I consume some of > those 254 addresses? A terminal server is a HOST, albeit a somewhat specialized one (i.e. it does perform all kinds of host services). A host must have an IP address. If your ethernet has a network number, the host must have an address with the address space of that network. Why would you (a) not want that ? (b) think this could be otherwise ? > Is there a network legal way to be on another net number > in the 255.255.255. upper 24 bits? Which my local hosts can see and still > get helped NS from my local domain internal name server? A terminal server does not have to be on the same network as the hosts it is communicating with. I.e. if your terminal server is on an ethernet connected to Milnet with a proper gateway, it can communicate with any host on the combined Internet, i.e. not just with your local machines but with any machines attached to MILnet, any machines attached to ARPAnet, any machines attached to NSFnet, any machines attached to the MIT campus net, etc. This is why we have IP in the first place. Thus, if you have multiple networks, you can attach terminal servers to whichever network you want, and they will still get to wherever you want to get to. However, it is a feature of IP routing, that when your packets move from one net to another, they do so at an IP gateway. Thus, you are imposing a processing load on the gateway node. This is not altogether desirable if the reason you moved the terminal ports off the bigger host in the first place was to save processing cycles on the bigger host. The location of your terminal server with respect to the name server is a slightly different issue. If the terminal server uses standard DOMAIN protocol, this runs on top of IP, so you can get name service from any host on the combined internet that has access to the information for your domain; however, you will usually (for reasons of performance and overhead avoidance) want to get it from a host as close to the terminal server as possible. > WHAT does every one else with multiple hosts and servers on a local ethernet > gatewayed to ARPA / Internet do to preserve host addresses with servers? > ... > efb@elroy.JPL.Nasa.Gov sun!tsunami!suned1!efb efbatey@nswses.arpa Numbers are fairly cheap. If you are planning to connect more than 254 hosts (including PCs an terminal servers) to your local network, then you should get a class B network instead of a class C network. This is MUCH friendlier to the world than to have multiple class C networks behind a gateway. / Lars Poulsen ACC Customer Service Advanced Computer Communications ("We make advanced computers communicate")