Date   : Sun, 22 Aug 1982 1742-:00PDT
From   : William "Chops" Westfield <BillW@Sri-Kl>
Subject: Another lesson learned with MODEM 2

If your computer buffers input on an interupt basis, you must be
carefull to flush your buffers.  Consider the following Scenario:

An IBM PC as the local host, with its BASIC interupt driven COM: port.
A Tops-20 system on the other end with short timeouts.  For some
reason the tops-20 system times out twice (in my particular situation,
there was the initial NAK, plus a NAK from a timeout (BASIC is slow)).
There are now 2 NAKs in the buffer.  The IBM PC see the first NAK, and
transmits the first block.  Tops-20 responds with an ACK.  The IBM's
buffer now contains a NAK and an ACK.  The IBM see the NAK, and
retransmitts the first block.  Tops-20, already having received the
block, sends an ACK.  Because of the buffering, the IBM is responding
to ACK and NAKs that actually refer to ONE BLOCK EARLIER than the
current block.  As long as no further errors occur, everything works
out fine. If however, another error DOES occur, the IBM retransmitts
the WRONG BLOCK. Depending on how the tops-20 system handles this,
various things can happen (my tops-20 program sent an ACK and
discarded the block, since it was an unexpected block, casusing
the block to be lost from the destination file.  If your proram
checks to make sure that blocks arrive in uniformly ascending order, it will
probably abort).  The solution is to make sure the input buffer is
empty after each ACK or NAK is received.  PCNet and other protocols handle
this better by saying WHICH block they are acknowledging.

This sounds very much like the problem that RGF and BYTE describe.
Does LMODEM clear out its buffers ?

Enjoy
BillW