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!