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.