Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!masscomp!ocpt!tsdiag!hico2!sonyd1.Broadcast.Sony.COM!blilly.UUCP!bruce
From: bruce@balilly (Bruce Lilly)
Newsgroups: unix-pc.uucp,comp.sys.3b1
Subject: Re: more on the HFC saga
Message-ID: <1991May24.235005.14690@blilly.UUCP>
Date: 24 May 91 23:50:05 GMT
References: <103431@becker.UUCP> <1991May22.042143.13250@fithp> <1991May24.054753.28804@colnet.uucp>
Sender: usenet@blilly.UUCP (News Administrator)
Organization: Bruce Lilly, Flushing, NY
Lines: 24
Nntp-Posting-Host: balilly

In article <1991May24.054753.28804@colnet.uucp> res@colnet.uucp (Rob Stampfli) writes:
>
>  "However, in the full-duplex variations, RTS/CTS is used as a kind of
>  throttle.  The signals have the opposite meanings than they do for
>  half-duplex communications.
>
>  "When a DTE device is able to accept data, it asserts pin 4, Request to
>  Send.  If the DCE is ready to accept data, it asserts pin 5, Clear to
>  Send.  If the voltage on RTS or CTS drops at any time, this tells the
>  sending system that the receiver is not ready for more data...
>
>This seems to agree with what the poster says above.  Could it be that
>AT&T implemented the half-duplex standard, which deals only with DTE to DCE
>flow control?  I have always assumed HFC worked like what was described as
>the full-duplex variation, but maybe this is not the case.   It would be
>interesting to hear from someone more well versed in the implementation
>of the standards.

HFC in the 3b1 (at least with 3.51m) works as described above
(full-duplex). There is, however a TCSRTS ioctl which only works in
half-duplex.

-- 
	Bruce Lilly		blilly!balilly!bruce@sonyd1.Broadcast.Sony.COM