kwe@bu-cs.BU.EDU (kwe@bu-it.bu.edu (Kent W. England)) (07/14/88)
In article <Jul.8.16.50.39.1988.19402@topaz.rutgers.edu> ron@topaz.rutgers.edu (Ron Natalie) writes: >Anybody who bases their observations on terminal servers on any >Ungergmann/Bass product is screwed up. > [flames regarding U-B performance deleted] Well, I won't dispute the fact that I am screwed up, but I will dispute the basis of that observation :-) U-B terminal servers running on U-B developed XNS-based protocols work well. U-B's handling of serial port handshaking and special quirks of specific terminals (like HP) is very good. The virtual circuit software works well and the broadband option was quite valuable at one time (still is). U-B's commitment to telnet and TCP/IP is uneven. The PC software is ahead of the NIU software and U-B backed out of development of IP routers, although there are still some running at the New Jersey Institute of Technology on jvnc-net, I believe. I assume that Ron's flame was based on hard experience with the first release of telnet software on the NIUs. That frustration is well earned. I reserve judgement on the current release called "TCP/IP Release 16" (to coincide with [XNS] Release 16 in name convention). Please don't label me a U-B apologist, I can flame on about U-B with the best of anyone, but I am not stupid or screwed up for having recommended, used, or even liked U-B products. Find me a better [any!] broadband terminal server in the 1984 timeframe. (Hey, anyone can find a better terminal server in the 1988 timeframe, that's not a really tough trick :-) One thing the world could use right now is a definitive evaluation matrix/document that we could use to rank and select all the umpteen telnet servers out there. Anyone done it yet? I even heard today that Sytek (remember the king of broadband networking back in, what, 1982??) has a telnet server!! So, does anyone have a full-up telnet server evaluation document that they would care to share? I'm looking for something that would let one evaluate a server initially on paper; weed out the misfits (like anyone who doesn't support icmp :-) and select a reasonable few that could be scrutinized in detail. How does one know ahead of time that the Sytek telnet server isn't the greatest thing since sliced bread? Kent England, Boston University
ittai@vx2GBA.NYU.EDU (Ittai Hershman) (07/14/88)
Like Ron, we too worked with the engineer who got his hands tied up. Fortunately, by the time we got our last "under the table" release, most of the problems had been resolved -- we are now running the original release plus about 10 patches. Given the change in heart at UB Corporate, I decided not to get involved in beta testing the second round... The only real problem remaining for us with the original release is that a) it only uses IEN116 name service, and b) you can only point to one name server, which means there is no redundency for name service. Also, the configuration process is half-assed -- there are three different databases with three different configuration programs, which don't interact well. It is virtually impossible to update certain types of information, without completely deleting and re-creating the box's configuration file. And to make matters worse, the configurations (which are downloaded) are keyed to the box's serial number -- which is hardwired -- so if a box dies and has to be replaced, you have to muck about with configurations. Alas, the engineer Ron and I dealt with only worked on the TCP innards and couldn't help with the configuration issues at all. We are using these boxes almost exclusively with broadband connections, where you really have to lock-in with a single vendor. For ethernet connections, if we had the need, I would probably buy cisco... -Ittai XYZZYGLORP
vixie@palo-alto.DEC.COM (Paul Vixie) (07/16/88)
In a previous lifetime, I worked with quite a lot of U-B equipment :-). The thing I liked about it was that it did full-duplex RTS/CTS hardware handshaking. This means that you can take an NIU-130 or -180, hook Telebit Trailblazer + modems up to it (with a special U-B adaptor cable), tell the TT+ to use full-dup RTS/CTS, and never worry about ^S/^Q again. It's great for a modem which sometimes runs in UUCP spoof mode (which needs no flow control because it's a windowing lock-step) and normal 'tip' which needs lots of ^S/^Q because the modem is usually talking to you at a different baud rate than its carrier calls for. The NIU-DMF32 (yes, I know that DEC makes a product by this name, but this is an Ungermann-Bass NIU-DMF32 I'm talking about) is a pretty clean way to attach a Unibus machine to a U-B network, except that the one part of the DEC DMF32 interface spec that U-B didn't implement was FIFO. (Note that this would have been trivial since they get packets with several characters in them when the speed is high enough.) The CPU gets an interrupt for each and every character received over a UB NIU-DMF32, and the driver is _not_ optimized for this case because (1) real DMF32-type devices have FIFO's, and (2) U-B hadn't thought of or heard of Telebit modems when they designed their NIU-DMF32. I've wondered if the NIU-130/180 were talking telnet to a DEUNA, whether it would perform better than when it speaks XNS to an NIU-DMF32. I suspect that some problem in telnet would make UUCP work poorly. Note: DEC doesn't know I'm sending this, so don't go suing them. -- Paul Vixie Digital Equipment Corporation Work: vixie@dec.com Play: paul@vixie.UUCP Western Research Laboratory uunet!decwrl!vixie uunet!vixie!paul Palo Alto, California, USA +1 415 853 6600 +1 415 864 7013