Xref: utzoo comp.mail.uucp:3727 unix-pc.uucp:194 comp.dcom.modems:4789 Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!uunet!samsung!gem.mps.ohio-state.edu!tut.cis.ohio-state.edu!ukma!david From: david@ms.uky.edu (David Herron -- One of the vertebrae) Newsgroups: comp.mail.uucp,unix-pc.uucp,comp.dcom.modems Subject: Re: UUCP Protocols, "efGxd" ... and a Telebit Trailblazer Question. Message-ID: <13216@s.ms.uky.edu> Date: 13 Nov 89 05:05:48 GMT References: <1009@icus.islp.ny.us> <1989Nov6.024128.1992@terminator.cc.umich.edu> <1014@icus.islp.ny.us> Reply-To: david@ms.uky.edu (David Herron -- One of the vertebrae) Organization: U of Kentucky, Mathematical Sciences Lines: 26 In article <1014@icus.islp.ny.us> lenny@icus.islp.ny.us (Lenny Tropiano) writes: >In article <1989Nov6.024128.1992@terminator.cc.umich.edu> honey@citi.umich.edu, >Peter Honeyman writes: >|>Lenny Tropiano writes: >... >What if one assumes they have RTS/CTS hardware flow control on both >end-points? Wouldn't that prevent against serial port overrun >problems with the modem sending too much to the system? Lenny ... Even if your hardware flow control works well (if memory serves right, the flow control is unidrectional only) you still have some sections of unprotected wire through which you can have noise come into the picture. The signals going through the phone wire do come out flow controlled and error corrected, but the tb's don't make any gaurantees beyond the phone wire (or, at any rate, some point in the wiring inside the box). Trust Peter ... not only does he know what he's talking about he's also fun at parties :-) -- <- David Herron; an MMDF guy <- ska: David le casse\*' {rutgers,uunet}!ukma!david, david@UKMA.BITNET <- <- New official address: attmail!sparsdev!dsh@attunix.att.com