From: utzoo!decvax!harpo!floyd!vax135!lime!houxe!houxi!npois!ucbvax!ARPAVAX:C70:info-cpm Newsgroups: fa.info-cpm Title: Another lesson learned with MODEM 2 Article-I.D.: ucb.1825 Posted: Sun Aug 22 18:36:34 1982 Received: Thu Aug 26 01:49:46 1982 >From BILLW@Sri-Kl Sun Aug 22 18:36:24 1982 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