Path: utzoo!utgpu!water!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!mailrus!rutgers!topaz.rutgers.edu!ron
From: ron@topaz.rutgers.edu (Ron Natalie)
Newsgroups: comp.dcom.lans
Subject: Re: Terminal servers over ethernet?
Message-ID: 
Date: 7 Jul 88 17:51:49 GMT
References: <320@ucrmath.UUCP>  <3960@saturn.ucsc.edu>  <9816@e.ms.uky.edu> <23612@bu-cs.BU.EDU>  <9870@g.ms.uky.edu>
Organization: Rutgers Univ., New Brunswick, N.J.
Lines: 30

> 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