Xref: utzoo comp.sys.ibm.pc:30459 comp.periphs:1845 comp.misc:6386
Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!rutgers!tut.cis.ohio-state.edu!bloom-beacon!think!barmar
From: barmar@think.COM (Barry Margolin)
Newsgroups: comp.sys.ibm.pc,comp.periphs,comp.misc
Subject: Re: RS-232 protocol primer (long)
Message-ID: <22770@news.Think.COM>
Date: 22 Jun 89 18:19:36 GMT
References: <589@megatek.UUCP>
Sender: news@Think.COM
Reply-To: barmar@kulla.think.com.UUCP (Barry Margolin)
Followup-To: comp.sys.ibm.pc
Organization: Thinking Machines Corporation, Cambridge, MA
Lines: 54

In article <589@megatek.UUCP> hollen@megatek.UUCP () writes:
>			XON/XOFF
>  Therefore, on the terminal's
>side it is wise to send XOFF to the host when the terminal receive
>buffer is about 3/4 full.  This depends on the size of the buffer,
>the baud rate, and the latency in the host response to received 
>characters.  

Unfortunately, host latency can vary widely.  This is the most serious
problem with the XON/XOFF protocol; if the terminal assumes that the
host can respond to the XOFF faster than it actually can, the
terminal's buffer will overflow.  Some recent terminals allow the user
to set the XOFF threshhold in the SET-UP menu, but many terminals and
emulators don't.

My friends at school used to refer to XON/XOFF as the "help!  I'm
drowning" protocol; if the lifeguard doesn't notice you until you're
going down for the third time, you'd better hope he's a fast swimmer.

>			ETX/ACK
>  Once the host has sent the buffer, it must wait until the
>printer has processed every one of the characters until it can recognize
>the ETX and send and ACK.  This reduces the amount of overlap in sending
>that can occur.

High throughput is typically achieved with using ETC/ACK by employing
"double buffering".  This is a very simple form of what is known as
"windowing" in the context of network transport protocols.  If the
printer is believed to have an N-byte buffer, you send an ETX after
every N/2 bytes.  The sender is permitted to continue transmitting
when there is one ETX that hasn't been ACKed, but it stops sending
if it gets to the second ETX without having seen an ACK.

ETX/ACK with double buffering permits the most efficient use of the
bandwidth without running the risk of overflowing the printer's
buffer.

One problem I've seen with ETX/ACK, though, is that some printers
don't implement it very well.  We had an NEC SpinWriter that didn't
recognize ETX if it was inserted into the middle of an escape
sequence.  Our application used escape sequences heavily (it
implemented bidirectional printing by sending appropriate escape
sequences at the end of each line), while the ETX/ACK was implemented
in the bowels of the OS terminal driver, which knows nothing about
escape sequences sent by the caller.  From time to time the printer
would just stop until someone manually typed Control-F (ACK) on its
keyboard.


Barry Margolin
Thinking Machines Corp.

barmar@think.com
{uunet,harvard}!think!barmar