[vcf-midatlantic] A "100%" Efficient BBS Transfer Protocol

Evan Koblentz evan at vcfed.org
Tue Oct 15 14:37:09 EDT 2019

>> You will probably want to at least mark block boundaries

Hello Ken. Looks like that's your first post here. Please introduce
yourself as is our tradition. How you found us, what are your interests in
vintage computing, where you live, etc.

-Evan K. (list admin)

On Tue, Oct 15, 2019, 2:34 PM Kenneth Gober via vcf-midatlantic <
vcf-midatlantic at lists.vcfed.org> wrote:

> On Mon, Oct 14, 2019 at 7:55 PM John Heritage via vcf-midatlantic <
> vcf-midatlantic at lists.vcfed.org> wrote:
> > This protocol would operate like ZModem or YModem-G where the uploader
> just
> > keeps streaming, but no CRCs would be sent with the transfer.  Instead,
> the
> > 'sender' computer would simply pre-calculate CRCs for every 1K or so;
> the
> > receiver computer would calculate after receiving that 1K, and send back
> to
> > the uploader.  The uploader would go back and verify that it was getting
> > the right CRCs in the right order (you could pre-calculate these and
> store
> > in RAM before the transfer starts to reduce CPU load during transfer).
>  If
> > no problems were encountered - you might hit that theoretical 1800 cps.
> >
> You will probably want to at least mark block boundaries, so that the
> sender
> and receiver can stay in sync if any bytes are dropped in transmission.
> Otherwise a single dropped byte could cause every successive block to
> be sent again.  With a 1K block size, a 2-byte 'frame boundary' marker
> would give you an efficiency of 1024/1026 (99.8%), assuming the block
> doesn't contain embedded markers that need to be escaped.  For
> random data you could guess that you'll get about 4 such bytes on
> average per block, so call it 1024/1034 (99.0%) efficient.
> I chose 2 bytes as the size of the frame marker so that a single escape
> byte could handle all of these cases:
> ESC n (n=0-63) - frame (x mod 64) follows (numbered starting from 0)
> ESC n (n=64-127) - current frame contains n-63 literal ESC bytes here
> ESC n (n=128-191) - end of file, file size should be (x mod 64) frames
> ESC n (n=192-255) - please send the CRC for frame (x mod 64) again
> The first 3 cases should be self-explanatory, the last case allows the
> receiver to send a 'frame' CRC in addition to the 'payload' CRC, so the
> sender can detect corrupt CRCs (or corrupt frame numbers).
> -ken

More information about the vcf-midatlantic mailing list