
Date: Fri 22 Jun 84 18:19:34-EDT
From: Frank da Cruz <CC.FDC@COLUMBIA-20.ARPA>
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

------------------------------
