casey@gauss.llnl.gov (Casey Leedom) (07/24/90)
We have a rack of eight (8) high speed modems (Telebit T2500s). We're
looking for a high performance terminal server to hang these guys off
of.
I'd appreciate any input anyone, vendor or user, may have on terminal
servers you think would satisfy our needs (or should be avoided at all
costs.) Thanks in advance. Please send email directly to
casey@gauss.llnl.gov. I will summarize all responses. (If you ask not
to be included in the summary I will respect your wishes.)
Casey
-----
ABSOLUTE MUSTS:
1. There shall be a minimum of eight (8) EIA232 serial interfaces
and one (1) Ethernet interface.
2. Serial interfaces shall handle at least 38.4K bits/second on all
lines. If two terminal servers are equivalent in other features,
the one with the highest throughput (serial and Ethernet) will be
selected.
3. Serial interfaces shall support hardware modem control (DTR/CD)
and hardware flow control (RTS/CTS) simultaneously. (I.e don't
even bother talking to me about the Xylogics Annex I or Annex
II. The upcoming Annex IIe does fulfill this requirement
according to their marketing blurbs.)
4. Shall be able to set up completely transparent 8-bit clean
connections. Yes, I realize that once such a connection is set
up the user wouldn't be able to escape out to other sessions.
Tough. Some of our applications need a clear channel.
5. Shall support TCP/IP telnet protocol. Shall support BSD rlogin
protocol.
6. Shall support passworded logins.
7. Shall use BIND for host name lookup.
8. Shall listen to RIP for routing information.
9. Shall respect ICMP redirects.
10. Shall incorporate Van Jacobson/Michael Karels TCP/IP
improvements: Slow start, retransmit timing, round trip timer,
etc.
DESIRED FEATURES:
11. SLIP (RFC1055). It would be nice to be able to dial in and set
up a SLIP connection. Preferably this should be implemented
either with subnetting (which means the terminal server will
have to participate in RIP) or by the terminal server proxy ARPing
for the remotely connected SLIP host.
12. SLIP with header prediction (RFC1144). More performance for the
above ...
13. SNMP monitoring/setup. It's the wave of the future. If SNMP
setup is provided for, it shall be possible to restrict such
SNMP access to a restricted list of authorized hosts.
14. Respond to ICMP ECHO requests. Useful for determining if the
terminal server is up, etc.
15. AppleTalk/EtherTalk gateway capabilities. We have a lot of
people with Macintoshes at home who would like to dial in and
simply become part of the AppleTalk community for file sharing,
printing, etc. If such a facility is offered, it shall use
AppleTalk Phase II. (And no, I don't want to hear about Shiva
modems. We already have one high speed modem pool I don't see
any point at all in fragmenting our resources. If we need more
modems, I just want to toss them on the already existing GENERAL
PURPOSE modem pool.)
16. More than eight (8) EIA232 serial interfaces. We might want to
expand the modem pool in the future.
17. Greater than 38.4K bits/second. Not likely, but with V.32bis
(probably coming within a year) and V.42bis modem standards,
we're looking at the possibility of achieving bursts of up to
57.6K bits/second over the phone lines. It sure would be nice to
be able to get at that bandwidth ...
18. Dialback capabilities. Since all modems tend to use at least
slightly different commands, etc. I don't hold out any hope
at all for this, but it would be nice.
19. LAT. We don't have any LAT users, but every once in a while we
run into one. We won't cry for a second if this isn't available.casey@gauss.llnl.gov (Casey Leedom) (08/09/90)
I'd like to thank everyone who responded to my posting regarding our need for a really good terminal server. We've decided on a Xylogics Annex IIe because it comes closest to satisfying all our needs. Note that this is not a negative comment on the other terminal servers described herein: our needs were very stringent (perhaps even excessive). I think that many people would be happy with other terminal servers. First, a copy of my original posting: | From: casey@gauss.llnl.gov (Casey Leedom) | | We have a rack of eight (8) high speed modems (Telebit T2500s). We're | looking for a high performance terminal server to hang these guys off | of. | | I'd appreciate any input anyone, vendor or user, may have on terminal | servers you think would satisfy our needs (or should be avoided at all | costs.) Thanks in advance. Please send email directly to | casey@gauss.llnl.gov. I will summarize all responses. (If you ask not | to be included in the summary I will respect your wishes.) | | Casey | | ----- | ABSOLUTE MUSTS: | 1. There shall be a minimum of eight (8) EIA232 serial interfaces | and one (1) Ethernet interface. | | 2. Serial interfaces shall handle at least 38.4K bits/second on all | lines. If two terminal servers are equivalent in other features, | the one with the highest throughput (serial and Ethernet) will be | selected. | | 3. Serial interfaces shall support hardware modem control (DTR/CD) | and hardware flow control (RTS/CTS) simultaneously. (I.e don't | even bother talking to me about the Xylogics Annex I or Annex | II. The upcoming Annex IIe does fulfill this requirement | according to their marketing blurbs.) | | 4. Shall be able to set up completely transparent 8-bit clean | connections. Yes, I realize that once such a connection is set | up the user wouldn't be able to escape out to other sessions. | Tough. Some of our applications need a clear channel. | | 5. Shall support TCP/IP telnet protocol. Shall support BSD rlogin | protocol. | | 6. Shall support passworded logins. | | 7. Shall use BIND for host name lookup. | | 8. Shall listen to RIP for routing information. | | 9. Shall respect ICMP redirects. | | 10. Shall incorporate Van Jacobson/Michael Karels TCP/IP | improvements: Slow start, retransmit timing, round trip timer, | etc. | | DESIRED FEATURES: | 11. SLIP (RFC1055). It would be nice to be able to dial in and set | up a SLIP connection. Preferably this should be implemented | either with subnetting (which means the terminal server will | have to participate in RIP) or by the terminal server proxy ARPing | for the remotely connected SLIP host. | | 12. SLIP with header prediction (RFC1144). More performance for the | above ... | | 13. SNMP monitoring/setup. It's the wave of the future. If SNMP | setup is provided for, it shall be possible to restrict such | SNMP access to a restricted list of authorized hosts. | | 14. Respond to ICMP ECHO requests. Useful for determining if the | terminal server is up, etc. | | 15. AppleTalk/EtherTalk gateway capabilities. We have a lot of | people with Macintoshes at home who would like to dial in and | simply become part of the AppleTalk community for file sharing, | printing, etc. If such a facility is offered, it shall use | AppleTalk Phase II. (And no, I don't want to hear about Shiva | modems. We already have one high speed modem pool I don't see | any point at all in fragmenting our resources. If we need more | modems, I just want to toss them on the already existing GENERAL | PURPOSE modem pool.) | | 16. More than eight (8) EIA232 serial interfaces. We might want to | expand the modem pool in the future. | | 17. Greater than 38.4K bits/second. Not likely, but with V.32bis | (probably coming within a year) and V.42bis modem standards, | we're looking at the possibility of achieving bursts of up to | 57.6K bits/second over the phone lines. It sure would be nice to | be able to get at that bandwidth ... | | 18. Dialback capabilities. Since all modems tend to use at least | slightly different commands, etc. I don't hold out any hope | at all for this, but it would be nice. | | 19. LAT. We don't have any LAT users, but every once in a while we | run into one. We won't cry for a second if this isn't available. And now the responses. My comments are contained in double brackets: [[ ... ]]. -------------------- Date: Mon, 23 Jul 90 21:47:15 EDT From: latzko@elbereth.rutgers.edu (Alex Latzko) I would suggest you take a look at the cisco sts-10x. If fulfills most if not all of you wants except for #18 dialback. If you can live w/o full hardware flow control it will do you fine. It can only be controlled by the remote end modem, but it has been my experience ( 16 V.32 and some tb+ ) you really can't overrun its input ports [[Our use is going to include a lot of file transfer and graphics -- including grabbing bitmaps from remote terminals. This combined with the fact that some times remote net connections hang for short periods of time almost demand flow control in both directions. I think it's somewhat silly to cheap out on providing one RS232 signal that's potentially so valuable when one of the major jobs of a terminal server is dealing with RS232 robustly ...]] -------------------- Date: Mon 23 Jul 90 19:24:35-PDT From: William "Chops" Westfield <BILLW@mathom.cisco.com> I think you are more or less out of luck. Here is the data for cisco terminal servers, though - I think we come close... [[And indeed they do. They came in second *for our use*. Thanks Bill for a great response!]] 1. There shall be a minimum of eight (8) EIA232 serial interfaces and one (1) Ethernet interface. Our 10 port box would suffice. 2. Serial interfaces shall handle at least 38.4K bits/second on all lines. If two terminal servers are equivalent in other features, the one with the highest throughput (serial and Ethernet) will be selected. This can be done. We don't have the guts to drive all the lines continuously and simultaneously at 38.4kpbs (this would be asking quite a lot - 80k interrupts/second!) [[Yes, it is and I don't think anyone's terminal server that I got information on could handle it. I had to ask though!]] A larger chassis (eg 16 or 32 lines) can take a 30 MHz 68020 processor, which might do that. It would be expensive. We do have enough umph in the small box to run all ten lines at somewhere between 9600 and 19200, although I don't know the exact rate. Isn't this about the speed trailblazers run at? [[Trailblazers yes, Telebit T2500s [current PROMs] yes. I haven't seen the new 6.00 PROMs yet, but they're almost sure to go up to 38.4Kbps because of the V.42bis support.]] 3. Serial interfaces shall support hardware modem control (DTR/CD) and hardware flow control (RTS/CTS) simultaneously. (I.e don't even bother talking to me about the Xylogics Annex I or Annex II. The upcoming Annex IIe does fulfill this requirement according to their marketing blurbs.) We support DTR/CD and CTS simultaneously. This is enough for the modem to flow control the terminal server. Typically, there is no need for flow control in the other direction - the terminal server has a full page interrupt level buffer, and is pretty quick... [[See comments above on Alex Latzko's letter. Full flow control was one of the reasons we ended up deciding on the Annex IIe over the Cisco. For those whose needs aren't quite as demanding as ours, the Cisco would probably be a fine choice.]] 4. Shall be able to set up completely transparent 8-bit clean connections. Yes, I realize that once such a connection is set up the user wouldn't be able to escape out to other sessions. Tough. Some of our applications need a clear channel. Doable. BREAK can still be used as an escape character. It would be a minor software modification to support 8bit clean + BREAK transparency. [[Not having BREAK be transparent shouldn't be a major problem since it's not clear what data character should be transmitted across an rlogin/telnet session in response to it. I suppose the terminal server could send a settable interrupt character with the TCP URGENT or OUT OF BAND bit set ... Whatever. Other terminal servers described below are also not transparent to BREAK.]] 5. Shall support TCP/IP telnet protocol. Shall support BSD rlogin protocol. 6. Shall support passworded logins. 7. Shall use BIND for host name lookup. 9. Shall respect ICMP redirects. Does all of these. 8. Shall listen to RIP for routing information. This is contrary to the recommendations of the hosts requirements RFC, and we have no plans of doing it. We do support "proxy arp", and are planning on support for a router discovery process. [[We've had this argument with Cisco before, so I won't go into it in too much depth. The name of the game is interoperability. RIP *is* bad. So what? It's in use in too many places (including here) to ignore. Cisco would make a lot of customers happy if they'd just give in and add RIP support to their products. You'll be able to take it out again in a couple of years when the customer base needing it dies away. This is something that Cisco has spent more time and effort fighting than would have been required to have implemented it and generated good customer vibes. This was another reason why we chose the Annex IIe over the Cisco.]] 10. Shall incorporate Van Jacobson/Michael Karels TCP/IP improvements: Slow start, retransmit timing, round trip timer, Has karn/jacobson retransmit timing and round trip timer. Slow start is not particularly applicable to terminal servers. Our ACK/WINDOW/Segment size strategy is compatible with this algorithm (watch out for terminal servers that advertise very small windows or segment sizes!). [[Some of our people will be dialing in to the terminal server and then connecting up to hosts all across the InterNet (one of the reasons we want passworded logins.) If we're doing file up loading, won't slow start be applicable? I'm very vague in this area, so I might be totally out to lunch.]] DESIRED FEATURES: 11. SLIP (RFC1055). It would be nice to be able to dial in and set up a SLIP connection. Preferably this should be implemented either with subnetting (which means the terminal server will have to participate in RIP) or by the terminal server proxy ARPing for the remotely connected SLIP host. We do the latter. We invented the concept. Addresses can be selected by the user, and are subject to authentication. 12. SLIP with header prediction (RFC1144). More performance... We are thinking about this one. So far, there wouldn't be much for us to talk to. The same is true of PPP, in its various incarnations. 13. SNMP monitoring/setup. It's the wave of the future. If SNMP setup is provided for, it shall be possible to restrict such SNMP access to a restricted list of authorized hosts. Done. 14. Respond to ICMP ECHO requests. Useful for determining if the terminal server is up, etc. Done. Also has built in PING command and TRACEROUTE capability (available from "enabled" mode) and extensive debugging facilities. You can also telnet into the terminal servers and issue any commands (fully implemented pty equivalents, with access control and login capability, of course.) 15. AppleTalk/EtherTalk gateway capabilities. Aysnc Appletalk support is something under consideration. 16. More than eight (8) EIA232 serial interfaces. We might want to expand the modem pool in the future. 3 models available now: 10 ports, 16-32 ports, 16-96 ports. The 16-32 port box with 32 ports is about the same price/line as the 10 port box, and you could get that 30 Mhz 68020 I was talking about. It is worth noting that our 10 port box is running out of room for new software features. Things "under consideration" may not make it onto that hardware platform. You can alway use extra ports for local terminals or async printers... 17. Greater than 38.4K bits/second. Not likely, but with V.32bis (probably coming within a year) and V.42bis modem standards, we're looking at the possibility of achieving bursts of up to 57.6K bits/second over the phone lines. It sure would be nice to be able to get at that bandwidth ... Hmm. There is some small chance that we could support a top speed other than 38.4. Not much. We would have to see more demand for it. For quite a while, I'd expect "burst of 57.6k" to get smoothed out to less than 38.4k average, by the modems. In order to get much use out of that sort of speed, you are probably talking about applications where average throughput is more important than burst throughput anyway. [[I'm sure that you're right. It was a fantasy desire.]] 18. Dialback capabilities. Since all modems tend to use at least slightly different commands, etc. I don't hold out any hope at all for this, but it would be nice. Under consideration. You can go a long way by toggling DTR and supporting "ATDTphonenumber"... 19. LAT. We don't have any LAT users, but every once in a while we run into one. We won't cry for a second if this isn't available. LAT is available now. Other intersting things available now or soon: ============================================= Extended security features: support for full audit trail (including connections) from login to logout. Per-user access-lists. SLIP allowed only for certain users. unix wtmp format accounting output. Interfaces other than ethernet (token ring, sync serial) Separate access control for incoming and outgoing connections. "one word" connection capability. Other things under consideration: ================================= XRemote: NCD's scheme for compressing X packets (similar to Jacobson TCP compression.) Use X terminals at home. TN3270: Talk to IBM systems. Security: kerberos, "smart card" security services. -------------------- From: Pushpendra Mohta <pushp@CERF.NET> Date: Mon, 23 Jul 90 19:53:48 PDT Organization: CERFnet, La Jolla, CA In a word , get the cisco terminal server. For routing needs get the TRouter product. [[Never heard of the ``TRouter product.'' What is it and what does it have to do with a terminal server??]] -------------------- From: Bob Stewart <stewart@xyplex.com> Date: Tue, 24 Jul 90 09:37:08 EDT {Fair warning: I'm an architect-type engineer who doesn't work directly on terminal servers, so I can be amazingly ignorant of practical details.} You should probably take a look at the Xyplex terminal server. It's good, but I know it doesn't meet all your requirements. Some it may meet in the future, some probably never. A guy I just talked to said he doesn't believe there is one that has all you want. [[Probably not, but that's why I sent a note out describing the features we wanted.]] I know we don't listen to RIP. There is a significant portion of the Internet community that believes that is absolutely a wrong thing to do (balanced by a group that believes it is necessary...). We support rlogin, Telnet, binary mode, LAT, SLIP, Domain, SNMP, etc. [[See comments above on Bill Westfield's letter.]] Our 16-port unit has an aggregate character throughput of about 21K char/sec, which won't run 8 38.4K ports flat out. I know we're working on software performance improvements, but at some point it takes hardware changes. We don't have both modem control and hardware flow control at the same time. We're considering it. We believe the DECserver 300 has the performance and the hardware signals, but it doesn't have Telnet. To remain competitive, that means we probably have to meet those capabilities when we believe they're going to support Telnet. If any of this sounds interesting, you can call 508-264-9900, tell them where you are and they'll fix you up with anything from glossy brochures to a glossy salesman. Our Marketing people have some say as to what Engineering builds, and they do respond to pressure from customers. -------------------- From: rls@apd.net.com (Richard Siegel) Date: Tue, 24 Jul 90 08:38:38 PDT Organization: Network Equipment Technologies I used to be the product manager for the T2500 when I worked at Telebit, so I guess I may have some credibility :-) I now work for N.E.T., which, among other things makes some good terminal servers! If I can send you a whole set of data, but I guess the first question is: is this just for TCP/IP or is it for a general DECNET type environment. Currently we have quite a few (non-LAT) DEC environment terminal servers, with plans to get into the TCP/IP market later this year. Let me know what your needs are, and I can connect you with one of our sales people. [[We're interested in TCP/IP and only passingly interested in LAT. Richard realized this after rereading my original posting and followed up his original response:]] I reread the full text of your needs (should have done that before my first mail!), and I think we will probably have something you'd like later this year, but your immediate needs may be met by someone like Datability's Vista box. They are in New York, I think the number is (212) 807-7800. [[I sent off for information on this, but never received anything. I guess some companies just don't like selling things ...]] -------------------- From: telebit!cec@uunet.UU.NET (Cerafin E. Castillo) Date: Tue, 24 Jul 90 12:25:17 PDT Organization: Telebit Corp., Sunnyvale CA 94089 > 10. Shall incorporate Van Jacobson/Michael Karels TCP/IP > improvements: Slow start, retransmit timing, round trip timer, > etc. > >DESIRED FEATURES: > 11. SLIP (RFC1055). > > 13. SNMP monitoring/setup. It's the wave of the future. If SNMP > setup is provided for, it shall be possible to restrict such > SNMP access to a restricted list of authorized hosts. You're asking for quite a lot. The Annex IIe is the best for the dial-up IP connectivity you want since it include VJ SLIP (CSLIP) AND PPP in a future upcoming revision of code. SNMP is already there. The only other terminal server I know of which comes close is the one offered by Cisco. -------------------- From: bob@MorningStar.Com Date: Tue, 24 Jul 90 10:47:00 EDT DESIRED FEATURES: 11. SLIP (RFC1055). 12. SLIP with header prediction (RFC1144). You might as well also spec PPP (RFC1134) while you're at it. Most of them will be doing it within a few months anyway. [[You're probably right. But since this isn't going to be a formal spec/bid process, I'll just have to remember to ask. So far, I don't think that any of the terminal servers I've received information on implement PPP yet. I can't tell for sure because I didn't ask explicitly for PPP and all I've received are volunteered notes that some are considering it, etc.]] -------------------- From: daniel@nstn.ns.ca (Daniel MacKay) Date: Thu, 26 Jul 1990 14:35:50 -0300 I highly recommend the Xylogics Annex IIs. They're well-built, tech support is great, prices are great, and they're very, very smart. -------------------- From: powell@wraith.wtp.contel.com (Mike Powell "CFS Net Ops) Date: Fri, 27 Jul 90 10:48:17 EDT Organization: Contel Federal Systems Try cisoc STS-10 10 ports all of what you need MSM 32 ports all of what you need and the ASM 32 port min 96 max all of what you need. -------------------- From: uunet!dciem!gandalf!carr@lll-winken.llnl.gov (Dave Carr) Date: Fri, 27 Jul 90 10:22:44 EST [[This was a response I wasn't exactly prepared for. I think this is far more than what we're interested in, but someone will probably find the very comprehensive description of the Gandalf Switch products interesting in any case ... It looks like anyone interested in supporting hundreds of dialins should take a serious look at this.]] We make a full line of terminal servers which can support from 8 to 1920 users. The larger model, STARMASTER, is a data switch with integrated terminal servers. Our lower cost entry level switch, ACCESS SERVER, handles from 8 to 64 users. Both product lines support: (a) Dumb subscriber cards (Time division multipled); (b) Intelligent subscriber cards; (c) Wide Area cards (stat-mux); (d) LAT Interfaces; (e) TCP/IP Interfaces; In addition, they support switching, contention, modem pools, etc, all the things one expects from a data switch. We are a multi-national company with revenues around $170,000,000, direct sales and support (enough of the sales junk). > ABSOLUTE MUSTS: > 1. There shall be a minimum of eight (8) EIA232 serial interfaces > and one (1) Ethernet interface. We can support from 8 to 1920 interfaces. We can support multiple Ethernet, Stat-Mux interfaces. Unsure about exact number, but more than 32. > 2. Serial interfaces shall handle at least 38.4K bits/second on all > lines. If two terminal servers are equivalent in other features, > the one with the highest throughput (serial and Ethernet) will be > selected. This is a slight problem. Currently we only go to 19200 bps. However, we do customer specials. There exists a customer special to support 38400 bps. It will probably have to be ported to the latest release. Also, the gateway channel cards would need modifications. Don't get too worried about specials. We do lots! Contact a Gandalf Sales person, and he will write up a special request and get a quote. > 3. Serial interfaces shall support hardware modem control (DTR/CD) > and hardware flow control (RTS/CTS) simultaneously. (I.e don't > even bother talking to me about the Xylogics Annex I or Annex > II. The upcoming Annex IIe does fulfill this requirement > according to their marketing blurbs.) Not sure on this one. It would have to be one of our intelligent subscriber cards. Check with Sales. > 4. Shall be able to set up completely transparent 8-bit clean > connections. Yes, I realize that once such a connection is set > up the user wouldn't be able to escape out to other sessions. > Tough. Some of our applications need a clear channel. No problem. In fact, subscriber could use BREAK or DOUBLE BREAK to either disconnect or WINK to another session. We support 4 alternate sessions per subscriber via WINK. > 5. Shall support TCP/IP telnet protocol. Shall support BSD rlogin > protocol. Yes. > 6. Shall support passworded logins. To the data switch I presume. Yes. Per subscriber, service, etc. > 7. Shall use BIND for host name lookup. Yes. > 8. Shall listen to RIP for routing information. Yes. > 9. Shall respect ICMP redirects. Yes. > 10. Shall incorporate Van Jacobson/Michael Karels TCP/IP > improvements: Slow start, retransmit timing, round trip timer, > etc. Yes. > DESIRED FEATURES: > 11. SLIP (RFC1055). It would be nice to be able to dial in and set > up a SLIP connection. Preferably this should be implemented > either with subnetting (which means the terminal server will > have to participate in RIP) or by the terminal server proxy ARPing > for the remotely connected SLIP host. Supports SLIP, but do not know to what degree. > 12. SLIP with header prediction (RFC1144). More performance for the > above ... No. Not in current release. > 13. SNMP monitoring/setup. It's the wave of the future. If SNMP > setup is provided for, it shall be possible to restrict such > SNMP access to a restricted list of authorized hosts. No. I believe the direction here is towards ISO (CMIP/CMOT). It too is not yet supported. We have network management via RS-232. > 14. Respond to ICMP ECHO requests. Useful for determining if the > terminal server is up, etc. Yes. > 15. AppleTalk/EtherTalk gateway capabilities. We have a lot of > people with Macintoshes at home who would like to dial in and > simply become part of the AppleTalk community for file sharing, > printing, etc. If such a facility is offered, it shall use > AppleTalk Phase II. (And no, I don't want to hear about Shiva > modems. We already have one high speed modem pool I don't see > any point at all in fragmenting our resources. If we need more > modems, I just want to toss them on the already existing GENERAL > PURPOSE modem pool.) No support for APPLETALK. > 16. More than eight (8) EIA232 serial interfaces. We might want to > expand the modem pool in the future. No problem. Up to 1920. > 17. Greater than 38.4K bits/second. Not likely, but with V.32bis > (probably coming within a year) and V.42bis modem standards, > we're looking at the possibility of achieving bursts of up to > 57.6K bits/second over the phone lines. It sure would be nice to > be able to get at that bandwidth ... We support 64 Kbps SYNCHRONOUS only, and only on point-to-point connections. The gateway card would need special s/w to support 64 Kbps. > 18. Dialback capabilities. Since all modems tend to use at least > slightly different commands, etc. I don't hold out any hope > at all for this, but it would be nice. YES! Chargeable option however. > 19. LAT. We don't have any LAT users, but every once in a while we > run into one. We won't cry for a second if this isn't available. YES! We have LAT gateway cards. Actually the same card as Ethernet. Great for sparing cards. Now, I don't work in the data switch/terminal server area any more, so my information may not be accurate. Best to check with our sales office. The STARMASTER offers great connectivity, more so than typical terminal servers. I take it from your address, you are in California. Here's our 2 offices in California. 1065 East Hillside Blvd, Suite 300, Foster City, CA 94404 (415) 571-6100 1 Newport Place, Suite 800, Newport Bch. CA 92660 (714) 752-8181 Or, e-mail me with specific questions and I'll try and get the answers right from the engineer. -------------------- From: Neil Gorsuch <uninet!neil%zardoz.uucp@ICS.UCI.EDU> Date: Sat, 28 Jul 90 16:16:16 PDT Organization: Uninet Peripherals, Santa Ana, CA, USA [[This looks like a very interesting approach, but I have yet to hear back on a list of questions I had. I'll try to remember them here and insert them for your reference.]] This is a little different that what you were probably thinking, but we have a SCSI based serial port expansion unit that could hang off of something like a diskless SLC, or even for that matter, an old 3/50. For more information, call (800)433-6784 and ask for marketing. A big advantage is that it uses the tty drivers already in the workstation and can therefore do a lot of stuff that ethernet terminal servers can't do. Someone here could even probably arrange an eval unit if you wanted to try it out. I seem to recall someone saying that you have almost a 1,000 Sun 3's lying around, maybe this would be a good use for one. [[It is different and since UNIX tty drivers are typically pretty bad, we're a little leery. I'm working to have hardware flow control made a standard part of the BSD tty driver which should improve the situation tremendously. I think that recent versions of Sun's OS tty drivers support hardware flow control so this may not be such a bad solution -- except that I think we want a little more oomph than a Sun 3/50 ... :-) Which versions of SunOS does this device work with and which versions support *REAL* RTS/CTS hardware flow control? The tty(4) manual page from SunOS 4.0.3c seems to imply that CRTSCTS just causes the tty driver to make RTS follow CTS which isn't at all what we want.]] >ABSOLUTE MUSTS: > 1. There shall be a minimum of eight (8) EIA232 serial interfaces > and one (1) Ethernet interface. Yep [[non-disclosure information deleted]]. > 2. Serial interfaces shall handle at least 38.4K bits/second on all > lines. If two terminal servers are equivalent in other features, > the one with the highest throughput (serial and Ethernet) will be > selected. Current model, 30,000 characters (not bits) per second. Next month's model, over 100,000 characters per second. Baud rates to over 150K baud. [[Is this synchronous or asynchronous???]] > 3. Serial interfaces shall support hardware modem control (DTR/CD) > and hardware flow control (RTS/CTS) simultaneously. (I.e don't > even bother talking to me about the Xylogics Annex I or Annex > II. The upcoming Annex IIe does fulfill this requirement > according to their marketing blurbs.) We already support ALL model signals, including flow control on ALL modem signals. Including CD, RTS CTS, DTR, RTS. > 16. More than eight (8) EIA232 serial interfaces. We might want to > expand the modem pool in the future. [[non-disclosure information deleted. Essentially ``in progress.'']] > 17. Greater than 38.4K bits/second. Not likely, but with V.32bis > (probably coming within a year) and V.42bis modem standards, > we're looking at the possibility of achieving bursts of up to > 57.6K bits/second over the phone lines. It sure would be nice to > be able to get at that bandwidth ... The only reason we stop at 150K baud is that the driver chips we picked on the first model start looking like triangle waves above that. We will also be shipping synchronous versions/expansion upgrades that go up to European T1 speeds. [[Neil included large chunks of my posting points and fundamentally said the following:]] Whatever you can put in Sunos 4.1 or whatever else workstation you use. We currently support Sun's, Solbournes, DECstations, VAXstations, Aviions. IBM 6000, HP, and NeXT ports are in progress. [[That is, anything that the host OS supports can be made to work. Thus listening to RIP, Domain service, passworded logins, etc. are all host OS questions.]] -------------------- From: Robert Claeson <prc@erbe.se> Date: Tue, 31 Jul 90 08:06:44 GMT [[Note that Robert is *NOT* an employee of Xylogics. I had to ask him because his review of the Xylogics Annex IIe's capabilities was so glowing ... :-)]] The Annex IIe from Xylogics. > ABSOLUTE MUSTS: > 1. There shall be a minimum of eight (8) EIA232 serial interfaces > and one (1) Ethernet interface. The Annex IIe has 16 or 32 RS423/RS232C serial interfaces, one parallel (Centronics and Dataproducts, software selectable) and one Ethernet or Token Ring interface. > 2. Serial interfaces shall handle at least 38.4K bits/second on all > lines. If two terminal servers are equivalent in other features, > the one with the highest throughput (serial and Ethernet) will be > selected. All serial ports can be individually configured with speeds from 50 up to 38400 bps. Our experience is that the Annex IIe has enough power to drive all lines at the top speed. > 3. Serial interfaces shall support hardware modem control (DTR/CD) > and hardware flow control (RTS/CTS) simultaneously. (I.e don't > even bother talking to me about the Xylogics Annex I or Annex > II. The upcoming Annex IIe does fulfill this requirement > according to their marketing blurbs.) The Annex IIe (it's not upcoming, it's already here) supports DTR/DCD/RTS/CTS simultaneously on all serial ports. > 4. Shall be able to set up completely transparent 8-bit clean > connections. Yes, I realize that once such a connection is set > up the user wouldn't be able to escape out to other sessions. > Tough. Some of our applications need a clear channel. Supported in the Annex IIe. Users can use the BREAK key to escape out to the command level of the terminal server. > 5. Shall support TCP/IP telnet protocol. Shall support BSD rlogin > protocol. [[Redundant information from earlier letters deleted.]] Both are supported, complete with all options (except for X Display Location). > 16. More than eight (8) EIA232 serial interfaces. We might want to > expand the modem pool in the future. 16 or 32 serial interfaces available. The Annex 3 will have from 8 to 64 (expandable/reconfigurable) serial ports. > 17. Greater than 38.4K bits/second. Not likely, but with V.32bis > (probably coming within a year) and V.42bis modem standards, > we're looking at the possibility of achieving bursts of up to > 57.6K bits/second over the phone lines. It sure would be nice to > be able to get at that bandwidth ... 38.4 Kbps is the maximum in the Annex IIe. Don't know about future Annex models, though... > 18. Dialback capabilities. Since all modems tend to use at least > slightly different commands, etc. I don't hold out any hope > at all for this, but it would be nice. Not supported. We use modems with built-in dial back capabilities. > 19. LAT. We don't have any LAT users, but every once in a while we > run into one. We won't cry for a second if this isn't available. The Annex IIe will support both TCP/IP and LAT later this year. It's a software-only upgrade. [[And in response to a letter I wrote Robert:]] From: Robert Claeson <prc@erbe.se> Date: Tue, 31 Jul 90 20:15:12 MDT : Thanks for the comprehensive answer to my posting. (Do you work for : Xylogics?) No. : Since you mentioned the Annex III, Really, Annex *3*. They will switch from Roman numerals to Arabic ones with the Annex 3. : do you know what time frame is on availability and what major : additional features it will have with respect to the Annex IIe? Just : curious. Oh well... The one thing that I know is that it will have two slots into which one can plug various cards. There will be cards with 8, 16 or 32 serial ports to start with. All with full modem control, of course. That's about what I know. : I'm planning on cutting an order for an Annex IIe within about two : weeks if I can convince management to come up with the money. I convinced our management by referring to other Annex sites. The Annex has a tremendously high availability (ours have never failed), and the best network functionality and administration I've seen. The new software (5.0.3) supports a macro/menu system, SNMP and a bunch of other neat stuff. In other words, the Annex'es has paid for themselves long ago when compared with cheaper terminal servers. Another thing is that Xylogics has a commitment to LAT and OSI networking, with the best TCP/IP on the market currently available. Of course, simultaneous use of TCP/IP, LAT and OSI will be supported (according to the salesman I use to speak to). It seems like that one will need the Annex 3 to get OSI, though. The I, II and IIe models doesn't have enough CPU power and memory to cope with it (which makes me wonder how other terminal server vendors intend to put TCP/IP, OSI with CLNS, CONS, TP0, TP2, TP4, CMIP, VTP and possibly also LAT in the 512 K other use, and have it run by a cheap 16 bit CPU. I don't trust anyone but Xylogics when they say that OSI networking, especially when compared with TCP/IP, is a though application if one wants all the facilities required by GOSIP/SOSIP/CEN/CENELEC/CEPP or whatever it's called in each country. -------------------- From: Jack O'Neil <oneil@Xylogics.COM> Date: Tue, 31 Jul 90 20:08:09 edt From your posting, it looks like you don't think Annex IIe's are available. They had been in short supply but are available through our distributors now. Should you decide on an Annex, I know Andataco has the IIe. You can reach them at 619/453-9191.. -------------------- From: "Milo S. Medin" (NASA ARC NSI Project Office) <medin@nsipo.nasa.gov> Date: Tue, 07 Aug 90 18:01:21 +0100 Casey, I've been on travel for the past 2 weeks, so here's my comments on your note. You can probably guess what I'll say: ABSOLUTE MUSTS: 1. There shall be a minimum of eight (8) EIA232 serial interfaces and one (1) Ethernet interface. The Annex IIe certainly supports this. A new model is coming out soon as well, and it will have more ports at a lower price. 2. Serial interfaces shall handle at least 38.4K bits/second on al l lines. If two terminal servers are equivalent in other features, the one with the highest throughput (serial and Ethernet) will be selected. The IIe can certainly handle this. The new model is LOTS faster. 3. Serial interfaces shall support hardware modem control (DTR/CD) and hardware flow control (RTS/CTS) simultaneously. (I.e don't even bother talking to me about the Xylogics Annex I or Annex II. The upcoming Annex IIe does fulfill this requirement according to their marketing blurbs.) The IIe and the new product both support this. 4. Shall be able to set up completely transparent 8-bit clean connections. Yes, I realize that once such a connection is set up the user wouldn't be able to escape out to other sessions. Tough. Some of our applications need a clear channel. Yes, the Annexes let you do this. You can set up the box to do this. Even so that a connect on the port does a binary TCP open (not even telnet negotiation if you want). Break can be used to knock the user bak to the cli anyways. 5. Shall support TCP/IP telnet protocol. Shall support BSD rlogin protocol. Of course. And full telnet options as well! 6. Shall support passworded logins. You probably know about the security server. Not only can you prompt for anything you want, on port connection, or remote logon initiation, but also on in bound connection. And, you an encrypt the security server-annex transactions so that eaves droppers can't fake requests/responses. 7. Shall use BIND for host name lookup. Of course. And you can have 2 servers set up in case the first fails. It even uses the TTL values on the RR's to cache things. 8. Shall listen to RIP for routing information. Yes, and this can be disabled as well. 9. Shall respect ICMP redirects. Yes, and ages them if routing is enabled. 10. Shall incorporate Van Jacobson/Michael Karels TCP/IP improvements: Slow start, retransmit timing, round trip timer, etc. The latest annex code has the full 4.3 Tahoe TCP in it. Not 4.3 release, but Tahoe. DESIRED FEATURES: 11. SLIP (RFC1055). It would be nice to be able to dial in and set up a SLIP connection. Preferably this should be implemented either with subnetting (which means the terminal server will have to participate in RIP) or by the terminal server proxy ARPing for the remotely connected SLIP host. Yup. 12. SLIP with header prediction (RFC1144). More performance for the above ... This runs in house, but isn't the current release. Expect this and PPP support by InterOp... 13. SNMP monitoring/setup. It's the wave of the future. If SNMP setup is provided for, it shall be possible to restrict such SNMP access to a restricted list of authorized hosts. Yes, and you can set up various community names. I don't think you can provide a list of hosts to listen from only, but a weird community name can do most of what you want, without requiring host info to be kept in all the servers. 14. Respond to ICMP ECHO requests. Useful for determining if the terminal server is up, etc. Come come now, my dog does this right! 15. AppleTalk/EtherTalk gateway capabilities. We have a lot of people with Macintoshes at home who would like to dial in and simply become part of the AppleTalk community for file sharing, printing, etc. If such a facility is offered, it shall use AppleTalk Phase II. (And no, I don't want to hear about Shiva modems. We already have one high speed modem pool I don't see any point at all in fragmenting our resources. If we need more modems, I just want to toss them on the already existing GENERAL PURPOSE modem pool.) Yuk. There is a way to do this with a Unix program that you can get from Webster Computer Corp. and running rtelnet on the Unix system. This maps the annex RS232 port into a pty like /dev/tty1 or the such, so anything that you can do with an directly attached Unix RS232 port you can do with an Annex RS232 port. We're trying to support this at Ames, though Appletalk at 9600 is really going to be UGLY! A better way is to support Iptalk, and use a a device which talks to SLIP, and thus not have to deal with Appletalk at all in the server... 16. More than eight (8) EIA232 serial interfaces. We might want to expand the modem pool in the future. Well, it's hard to buy things for just 8 ports anyways. 17. Greater than 38.4K bits/second. Not likely, but with V.32bis (probably coming within a year) and V.42bis modem standards, we're looking at the possibility of achieving bursts of up to 57.6K bits/second over the phone lines. It sure would be nice to be able to get at that bandwidth ... I don't think you get any kind of good error rate here. Better to go with ISDN. The Xylogics people are working on serial sync capability too though. [[We can only hope that the people at Telebit are also working on this problem. Currently the T2500s only go up to 19.2Kbps but with V.32bis/V.42bis they're going to have to support at least 38.4Kbps (thus my requirement for 38.4Kbps.)]] 18. Dialback capabilities. Since all modems tend to use at least slightly different commands, etc. I don't hold out any hope at all for this, but it would be nice. Since the security server can also net management commands, you should be able to do this depending on how the modem is configured. We use this sort of thing now so that when a user signs on, the security server OK's him to connect to the annex, but also resets the remote slip address, so no matter what port he dials into, he gets the same address. This is pretty easy since you get the source code to the management utilities and the security server. 19. LAT. We don't have any LAT users, but every once in a while we run into one. We won't cry for a second if this isn't available. Also supported in the next release, with a LAT-TCP gateway. Bletch! In addition, the annex software slices bread, and I don't think anyone else has a Unix interface that makes people not have to learn yet another environment. We love 'em here. [[They certainly look like the ticket for us. I've asked for information on the upcoming Annex 3 to decide whether we want to wait for that, but since that's not an announced product, there's not much I'll be able to say in this summary about it, so I'll end things here. Besides, this is already much longer than it should be ... Casey]]
colin@array.UUCP (Colin Plumb) (08/10/90)
In article <66116@lll-winken.LLNL.GOV> casey@gauss.llnl.gov (Casey Leedom) writes: >[[Some of our people will be dialing in to the terminal server and then >connecting up to hosts all across the InterNet (one of the reasons we >want passworded logins.) If we're doing file up loading, won't slow start >be applicable? I'm very vague in this area, so I might be totally out to >lunch.]] No; slow start is only necessary if you are talking through a network substantially slower your packet generation capabilities. This applies to gatewaying between ethernets with an ARPAnet 57.6kbaud line, but not to a connection limited to 38.4kbaud, as you have. See Van Jacobsen's paper, "Congestion Avoidance and Control," Proceedings of the ACM SIGCOMM '88, August 1988 for pretty pictures. Basically, if you send all of a large window really fast, then the fast->slow gateway starts dropping packets really fast. -- -Colin