[vcf-midatlantic] A more efficient BBS Xfer protocol

[John Heritage]

Hi folks!

Being a geek and SysOp I spent a lot of time as a teenager looking for the
most efficient BBS file transfer protocol - working through XModem CRC,
Ymodem-1K, ZModem, ZModem with MobyTurbo, Ymodem-G, etc..   I even ran
HS-Link (and BiModem) for a while to help people who actually uploaded to
BBSes :).

In search of CPS, the fastest I could transmit a compressed file over a
14.4 kbps link (1800 cps theoretical maximum) was using Ymodem-G** with a
series of modem settings (AT&K0 - disable compression, and a few others),
achieving just over 1730 cps. ZModem* was something in the 1630-1650 range,
and DSZ's "mobyturbo" Zmodem would do ~ 1660-1665.

Anyway I had an idea at the time to write a protocol that would dedicate
100% of the senders bandwidth to transmitting data while still adding error
correction.   Here's how it would work:

1.  Sender streams data continuously;  but calculates a CRC every X bytes
(x=1024 initially), and stores to RAM.
2.  Receiver receives data continuously;  calculates a CRC every 1024 bytes
and then sends back to the receiver over the modem back channel***.
3.  Sender looks at CRCs received and if there's a match, continues
sending.  If there is a bad CRC, the Sender would either end the transfer
(like Ymodem-G) or initiate some kind of "resume from previous bytes"
control sequence TBD.
4.  To help the file transfer end with minimum wasted overhead, I'd
probably start the protocol with a simple string indicating how many bytes
are in the transfer so the receiver knows when to stop recording.

I know there's more to it than this -- the control sequence would still
cost something unless I went the Ymodem-G route.  The receiver would have
to be fast enough to write to disk, calculate CRCs, and send CRCs without
running out of modem buffer to prevent delays..

Anyway, in my mind this is 100% or as near to 100% efficient for a one-way
file transfer as you can get..   Did anyone ever write a protocol like
this?    Am I a fool?   :)

Thanks!
John

....... If you like reading:
* Zmodem of course could resume and recover where Ymodem-G couldn't, but
was less efficient due to certain control byte characters needing to be
double sent when they appeared in the stream.

** Ymodem-G though rarely failed on "modern" error correcting modems..

***  USRobotics initial 14.4kbps implementation only had a 450 baud back
channel which was limiting, but the industry standard (V.32bis?) was
capable of 14.4kbps symmetrically.