Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!ames!uhccux!querubin
From: querubin@uhccux.uhcc.hawaii.edu (Antonio Querubin)
Newsgroups: comp.sys.ibm.pc
Subject: Re: XMODEM,YMODEM,ZMODEM,KERMIT Which is best and why?
Message-ID: <5902@uhccux.uhcc.hawaii.edu>
Date: 4 Jan 90 10:54:01 GMT
References: <32428@news.Think.COM> <25A14694.9576@maccs.dcss.mcmaster.ca>
Reply-To: querubin@uhccux.UUCP (Antonio Querubin)
Organization: University of Hawaii
Lines: 21

In article <25A14694.9576@maccs.dcss.mcmaster.ca> cs4g6ag@maccs.dcss.mcmaster.ca (Stephen M. Dunn) writes:
>
>   If you can avoid kermit, do so for several reasons.  It's designed
>to work on a 7-bit data path, so it has an inherent performance penalty
>due to this.  Also, it uses miniscule packets (although newer versions
>are supposed to be able to handle reasonably-sized packets ... but only
>if you have a newer version at both ends of the data link).  I'm not
>sure if it can transmit date/time stamp information; I don't think it
>can.

Kermit does not inherently work on a 7-bit data path.  MS-Kermit and MACKermit
for example, transfer 8-bit data AS 8-bit data.  You can force 8-bit 'quoting' 
if you need to.  Both these versions handle 1K and 2K packets, respectively. 
C-Kermit also handles 1K+ packets.  I know that MS-Kermit handles file 
attribute info.  MACKermit does also if you select the macbinary mode.  I don't
know about the other modes.

The Kermit family of programs is pretty big.  They're written for different
hardware platforms and a wide variety of operating systems.  Some implement 
many of the kermit protocol features, others implement only the basics just to 
get the job done.  But they share one very important feature:  they can talk to
each other.