jantypas@hope.UUCP (John Antypas) (06/22/88)
Another question for the net? I'd like comments of any type concerning
terminal servers or muxes which dump material to the ethernet much like the
Encore Annex server or the U.B. system. Surely there must be others out
there.
John Antypas -- Soft21 --21st Century Software:
UUCP: {buita, crash, garp, killer, pyramid}!soft21!jantypas
{reed, sdeggo, ucsd!ucrmath, uport}!soft21!jantypas
Internet: jantypas%soft21.uucp@{garp.MIT.EDU, ucsd.EDU}
BITNET: jantypas@ucrvmsron@topaz.rutgers.edu (Ron Natalie) (06/28/88)
The UB server is an unmitigated piece of crap. We've been stuck with a number of these and we have had no luck getting any real level of support out of Ungerman/Bass. Their major problem is that the code is still buggy and the boxes just lock up from time to time. Also, there seems to be not much steam in their 286 or whatever processor they use and while the boxes run fine for one or two connections, three connections are miserable. There is still a bug with the way they handle telnet option negotiation and the UDP IEN-116 name server has a bug doing checksums. In addition the boxes will masquerade as other of your hosts due to an error in the ICMP code (they will occasionally claim in ARP messages to be other IP addresses than they really are). We're to the point of just heaving ours out the window. To run the UB server requires you buy one of their silly Network Management Stations and run a dedicated "Down Load Server." Fortunately they've recently moved this to SUN's rahter than burning IBM-PC's for the task. The software is very pricey compared to the cheap price for the box. On the other hand, the UB boxes are about the most programmable/configurable of any box on the market. We've looked at servers from CISCO and ANNEX. They are both about equivelent in their features. CISCO really excels in large (like 96 lines) applications in a single box. They are not as cost effective for 16 lines. They are planning to announce a new small product that will run the same software that will probably be pretty slick, but I only have rumors on the subject. We ran Bridge servers here for several years (actually some departments still do) and while they are not our first choice, they do work. My main observation on Bridge products in general is that they work as claimed, are really reliable, but they don't always get the protocols right. For example the terminal servers have some small problems in the options negotiation and they don't do ICMP at all. They also don't do Domain name server, but I here you can get that now, if you have a box with enough memory in it to run their new software. -Ron
eshop@saturn.ucsc.edu (Jim Warner) (06/29/88)
In article <Jun.28.11.38.38.1988.24031@topaz.rutgers.edu> ron@topaz.rutgers.edu (Ron Natalie) writes: >We ran Bridge servers here for several years... >My main observation on Bridge products in general is that they work >as claimed, are really reliable, but they don't always get the protocols >right. For example the terminal servers have some small problems in the >options negotiation and they don't do ICMP at all. They also don't do >Domain name server, but I here you can get that now, if you have a box >with enough memory in it to run their new software. We have a Bridge LS/1 with 64 ports. We are running their current software. It has the Domain name server with the ability to use an alternate if the primary is down. This all works quite well. Their current code (TCP 20000) also answers ICMP echo requests (ping) and accepts ICMP redirects. I had some difficulty with their telnet option negotiation, but the problem turned out to be that what they were doing was different than what 4.3BSD does, but still legal. My biggest complaint with the Bridge terminal server is that it cannot be configured to time out a terminal that has been inactive for longer than some threshold. Like Ron, I found that the box is very reliable. jim warner Univ of California, Santa Cruz
jqj@uoregon.uoregon.edu (JQ Johnson) (06/29/88)
In article <Jun.28.11.38.38.1988.24031@topaz.rutgers.edu> ron@topaz.rutgers.edu (Ron Natalie) writes: >The UB server is an unmitigated piece of crap. >... >We [also] ran Bridge servers here for several years ... >My main observation on Bridge products in general is that they work >as claimed, are really reliable, but they don't always get the protocols >right. For example the terminal servers have some small problems in the >options negotiation and they don't do ICMP at all. They also don't do >Domain name server, but I here you can get that now, if you have a box >with enough memory in it to run their new software. I second Ron's comments, though his Bridge/3Com observations are somewhat out of date. I would not recommend that anyone run the old Bridge software since the new stuff has been out for more than 6 months. Even on old small-memory CS-1s they've fixed their ICMP problems. The CS-200 (their best current product) running the current 20000 software seems to have very few IP-related problems and be very cost-effective for small clusters of lines. Remaining problems we have seen here: 1/ we're trying to track down what may be a bug in Bridge's name resolver code. What seems to be happening is that the CS200 occasionally sticks the address of an authoritative domain name server in its cache instead of the address of the host it requested. Anyone else seen this problem? (note we are currently not even sure the bug is in the CS200). 2/ very serious problem: Bridge servers can't be booted across gateways. That means in subnetted environments that you need to buy servers with floppy drives in them or put a boot server on every subnet that has terminal servers.
tjh+@andrew.cmu.edu (Tom Holodnik) (07/01/88)
We're really satisfied with the Encore Annex terminal servers. Typical
uptimes for these machines (in our environment) are about a month or more
(limited by the need to reconfigure and by the recent frequency of power
outages).
In terms of functionality, the IP/TCP implementation is pretty close to
4.3 BSD. The support software is designed to run on a variety of machine types
and flavors of Unix (including MACH, and Xenix). The operating software has
many useful features for maintenance and performance. A quick summary:
Subnet Routing
Domain Name Service
Lots of Security Options (user configurable)
Facility for crash dump recording.
High throughput (all 16/32 ports run at 9600 bps)
Good user interface
Easy installation
Good customer support
We're really impressed with these machines. A few years ago, the
Electrical and Computing Engineering Dept. had designed terminal servers that
were as good as anything then on the market (in some cases it was better). I
don't handle the business around here, but we saved quite a bit of money in
terms of man-hours and hardware in converting to Annexes.
Oh- I don't have any relation to Encore other than installing their
equipment and using it.
Tom Holodnik
Carnegie-Mellon Universitydavid@ms.uky.edu (David Herron E-Mail Hack) (07/02/88)
We're looking for terminal servers too. You wouldn't believe the thing
that we're replacing, but it *does* work.
Anyway. For some reason one of the ideas around here is that LAT
based servers (We'll be talking to Ultrix machines -- for some reason
we're ignoring the existance of a Sequent and Suns and 3b2's) will
be "better" in some way than a box providing TELNET type service.
Probably it's simply a matter of general inexperience on campus
with this sort of box. *I* don't want to get a LAT box because it
would tie us too closely with DEC.
Be that as it may. Do any of these boxes sufficiently emulate
being hardwired that one can believe that they're hardwired?
I know that with a real hardwired terminal, that the 4.3bsd rlogin
works well/fast enough that if "feels" like it's a hardwired terminal.
So *I* am ready to believe that one of these boxes doing rlogin
would "feel" right. The problem is convincing the others around me.
Just for jollies, do any of the 3rd party boxes support LAT?
I've been saving away messages about terminal servers for a long
time, so y'all don't need to give me any general information.
Thanx for any help y'all can provide me..
--
<---- David Herron -- The E-Mail guy <david@ms.uky.edu>
<---- ska: David le casse\*' {rutgers,uunet}!ukma!david, david@UKMA.BITNET
<----
<---- I'm not bad, I'm just coded that way!ron@topaz.rutgers.edu (Ron Natalie) (07/03/88)
Both CISCO and ANNEX support "rlogin" as well and it works just as nice (well maybe even better) than it does under BSD UNIX. Nearly all our UNIX terminals these days go through the terminal servers and we also use them for other machines such as VMS and IBM. The major problem with LAT, other than the fact that it only works with DEC computers, is that it will not go through any sort of Router (even a DEC one). This greatly diminishes its usefulness in a large network environment like ours. If you must have LAT, I here now there is a company called Xyplex that makes LAT servers that they've also hacked TCP into. -Ron
chris@mimsy.UUCP (Chris Torek) (07/03/88)
In article <Jul.2.22.15.15.1988.2756@topaz.rutgers.edu> ron@topaz.rutgers.edu (Ron Natalie) writes: >Both CISCO and ANNEX support "rlogin" as well and it works just as nice >(well maybe even better) than it does under BSD UNIX. Almost. The Annex rlogin, at least, still has the old 4.2BSD bug where output is flushed on any out of band data byte, rather than just those that specify output flushing. This is bad for Emacs, since flow control settings are controlled via out of band data. -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163) Domain: chris@mimsy.umd.edu Path: uunet!mimsy!chris
kwe@bu-cs.BU.EDU (kwe@bu-it.bu.edu (Kent W. England)) (07/05/88)
In article <9816@e.ms.uky.edu> david@ms.uky.edu (David Herron E-Mail Hack) writes: >Be that as it may. Do any of these boxes sufficiently emulate >being hardwired that one can believe that they're hardwired? > With one very important difference. A truly hardwired device may be able to operate without benefit of flow control of any kind. A networked terminal, in my experience, must always support flow control, even at speeds as low as 1200 bps. I have never been able to make a device that did not support flow control operate over a terminal server. Contention and lost packets... >I know that with a real hardwired terminal, that the 4.3bsd rlogin >works well/fast enough that if "feels" like it's a hardwired terminal. >So *I* am ready to believe that one of these boxes doing rlogin >would "feel" right. The problem is convincing the others around me. > I would be concerned on large model servers like the cisco. What happens if everybody is active at the same time? Do all 96 terminals operate at 9600 bps average throughput? There is work on SLIP support on terminal servers, although BU isn't running SLIP yet. I wonder how many SLIP ports a typical terminal server could support? Is SLIP more compute intensive than telnet? Kent England, Boston University
david@ms.uky.edu (David Herron -- One of the vertebrae) (07/06/88)
In article <23612@bu-cs.BU.EDU> kwe@buit13.bu.edu (Kent England) writes: >In article <9816@e.ms.uky.edu> david@ms.uky.edu (David Herron E-Mail Hack) writes: >>Be that as it may. Do any of these boxes sufficiently emulate >>being hardwired that one can believe that they're hardwired? >With one very important difference. A truly hardwired device may be >able to operate without benefit of flow control of any kind. A >networked terminal, in my experience, must always support flow >control, even at speeds as low as 1200 bps. I agree completely. Let me add that in my experience that most manufacturers assume that ^S/^Q flow control is enough. But that ^S/^Q is often WORSE than no flow control. The fact that I like Emacs is not an issue as I'm a relatively recent convert to that way of life, and the experiences I have about ^S/^Q predate my conversion to Emacs. ^S/^Q gets in the way too much. You can't run a file transfer protocol like UUCP or ?MODEM through such a line. You have constant problems with strange "lockups" on such lines, if a ^S happens at the right moment. etc. -- <---- David Herron -- The E-Mail guy <david@ms.uky.edu> <---- ska: David le casse\*' {rutgers,uunet}!ukma!david, david@UKMA.BITNET <---- <---- I'm not bad, I'm just coded that way!
ron@topaz.rutgers.edu (Ron Natalie) (07/06/88)
> A networked terminal, in my experience, must always support flow > control, even at speeds as low as 1200 bps. I have never been able to > make a device that did not support flow control operate over a > terminal server. Contention and lost packets... I have a Visual 200 on my desk which is as dumb as they come. It doesn't need anytype of flow control. Contention and lost packets have little to do with it. If you're talking about Ethernet there's more than enough bandwidth. Your statements are also a bit confusing. No body types at even 120 cps, so the flow control that is really necesary is at the host end. With TCP the server <-> host flow control is all ready managed by the TCP window. > I would be concerned on large model servers like the cisco. What > happens if everybody is active at the same time? Do all 96 terminals > operate at 9600 bps average throughput? Large model servers usually have larger scale processors. For example the CISCO terminal server runs a 68020 while most of the smaller ones use 8086's or 80186's. We don't expect our CISCO terminal servers to run 96 lines at 9600 all active, but we do expect them to run 64 and we haven't been proved wrong yet. The answer is that they get slower when you overload them, but of course, that makes less of an argument that the terminal needs flow control, not more. > There is work on SLIP support on terminal servers, although BU isn't > running SLIP yet. I wonder how many SLIP ports a typical terminal > server could support? Is SLIP more compute intensive than telnet? CISCO has SLIP, such that it is, on their servers. I can't tell you for sure but my guess is that while SLIP is more I/O intensive (theres actually protocol overhead running in both directions and if you have more than just a PC on the far side you've probaby got more than one connection going at a time), however compute intensity will be less. You're not using the TCP part of the server, you're just dumping IP packets into the IP portion directly. -Ron
hedrick@athos.rutgers.edu (Charles Hedrick) (07/06/88)
There are flow controls issues with using terminal servers. I'm not sure whether this message was unclear or I am just misreading it, but at any rate, let me say what our experience is. First, we normally run normal terminals without depending upon flow control. There are various reasons for this, of which network terminal servers are only one. (The original reason is that if you make the terminal generate xoff, Emacs users are constantly getting spurious search commands.) This is done by putting appropriate padding entries into the termcap terminal descriptions. If your terminal control codes are properly padded, then they will work on direct lines or terminal servers without any difference. The cases where flow control is needed are generally driving printers or similar devices. In that case, there is a potential problem, because the buffering delays introduce enough sloppiness in timing that you can't depend upon the host to respond to an xoff fast enough. Note that packet loss and network contention are not the issue. What causes the delay in response to xoff is the fact that network software tends to put lots of data in one packet, and to use multiple buffering. The result is that when the host senses an xoff, there is a lot of data already in its own output buffers, in packets on the network, in gateways, in terminal servers, etc. Even if the host stops sending data immediately in response to xoff, you'll see as much as several Kbytes of data that was already output. The simplest solution to this is to set things up so that the terminal server itself processes the xoff. In that case, things stop and start immediately, and in general work just like a hardwired line. This is a complete solution for printers and most other similar devices. The hard case is flow control for connections with humans on them. Note that we are talking only about the case where a human wants to stop output so it doesn't scroll off the screen. We are not talking about terminals that are too slow to keep up with output, since we've already solved that by padding. If you are willing to have ^S always stop output, there is no problem. Just have the terminal server do it locally, and everyhthing will work like a hardwired line. However there are programs like Emacs that expect to use ^S as a search command. So there are two possibilities. (We support both.) One is to use a protocol like rlogin, where the terminal server is told by the host when ^S should stop output and when it should act like a normal character. The other is to find some character other than ^S that isn't essential to Emacs or whatever similar applications your site runs. The terminal servers are set up to pause locally whenever they get that character. We use ^\ by default. (The user can change it.) I would not expect SLIP to be very different in overhead from normal terminal server traffic. It might be slightly slower, but in practice I suspect differences are more in the quality of the implementation (i.e. in how much optimization has been done) than due to inherent differences in the CPU requirements. The other difference is feel from a terminal server is also related to buffering on the network: ^C, ^O, etc. Most operating systems have control characters that tell it to start discarding output. For the same reason that the host can't immediately stop output when you type ^S, it can't immediately suspend output when you type ^O or ^C: a lot of it is already in flight. Both telnet and rlogin allow a host to send an "out of band" messge to the terminal server telling it to discard any data that is already in the pipeline. When this is implemented (it was not in 4.3 telnetd), you may see a few extra lines of output after a ^C, but little more than that. WIthout this mechanism, output can go on for pages after you have told it to stop. Even with the out of band support, users notice the extra few lines of output, but generally it doesn't bother people. It's important to bring these issues out because managers should know that switching from hardwired lines to terminal servers will not be totally transparent. In order to get good results, your host telnet software must be up to date. And even then, users will notice some slight changes in the way things behave, mostly in stoppping or suspending output. When people said that a terminal server felt just like a local terminal, I think what they were referring to was response time. That much is true. With a properly engineered network, you will not notice a slowdown in echoing. On the other hand, it does increase the number of things on which you are depending. Not only must the host be working, but the terminal server must be, and the network must be free of short-circuits, broadcast storms, etc. Inevitably there will be times when this is not the case, and you will see misbehaviors due to the network or terminal server. However serial interfaces are among the more failure-prone pieces of most hosts, so the overall reliability may not be decreased. (This is particularly true in multi-vendor situations. I think our overall quality of service to dialup users is better with terminal servers than in the days when we had many different machines, each with its peculiarities in modem control. However you should at least think about the implications before making any such change.
jerry@oliveb.olivetti.com (Jerry Aguirre) (07/06/88)
In article <Jul.2.22.15.15.1988.2756@topaz.rutgers.edu> ron@topaz.rutgers.edu (Ron Natalie) writes: > >If you must have LAT, I here now there is a company called Xyplex >that makes LAT servers that they've also hacked TCP into. Not quite. The last I heard what they supported was not LAT. It does talk to VMS systems but I think you install some host software they provide. This isn't really much different because if you want to run LAT you have to buy the LAT software from DEC and install it. Of course I hear several people are working on LAT support so this may have changed.
loverso@encore.UUCP (John Robert LoVerso) (07/06/88)
In article <12297@mimsy.UUCP> chris@mimsy.UUCP (Chris Torek) writes: > The Annex rlogin, at least, still has the old 4.2BSD bug > where output is flushed on any out of band data byte, rather than > just those that specify output flushing. Well, that was true the last time I talked to Chris about it. This has since been "fixed in 4.0", to coin a phrase. R4.0 (of the Annex boot image) is now in beta, and fixes this age old bug in rlogin, mostly by using 4.3BSD rlogin. On top of that, most of 4.3BSD telnet is also included. In article <frob@andrew.cmu.edu> tjh+@andrew.cmu.edu (Tom Holodnik) writes: > In terms of functionality, the [Annex] IP/TCP implementation is pretty > close to 4.3 BSD. Not to let the cat out of the bag, but it *is* the 4.3BSD code. John R LoVerso Encore Computer Corp loverso@multimax.arpa, encore!loverso
chris@mimsy.UUCP (Chris Torek) (07/07/88)
>In article <12297@mimsy.UUCP> I wrote: >>The Annex rlogin, at least, still has the old 4.2BSD bug >>where output is flushed on any out of band data byte, rather than >>just those that specify output flushing. In article <3290@encore.UUCP> loverso@encore.UUCP (John Robert LoVerso) writes: >Well, that was true the last time I talked to Chris about it. This has since >been "fixed in 4.0", to coin a phrase. ... Great! Now when can we get 4.0? :-) [We have a fair number of Annex boxes on campus: something like 7 for the CS department facilities= (faculty, staff, and grad students) alone, and more for other departments in the building: around twice that total. I have no idea how many there are in the CS Center (undergrads) but they are there as well. They generally work well, and we like them; the flush bug has been the only real thorn.] >On top of that, most of 4.3BSD telnet is also included. This is substantially better than the old telnet, though it has been improved again since then. (But since we never use telnet. . . .) -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163) Domain: chris@mimsy.umd.edu Path: uunet!mimsy!chris
david@ms.uky.edu (David Herron -- One of the vertebrae) (07/07/88)
In article <Jul.5.18.38.50.1988.26125@topaz.rutgers.edu> ron@topaz.rutgers.edu (Ron Natalie) writes: >> A networked terminal, in my experience, must always support flow >> control, even at speeds as low as 1200 bps. I have never been able to >> make a device that did not support flow control operate over a >> terminal server. Contention and lost packets... >I have a Visual 200 on my desk which is as dumb as they come. It doesn't >need anytype of flow control. Contention and lost packets have little >to do with it. If you're talking about Ethernet there's more than >enough bandwidth. Your statements are also a bit confusing. No body >types at even 120 cps, so the flow control that is really necesary >is at the host end. With TCP the server <-> host flow control is all >ready managed by the TCP window. Oh puhlease ...when will people STOP making bogus assumptions like this? There has been more pain and grief done by people like us because of the assumption that the only thing you could possibly want to hook up to a serial port is a terminal or printer! Sheesh! There are many instances where you want to hook something other than a terminal to a serial port, be it directly on a host or on some ethernet based server. Flow control (hardware level, not software level as in ^S/^Q) is just as badly needed on transmit as on receive. A case in point: SLIP service in a terminal server. If you have SLIP service there, it's very easy for the attached computer to be generating large amounts of data and to start needing flow control on the INPUT side of the serial port just as badly as it is needed on the OUTPUT side. But there are other cases. Connecting Unix machines up to such a thing with the idea of either doing call-out to other places or doing uucp transfers. Attaching modems to a terminal server and then having other sites call in through those modems -- especially if you have TElebit's. -- <---- David Herron -- The E-Mail guy <david@ms.uky.edu> <---- ska: David le casse\*' {rutgers,uunet}!ukma!david, david@UKMA.BITNET <---- <---- I'm not bad, I'm just coded that way!
bdale@hpcsrc.HP.COM (Bdale Garbee) (07/07/88)
>There is work on SLIP support on terminal servers, although BU isn't >running SLIP yet. I wonder how many SLIP ports a typical terminal >server could support? Is SLIP more compute intensive than telnet? > > Kent England, Boston University In general, SLIP should be less compute intensive than telnet for a terminal server, since there are only packet routing decisions to be made, and the IP frames don't have to get unpacked and processed, etc. However, SLIP links tend to have heavier data flow than a Telnet session, so they are likely to impose more load on a terminal server than a Telnet session. Overhead per unit data is typically lower, but there's more data... Bdale, N3EUA bdale%hpcsla@hplabs.hp.com
ron@topaz.rutgers.edu (Ron Natalie) (07/08/88)
> Oh puhlease ...when will people STOP making bogus assumptions like this? If you'd read the damn context you quoted, you'll see that it isn't a bad assumption to make. I had also stated that reasonable terminal servers have enough power to statistically multiplex your terminal traffic onto the Ethernet without doing flow control. This was a direct counter to the claim that the original poster could not even get 1200 baud to work. For devices that are going to run a protocol that isn't internally regulating like TCP, you will need flow control. Good devices support many different types of flow control. For example, the CISCO termianl servers have a couple of different flavors of software and hardware flow control. If you are spec- ing performance on a box and you are hooking terminals to it, then why buy enough capacity for 9600 baud bidirectional traffic? > A case in point: SLIP service in a terminal server. > > If you have SLIP service there, it's very easy for the attached > computer to be generating large amounts of data and to start needing > flow control on the INPUT side of the serial port just as badly > as it is needed on the OUTPUT side. If you are trying to run slip "through" a telnet connection you're going to lose anyway. It's braindamanged. Why not buy a terminal server that does SLIP? Then you won't need flow control at all, any more than IP is doing for you anyway. -Ron
hobson@porthos.rutgers.edu (Kevin Hobson) (07/08/88)
Didn't include the whole message. He is referring Ron Natelie response. >In article <9870@g.ms.uky.edu> david@ms.uky.edu (David Herron -- One of the vertebrae) writes: > There are many instances where you want to hook something other than > a terminal to a serial port, be it directly on a host or on some > ethernet based server. Flow control (hardware level, not software > level as in ^S/^Q) is just as badly needed on transmit as on receive. > > A case in point: SLIP service in a terminal server. ... > But there are other cases. Connecting Unix machines up to such a thing > with the idea of either doing call-out to other places or doing uucp > transfers. Attaching modems to a terminal server and then having other > sites call in through those modems -- especially if you have > TElebit's. We are using Telebit modems (using every baud rate) for uucp (outgoing /incoming) through terminal servers. We have also used SLIP. We've used terminal servers to connecting printers (line and/or laserwriters), modems, and machines not using TCP/IP. Before PRIME finish their telnet/ftp implementation, we use Bridges boxes. Data General version of telnet/ftp was too flakey (bounce at least every other day) for us, so we hooked the serial ports to Bridge boxes. Until we get networked TCP/IP printers (Imagen postscript) or write decnet print-command (for DEC LPS40) for non-DEC machines, we just run the printers off a terminal server. Any unix or VMS can print to these printers without using line drivers or nearby minicomputer because distance limitation. These printers run at 9600 baud or better. We like Cisco terminal servers, but Bridge and Encore have the ability to do some and/or all these functions. Ron just answer the question. He didn't go into details. -- Kevin Hobson - Telecommunications Analyst IV ARPANET: hobson@rutgers.edu Rutgers, The State University UUCP: {backbone}!rutgers!hobson P.O. Box 879, CCIS, Hill Center, Busch Campus BITNET: hobson@cancer.BITNET Piscataway, N.J. 08855-0879 PHONE: (201) 932-2351
david@ms.uky.edu (David Herron -- One of the vertebrae) (07/08/88)
In article <Jul.7.13.51.48.1988.18949@topaz.rutgers.edu>, ron@topaz.rutgers.edu (Ron Natalie) writes: > > Oh puhlease ...when will people STOP making bogus assumptions like this? > If you'd read the damn context you quoted, you'll see that it isn't a > bad assumption to make. Sorry, I just get a little hot-headed when it comes to flow control. I've had so many problems in dealing with it in the past ... hmmm.. It does seem that we are talking about slightly different things. I took the person you were responding to to be talking about flow control at the serial port. But as I recall, you were talking mainly about flow control in the TCP code, which doesn't make sense to me because TCP is flow controlled all by itself. I was of course referring to flow control at the serial ports. For me, the magic words to get me boiling is something to do with it not being necessary to have equivalent flow control in both directions. There is no good reason why it should be unequally implemented! All it does is save a few pennies here and there in parts cost (i.e. there isn't any logic on the host to pass the flow-control from the other device down to the software), and later cost people real problems when they don't hook a terminal to the serial port like the designer thought. Then there are a number of terminals which NEED flow control just to operate at 9600 baud. Ones which I'm familiar with are vt100's and the AT&T 5620 (I happen to have had one of each on my desk at various times over the last year). Any micro running a terminal emulator falls into this category. Hmm, wellll, my Amiga seems to do a real good job of keeping up at 9600 baud ... so maybe not ANY micro. [I started to write out some problems we've had here related to UB NIU-180's we've got and have tried to use in a number of ways. But it started to get rather long ... if someone is interested in seeing a horror story I can post it.] -- <---- David Herron -- The E-Mail guy <david@ms.uky.edu> <---- ska: David le casse\*' {rutgers,uunet}!ukma!david, david@UKMA.BITNET <---- Vnend would make a perfect toon! <---- He already cleans up after himself like one!
kwe@bu-cs.BU.EDU (kwe@bu-it.bu.edu (Kent W. England)) (07/09/88)
>[I started to write out some problems we've had here related to UB > NIU-180's we've got and have tried to use in a number of ways. But > it started to get rather long ... if someone is interested in seeing > a horror story I can post it.] >-- ><---- David Herron -- The E-Mail guy I don't want to jump in the middle of a flame, but I can say that my original comments about needing serial port flow control at slow baud rates on networked terminal servers was based, like Dave Herron's, on U-B NIU-180s running XNS over broadband. I had a consistent problem dropping characters on terminal to modem connections over the U-B NIU "dataswitch" (ie through a pair of terminal servers) when the devices did not have flow control enabled. I had no problems when flow control was enabled, but I always lost characters when there was no flow control. I do not have enough experience with Annexen or cisco's or even U-B Access/One to know if better hardware and software eliminate this problem, but I think they would only improve the situation, not eliminate lost characters. If you care to comment on why you think that flow control should be required or not be required on serial ports running through terminal server pairs or serial ports connected to telnet servers, please go ahead. In my opinion, there is always the risk of temporary network errors or buffer overflow that requires flow control capability on the serial devices to avoid loss of characters (assuming no error recovery protocol in the attached devices and error recovery in the terminal servers). I think this applies at all baud rates, even as low as 1200. Kent England, Boston U
ron@topaz.rutgers.edu (Ron Natalie) (07/09/88)
Yes, and real VT100's will not be happy with anything less than local ^S/^Q flow control on a terminal server or anything else. Actually, neither am I. I nearly never use "more", prefering to be quick on the ^S key. I leave my terminal server set (on my line at least) in ^S/^Q local mode. When you use rlogin, you get this automatically. -Ron
ron@topaz.rutgers.edu (Ron Natalie) (07/09/88)
Anybody who bases their observations on terminal servers on any Ungergmann/Bass product is screwed up. Ungermann/Bass is in my one of the most screwed up companies in the data communication industry. It has been my misfortune to be stuck with nearly $40,000 of their stuff that was sold to my predecessor by one of their former (and extremely voluptuous) salesperson. I've now had to deal with four different UB salesman and about six different service engineers with no resolution. All this equipment does not work, nor has it ever work (we have a collection of PC-NIU's and NIU-180's). Escalation by calling a customer service director in their home office in California, nor the complete slime of a district manager in New York has been completely worthless. The only help I've ever got out of UB was that one of their engineers, who is very sharp, was fixing the bugs I was reporting and sending me fixed up disks under the table. The rest of the corporation found out that he was actually being useful and slapped his hands and keep him from sending me any more floppies. Even so, the last disk he sent me last October, is still a more correct version of the software than what they are currently shipping to customers. -Ron
sob@watson.bcm.tmc.edu (Stan Barber) (07/09/88)
In article <3960@saturn.ucsc.edu> eshop@saturn.ucsc.edu (Jim Warner) writes: >My biggest complaint with the Bridge terminal server is that it >cannot be configured to time out a terminal that has been inactive >for longer than some threshold. Like Ron, I found that the box >is very reliable. > >jim warner >Univ of California, Santa Cruz The 3-com Communications Servers will timeout a user when configured as a HOST port after a certain period of inactivity. It should be possible to add such an ability to the server since the code is there for the host side. Hopefully, 3com is reading this and will think about doing it for release 20010 [by Arthur C. Clarke?]. Stan internet: sob@tmc.edu Baylor College of Medicine Olan uucp: {rice,killer,hoptoad}!academ!sob Barber Opinions expressed are only mine.