Manual

16-2 Appendix F
Certain host software structures may be able to use Enq/Ack where they cannot conveniently
use Xon/Xoff, and vice-versa. For example, is the host software able to test whether an Xoff
character has been received, without actually hanging up waiting for one to arrive?
The Software Checking handshake should probably only be used as a last resort. Because of
the large number of characters which must be transmitted in each direction, the handshake
itself becomes the major burden on the RS-232C channel and on processor time at both ends
of the channel. The host must chunk the data as for the Enq/Ack handshake. In a
timeshared ("Big Computer") environment or a half-duplex modem environment where line
turnarounds are slow, the Software Checking handshake would probably be far too slow.
There are other factors to consider in choosing a handshake. Is handshaking software
already available? (Xon/Xoff is common.) Is vector throughput really important in your
application? How will it be affected by the handshake? (See Appendix E Speed
Considerations.) Does cable length dictate a low baud rate? If so, the number of characters
transmitted for handshaking becomes more important.
Does an "antagonistic" I/O driver or host programming language prevent the application
program from sending escape sequences? Does the driver send its own escape sequences
which interfere with the ones sent by the application, or create output conflicts? (See
ESC.E
in Chapter 6.) Is the driver software accessible for modification?