Path: utzoo!attcan!uunet!lll-winken!lll-tis!helios.ee.lbl.gov!pasteur!ames!mailrus!tut.cis.ohio-state.edu!ukma!david
From: david@ms.uky.edu (David Herron -- One of the vertebrae)
Newsgroups: comp.dcom.lans
Subject: Re: Terminal servers over ethernet?
Message-ID: <9870@g.ms.uky.edu>
Date: 7 Jul 88 14:23:34 GMT
References: <320@ucrmath.UUCP>  <3960@saturn.ucsc.edu>  <9816@e.ms.uky.edu> <23612@bu-cs.BU.EDU> 
Reply-To: david@ms.uky.edu (David Herron -- One of the vertebrae)
Organization: U of Kentucky, Mathematical Sciences
Lines: 42

In article  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                         
<---- ska: David le casse\*'      {rutgers,uunet}!ukma!david, david@UKMA.BITNET
<----
<---- I'm not bad, I'm just coded that way!