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
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
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