Xref: utzoo comp.protocols.tcp-ip:4908 comp.unix.aux:446
Path: utzoo!utgpu!water!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!bloom-beacon!bu-cs!kwe
From: kwe@bu-cs.BU.EDU (kwe@bu-it.bu.edu (Kent W. England))
Newsgroups: comp.protocols.tcp-ip,comp.unix.aux
Subject: Re: tcp-ip terminal servers
Message-ID: <25470@bu-cs.BU.EDU>
Date: 18 Oct 88 17:22:55 GMT
References: <337@thor.wright.EDU> <417@wasatch.UUCP>
Reply-To: kwe@buit13.bu.edu (Kent England)
Followup-To: comp.protocols.tcp-ip
Organization: Boston Univ. Information Tech. Dept.
Lines: 51

In article <417@wasatch.UUCP> haas@wasatch.UUCP (Walt Haas) writes:
>I've been evaluating terminal servers and am not too pleased with the results
>so far.  The application I have in mind is a little different from the usual-
>I want to put a TCP/IP/Ethernet server back-to-back with a Zenith Z-LAN NCU
>so that users of the Z-LAN network can access Ethernet machines and
>vice versa.  Therefore the TCP/IP server must simultaneously provide both
>modem control and hardware flow control in both directions.  This rules out
>use of the cisco ASM and the Encore Annex, sigh, both of which look like
>good boxes in most other respects.
>
>So would all you folks with brilliant ideas about how to solve this
>problem mind coming out of the woodwork with your bright ideas?
>
	You are right about the products:  those that do good telnet
and rlogin don't understand serial lines and those that understand
serial lines (like U-B, Sytek, ...) don't do rlogin, domain name, etc
very well.

	I think part of the problem is trying to minimize the number
of pins supported.  The vendors want to use just four or five signals
when we need eight (but not always all at the same time).  Using eight
signals only allows six circuits on a 50 pin telco connector.  Using
six or fewer signals lets you put eight circuits on a 50 pin telco.  I
don't think a lot of the hardware design goes much beyond those decisions.

	It's my opinion that, at a minimum, your serial interface
needs to support a connect/disconnect hardware handshake and a
ready/clear flow control handshake.  connect/disconnect is usually
dtr/dsr or dtr/cd.  Hardware flow control is usually rts/cts.  But no
matter; you can always remap the flow control or conn/disconn signals
to other pins on your punchdown or in your RJ/DB adaptor.  The point
is that you need the functionality of handshaking upon connect and
disconnect (how many of you have systems that don't close sessions
when the modem line is dropped?) and you need hardware flow control
sometimes (you always need flow control, either soft or hard).  Of
course, you need three data signals.  That's seven or eight signals
depending on whether dsr and cd have different characteristics.

	I can get along without ring indicator, speed, and busy out,
but there are those who will have difficulty without those signals.
Could we at least agree on the need for connect/disconnect and
hardware flow control handshaking?  If they could give us that much we
could build most of our terminal clusters and modem pools and host
front ends.

	Of course, there will be problems with "normally on" versus
"normally off" and toggle times (oops, the vax missed the toggle,
sorry your session is still open), but that's why we have to get away
from RS232 eventually.

	Kent England, Boston University