Date: Fri 22 Jun 84 18:19:34-EDT From: Frank da Cruz Subject: Comparing Kermit with Other Packages To: Info-Kermit@COLUMBIA-20 First let me say that there seem to be two major kinds of commercial packages: the kind that use some variation of MODEM protocol, and the kind that use their own proprietary protocols. First, MODEM (please, any MODEM aficionados feel free to correct any of this)... MODEM and Kermit are similar in that they both use back-and-forth ACK/NAK protocols over asynchronous telecommunication lines. However, MODEM sends fixed-length packets with 128 8-bit data bytes, KERMIT sends variable length packets (up to 96 characters in length) with either 7- or 8-bit data bytes. The MODEM packet control fields use all 8 bits; Kermit control fields only use 7. There are several consequences of all this: MODEM can't work at all over a 7-bit channel, even for text files, because the checksum and other control fields will be wrong. This means that MODEM can't be used over public packet-switched networks like TELENET, or with hosts that require use of character parity, like IBM mainframes. Kermit can send both text and binary files over either 7-bit channels or 8-bit channels, but the data gets longer if you have to squeeze it through a narrower hole. Certain computing or communication equipment cannot accept 128 characters at a time. Their buffers aren't that big. Kermit can accommodate these systems, but MODEM cannot. Many systems cannot accept all ASCII characters, particularly control characters, transparently (see the message about PRIME above for one of many possible examples). MODEM provides no mechanism for encoding otherwise taboo characters. Non-CPM systems, which do not necessarily allocate files in units of 128 bytes or follow the CTRL-Z end-of-file convention, will often have junk at the end of a file received by MODEM. MODEM, to the best of my knowledge, does not have a good mechanism for transmitting a group of files; Kermit has it built into the protocol. Kermit protocol also includes optional features for management of remote files -- directory listings, file deletion, quota checking, etc. Many of the Kermit programs support these optional features. MODEM sends the file bytes exactly as is, whereas Kermit gives you some options for reformatting and compressing. A "text" file is transformed to "canonical form" by Kermit, i.e. a stream of ASCII characters with the "records" (lines) separated by (encoded) CR/LF sequences, so that it may be stored in useful form on the target system. Thus, Kermit may be used on record-oriented systems (like IBM VM/CMS) or on stream-oriented systems like Unix where there record boundaries may be different (LF instead of CRLF); Kermits on those systems that don't store text files in the canonical manner do the appropriate conversions. In addition, Kermit may also be told to send files as-is. On the other hand, MODEM works nicely between like systems (especially CP/M systems) -- it's more efficient than Kermit because it doesn't have to encode and decode the data, and the packets are somewhat longer. Also, much greater attention has been given in MODEM programs to modems themselves, and MODEM programs are typically able to control dialout modems from various manufacturers, and to run in "remote mode" when dialed up from the "back port" of a micro (but the forthcoming MS-DOS Kermit will have this ability also). MODEM provides the ability to dynamically switch between 8-bit and 16-bit block checks depending on the error rate; KERMIT provides 6, 12, and 16 bit block checks, but one of these must be selected ahead of time and will be used throughout the transfer. There's more, but in short I think that, on balance, Kermit is more flexible and more easily adaptable to new systems; hence its rapid spread to a wide variety of micros, minis, and mainframes. Now, as to commercial packages with proprietary protocols -- well, who knows? In some cases, these protocols may be superior to Kermit in every way. But you have certain problems with any commercial package: Are implementations available for all the systems you want them for? If not, will the vendor write the missing implementations? When? For how much money? Does the protocol make assumptions (like full duplex communication, 8-bit data path) that would lock out certain classes of systems? Do you have enough money to buy the software licenses for your mainframes and each and every one of your micros? Some sites have thousands of micros. A typical commercial file transfer package costs $500-$5000 dollars for the mainframe end and $50-$500 for each micro. Can your vendor fix bugs in a timely fashion? If you had sources, you could fix them yourself, but most vendors don't provide sources. Many commercial packages are very fancy, both in the protocol and the user interface. But they often tend to be specially tailored to a certain combination of systems and/or applications. Kermit is not as fancy as a commercial product that knows how to dial up Dow-Jones and look up your stocks, reformat the data as it comes in, and display it in a color pie chart, all upon a single keystroke. But then that package probably can't exchange text and binary files with 50 or 60 different kinds of systems in a relatively uniform and consistent way. Comments, rebuttals, are invited. - Frank ------------------------------