more on the HFC saga

[Rob Stampfli]

>Well, sort of...The place where HFC on the UNIXPC really works is when your
>PC can send chars out faster than the remote modem can handle them.  For
>instance, if either the DCE-to-DCE speed or the DCE-to-DTE speed on the far
>end are less than the host DTE-to-DCE speed, then the modems will apply
>HFC and the UNIXPC will properly halt data transmission.  HFC does NOT
>seem to work for handling overflow on incoming PC ports.

The above comment seems to have the support of a number of people who have
played around with hardware flow control.  I was just perusing "Managing
UUCP and Usenet" by O'Reilly & Associates, and here is what they have to
say about this (brackets mine):

  "In the RS-232 standard, [ hardware ] flow control is defined only for
  half-duplex connections -- that is, for connections in which data can be
  transmitted only in one direction at a time.  However, the standard has
  been adapted, de-facto, for full-duplex communications as well.

  "In the half-duplex standard, the DTE [ computer ] asserts RTS when it
  wants to send data.  The DCE [ modem ] replies with CTS when it is ready,
  and the DTE begins sending data.  Unless RTS and CTS are both asserted,
  only the DCE can send data.

  "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.

PS:  The short excerpt from "Managing UUCP and Usenet" is typical of the
calibre of information contained in this publication.  I would recommend it
highly to anyone owning a Unix-PC.  It is indeed the UUCP "bible".
-- 
Rob Stampfli, 614-864-9377, res at kd8wk.uucp (osu-cis!kd8wk!res), kd8wk at n8jyv.oh