dorl@vms.macc.wisc.edu (Michael Dorl - MACC) (07/07/89)
I'm looking for recommendations for a terminal server to be used in reverse to front end a host computer. I'm interested in a box with... a small number of lines, say about 8. one that has static configuration memory. one that translates telnet session status to/from rs232 signals. A telnet session ought to cause DTR to come up. A drop of DSR from the host ought to terminate the telnet session. one that pools the rs232 under one id so that a telnet to the box hunts for an available rs232 port. Any recommendations or advice welcome. Thanks, Michael Dorl (608) 262-0466 fax (608) 262-4679 dorl@vms.macc.wisc.edu dorl@wiscmacc.bitnet
epsilon@wet.UUCP (Eric P. Scott) (07/10/89)
Yes, I have a recommendation: DON'T DO THIS. 16 reasons why "milking machines" are a bad idea: - The terminal server doesn't know where "information boundaries" are. It doesn't know when to push, it can't dynamically switch between character-at-a-time operation and intelligent forwarding. Remote echo performance suffers, or you generate a lot of unnecessary network traffic, or both. Local echoing is probably not a viable option. - Most telnet implementations do not negotiate baud rate information. Mismatches cause problems. Then again, who said the user side was a "real terminal" anyway? - You lose all useful telnet subnegotiation capability. - Unless you have hardware handshake, you tend to have transparency problems. - You might not be able to send BREAKs in both directions. - You may have flow control problems. - Interrupt characters don't take effect promptly. - It's difficult to do flushes. - You can't do reliable timed inputs. - The host machine doesn't get address information, making intrusion tracing difficult. - You only get telnet access, and possibly only incoming. - You are limiting yourself to a small, fixed number of sessions. - It costs more to do it this way--you are paying for two unnecessary serial interfaces per line. - On many machines serial I/O has significantly higher overhead than network service. - What happens if you get a "zombie line" on your host? Will incoming connections consistently hunt to the loser? - More intervening hardware => lower reliability => more downtime => higher maintenance costs -=EPS=-
dcrocker@AHWAHNEE.STANFORD.EDU (Dave Crocker) (07/11/89)
Coming from a standard, Arpanet, packet-switching-among-hosts orientation, I had a similar, negative view about milking machines. Imagine my surprise upon disccovering that the use of such a configuration is an integral part of an industry that has revenue in the range of $100M-$300M per year. (That's hundreds of millions of dollars.) All of the concerns and criticisms that were listed in the previous note are quite valid. However, some machines simply do not have a version of the desired protocol available. Further, some operations managers want all networking to be kept separate from the computational engine. (While this latter issue seems to be reduced, as host-integrated networking experience increases, the attitude has not disappeared.) Dave
hedrick@geneva.rutgers.edu (Charles Hedrick) (07/11/89)
I agree completely about not using milking machines. The
configuration is a pain and the neck, and results normally aren't as
good as buying TCP/IP software for the host. However sometimes there
is no choice. E.g. we have an HP 3000. Its TCP/IP is bad enough that
we can't depend upon it for our terminal access. I would guess that
there are a number of other vendors whose systems either don't have
TCP or where for one reason or another it is not feasible to use their
implementation. Actually most of our milking machine ports are on an
IBM-compatible mainframe. Good TCP/IP is now available for them, but
there are technical reasons why some of the subsystem on our machine
need to be accessed via real serial ports.
So I agree that it's not something I'm anxious to do. But there are
enough cases where we have to that I've put some time into making
milking machine service work as well as possible. This is on our
cisco terminal servers. (I believe that cisco supports most of these
features now, though probably not the ability to pad breaks.) Here
are some of the things that can be done to deal with some of the
problems that Eric mentions:
- The terminal server doesn't know where "information
boundaries" are.
In general you have to run milking machine configurations in character
at a time mode. Until the new "line mode telnet" is widely
implemented, host implementations won't be much better.
- Most telnet implementations do not negotiate baud rate
information. Mismatches cause problems. Then again, who said
the user side was a "real terminal" anyway?
You'll notice a relatively new telnet option for sending terminal
speed. We did this specifically for milking machines. Our terminal
servers now have an option that causes them to switch the baud rate to
match the other end. We had to do that because one system we were
front-ending couldn't do flow control. The usual strategy is to run
the milking machine ports at the highest speed used by the host and
depend upon flow control. However if you match the speed of the
connection and you have big enough buffers, it is possible to operate
without any flow control.
- Unless you have hardware handshake, you tend to have
transparency problems.
- You may have flow control problems.
Absolutely. It takes a lot of work on both the host's comm gear and
the terminal server to make things work transparently. This is not
for the faint of heart.
- You might not be able to send BREAKs in both directions.
And then again you might. We have no problem sending breaks, although
on one host that causes them to drop the next character after a break.
We had to implement an option in the terminal server that "pads"
breaks. I.e. we follow each break with a null.
- Interrupt characters don't take effect promptly.
- It's difficult to do flushes.
We added an option that allows the terminal server to flush. When it
sees a break it not only sends it to the host but does a flush and
telnet sync. I think we only support breaks, but it would be easy
enough to generalize it to recognize any character. The problem would
be that if you tried to use it for something like Unix or VMS, you'd
have no way of knowing whether the user had changed his break
character or was in Emacs. But the systems we're front ending don't
have such fancy terminal handling. So break is enough.BILLW@MATHOM.CISCO.COM (William Westfield) (07/14/89)
["-=EPS=-" says:]
Yes, I have a recommendation:
DON'T DO THIS.
16 reasons why "milking machines" are a bad idea:
First of all, let me agree with EPS and Chuck - reverse terminal
server connections are not a particurally wonderful way of connecting
things to a network. However, things are not necessarily as bad as
EPS makes out, especially if the "milking machine" the only
alternative you have for connecting something to the host. A lot of
the complaints made are generally true of network terminal access
(not restricted to "milking machines"). These include:
- You may have flow control problems.
- Interrupt characters don't take effect promptly.
- It's difficult to do flushes.
- You can't do reliable timed inputs.
- The terminal server doesn't know where "information
boundaries" are. It doesn't know when to push, it
can't dynamically switch between character-at-a-time
operation and intelligent forwarding. Remote echo performance
suffers, or you generate a lot of unnecessary network traffic,
or both. Local echoing is probably not a viable option.
Very few telnet implementations do any of this (although this will
hopefully change in the non-distant future). For a milking machine,
it may be impossible, rather than just not done, but this is a fine
distinction. Depending on the application, it may be possible to
configure the terminal server to be more intelligent (to know when
to "push", for example).
I have some other answers:
- You lose all useful telnet subnegotiation capability.
Which may not be supported by the originating host anyway, which may not
be applicable for the application.
- Unless you have hardware handshake, you tend to have
transparency problems.
Always true for any situation requiring flow control.
- You might not be able to send BREAKs in both directions.
This SHOULD work.
- You only get telnet access, and possibly only incoming.
This may be all you need.
- You are limiting yourself to a small, fixed number of
sessions.
This may be all you need.
- It costs more to do it this way--you are paying for two
unnecessary serial interfaces per line.
- More intervening hardware => lower reliability => more downtime
=> higher maintenance costs
- On many machines serial I/O has significantly higher overhead
than network service.
This all assumes that network service is available at a finite cost.
network access. I can assure you that if you have (say) a DEC-20
that already has serial lines, it is much cheaper to connect it
to a $3000 milking machine than to install an ethernet interface ($12000,
plus significant hardware work that may force you to change your current
configuration), plus TCP software ($5000, if you can find someone to sell
it to you, free from various other places, if you happen to know how to
build your own monitors from sources). And after you've spent your
$17K, the network support doesn't give you any additional telnet
functionality than the milking machine. Im sure that there are other
dinosaurs (obviously anything that doesn't run unix) in the same boat.
One of the things we use "milking machines" for internally at cisco
is to connect to the console ports of routers, csu/dsus, and so on,
so that we can access them form the network. A milking machine is
obviously adequate for this sort of use.
Bill Westfield
cisco Systems.
-------