Thankfully, ZModem existed. I’d never been able to use Kermit successfully back in the days, always had trouble with it. I even had more success with XModem.
Jumping from Kermit to ZModem was quite a revelation for this Muppets fan. I was so sad to find I'd been needlessly reducing my download speed just by going with the fuzzy green frog, when presented with all of the different download options.
What gets me is that ZModem-Resume had effective continuation of failed transfers _decades_ before HTTP got it right. The early days of the web drove me bonkers, having to start over with a long file that failed in the middle.
I remember using a program...I forget what it was called, but it was popular in the 56K days for resuming HTTP downloads. It would even allow you to provide mirror URLs so you could download from multiple sources at once.
I want to say it was called WinGet, but now there's something else called that, so I can't confirm it.
In the spec, yes. But since servers use Content-Encoding instead of Transfer-Encoding for on-the-fly compression, its unspecified now whether the byte offsets in the resumption refer to the compressed or uncompressed file. Result: Download resumption did not work reliably and got removed from browsers.
You probably didn't have Kermit configured correctly; most of us didn't.
When someone finally showed me how to set the options (which default to reliable-but-godawfully-slow) for much higher speed transmission (bigger segments, sliding windows for ACK, maybe a few other things?), it was entirely comparable to Zmodem.
That's pretty funny. I don't remember ever coming across configs for Kermit or other protocols, just the [K]ermit | [Z]modem -type options on the front end of whatever clients I was trying out.
I wonder why more than one client would default to such comparatively-lame settings for Kermit though.
IIRC you basically have to get a Kermit prompt and issue your commands to the server. Which is easy if you use an actual Kermit client, like Columbia put out (though apparently for the last 12 years it's been an independent project no longer affiliated with the university), but most people just used the internal version that came with their terminal program - with the primary effect being that most people had no idea it was actually a fast, flexible protocol (see the long explanation at http://www.columbia.edu/kermit/misconceptions.html).
The stated reason for this is that it should always default to working, and it's up to you to configure it to work well if your connection is better than rusty barbed wire.
The default of "always work" is amply demonstrated by the fact that Kermit is available for CP/M, and can be compiled on a working CP/M-80 system from .HEX files that you just blast over the serial port. Obviously, due to system constraints, this is not a fully modern Kermit.
But it works. And if you want error checking and reliable file transfer on a Kaypro, it's not a bad way to do it.
There was also short BASIC programs that could be readily keyed in that supported the basic lowest common denominator of the Kermit protocol. The goal being to key that in, and use it to transfer and bootstrap a better version of Kermit.
