Path: utzoo!utgpu!water!watmath!clyde!bellcore!rutgers!gatech!ncar!boulder!sunybcs!bingvaxu!leah!uwmcsd1!ig!agate!ucbvax!UCONNVM.BITNET!SEWALL
From: SEWALL@UCONNVM.BITNET (Murph Sewall)
Newsgroups: comp.sys.apple
Subject: Re:  EXEC-ing Sound Progs
Message-ID: <8806051659.aa16866@SMOKE.BRL.ARPA>
Date: 3 Jun 88 20:45:01 GMT
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The Internet
Lines: 50

>Just last night I had a similar problem downloading a file with
>Kermit 3.83.  Normally I have a clean phone connection and no retries
>are needed.  But last night I must of had a noisy phone connection
>because many retries were occurring.  When the packet was
>re-transmitted, Kermit did not throw away the bad packet.  Each time

Did it not discard ANY of the bad packets or only some of them (one
would have been enough to FUBAR the EXECUTIONER)?

>I attempted to EXEC the file after any retries had occurred, I got
>the "ERROR" message.  I was finally able to download the file without
>any retries and it then EXECed cleanly.
>
>Has anyone else had any problems with Kermit not discarding bad
>packets?

I've never had that problem downloading text files.  I occasionally
get a retry and haven't gotten an extra packet (perhaps it depends on
exactly what error requiring a retry occurs).

Is it possible that the bad packets generating retries WERE replaced,
but that at least one packet was accepted (correct checksum character)
that should not have been?  There's a 1 in 256 chance of that happening
in XModem given a bad block, and if I understand Kermit's error checking,
the same odds apply.

I have had trouble downloading binary files (from IBM to IBM over
bitnet where no translations to ASCII intervene, binary transfer will
work).  Evidently the one character block-check (the only level Kermit-65
supports) is insufficient to insure against bad blocks in 8bit transfers.
I've received corrupted binary code even when there were NO errors
resulting in retries (confirmed by uploading the file and comparing
byte-for-byte against the original).

The Kermit protocol provides for up to 3 character CRC error checking.
The MS-DOS docs note that SET BLOCK 3 should be used when transerring
binary files.  However, I've been under the impression that SET BLOCK 1
is sufficient for 7-bit transfers.

I assume that providing for SET BLOCK-CHECK 2 (or 3) in Kermit-65
would involve a LOT of overhead that might create other problems or
expand the code beyond the capacity of 48K Apple 2's (?).

---------------------
Disclaimer: The "look and feel" of this message is exclusively MINE!
            (subject to change without notice; void where prohibited)

ARPA:   sewall%uconnvm.bitnet@mitvma.mit.edu       Murphy A. Sewall
BITNET: SEWALL@UCONNVM                          School of Business Admin.
UUCP:   ...ihnp4!psuvax1!UCONNVM.BITNET!SEWALL  University of Connecticut