25 If I Have an Error Correcting Modem Why Do I Need Kermit Protocol?

"If modern modems are capable of hardware error correction and compression, isn't it redundant and inefficient to continue to use file-transfer protocols like Kermit and ZMODEM that provide the same services?"

This is a common misconception, and, unfortunately, one that is promoted by many of the modem makers themselves (e.g. when you read about protocols in the modem manuals). The modem makers (some of them) might excel at what they do, but they are generally not experts on computers and software. For example, the following appears in a current modem manual:

Generally, the most efficient file-transfer operations are achieved when the EC modem does the error checking in hardware, and the file-transfer protocol does not duplicate this effort. The YMODEM-G file-transfer protocol provides this level of service. This protocol was written for use with high-speed, error-control modems. This protocol does not provide any error-detection or recovery capability.

But it is not true that protocols like YMODEM-g (or, as is often suggested by newcomers to modem communication, no protocol at all) are the best to use with error-correcting modems.

That's because errors can also occur (and often do) outside the modem-to-modem connection. The most common causes are lack of sufficiently effective DCE/DTE flow control and resulting buffer overflows in the receiver; unbuffered UARTs that can't be serviced fast enough by a busy or slow CPU; interrupt conflicts (including characters lost due to having interrupts turned off by other drivers, e.g. disk-caching programs), and on and on -- things that are beyond the modem's control.

Second, you don't always know that your error-correcting modem will make a successful MNP or V.42 connection with the other modem. The two modems might have mismatched capabilities or there might be a "failure to negotiate" the capabilities they do have. Would you want to use different file transfer methods depending on the type of connection negotiated by the modems?

Third, the communication channel outside the modems might not be fully transparent. For example, it might chop off the 8th bit of each byte, or it might filter out certain characters, or use them for special purposes rather than treating them as data. This is common with terminal servers and other types of communications front ends.

Fast protocols like Zmodem and modern Kermit impose little additional overhead, and that small amount of overhead is well worth the savings in failed or corrupt transfers, which are inevitable when using non-recovering methods in situations like the ones described above.

But even more fundamentally: you can't know in advance that there will be no errors. So using a file transfer procedure without error recovery is silly, because if there are errors, you'll have to start all over again. It's like not buying fire insurance for your house because you think it is fireproof.

Finally, what happens when the connection is broken? Say, after transferring 99 megabytes of a 100-megabyte file? Error-correcting modems can't stop wires from being cut or pulled out, nor can they prevent power failures or keep computers or applications from crashing. So again, you need a good error recovery protocol. Both Zmodem and Kermit can pick an interrupted transfer up from the point of failure.