FROM JEFF JODOIN THE NEW SYSOP OF AWAUG BBS, 24 HRS. 202-561-2475 comes the following files I requested for those of you interested in these areas.
 
 
Below is a recent exchange of messages concerning the heritage and 
future of the XMODEM/YMODEM/ZMODEM protocols.
 
--Keith Petersen, W8SDZ - 9-Jan-87
 
---------------------------- 
Date: 29 Dec 86 19:08:53 GMT 
From: Chuck Forsberg <uw-beaver!tektronix!reed!omen!caf> 
Re:  What is the Diff between Xmodem/Ymodem
 
In article <2374@psuvax1.UUCP> jte@psuvax1.UUCP (Jon Eckhardt) writes: 
:Now, one question for all of you guys who know your communication 
:packages.  What is the difference between Xmodem/Ymodem/Umodem/Kermit. 
:Which one do you guys think is the best of all of them and most versitile.
 
Ward Christensen wrote MODEM in the late 70's to transfer files between 
the primitive Altair bus (S-100) micros available to hobbyists at the 
time.  The press has since come to call this protocol XMODEM, and the 
name has stuck.  XMODEM uses 128 byte blocks to transfer a single file 
between two machines.  A path name must be given to both sending and 
receiving programs.  The resultant file will have up to 127 bytes of 
garbage appended to it.  Without proprietary enhancements, XMODEM 
transfers are unreliable in the presence of line impairments.
 
UMODEM is a popular Unix program that supports XMODEM protocol.
 
XMODEM/CRC uses a 16 bit CRC instead of the original 8 bit checksum, 
improving integrity but not reliability.  XMODEM-1k also allows 1024 
byte blocks to be sent to improve throughput with computer networks and 
timesharing systems.
 
YMODEM sends one or more files per command by passing the pathname and 
(optionally) file length, modification time, etc., in block 0.  This 
allows the receiver to generate an exact copy of the file contents. 
CRC-16 is normally used with YMODEM.  1k blocks are a popular option, 
but cannot be mandatory because some operating systems choke on the 
longer blocks.
 
The Unix rb and sb programs (now superceded by rz and sz) support 
YMODEM file transfers as well as XMODEM, XMODEM/CRC and XMODEM-1k.
 
Kermit refers to a set of related file transfer protocols developed at 
Columbia to allow file transfers in brain damaged communications 
environments that do not allow all 256 8 bit codes to be sent and 
received correctly.  As with YMODEM, Kermit sends the pathname to the 
receiver, so multiple files can be sent with one set of commands.  To 
transfer files, both Kermit programs must be set to use the same 
Kermit sub-protocol (8th bit quoting .vs.  transparency).  An average 
Kermit implementation is more reliable than an average XMODEM 
implementation.  The design features that allow Kermit to work in 
brain damaged environments make it less efficient than YMODEM or 
XMODEM-1k.
 
In early 1986 Telenet commissioned the development of the Public 
Domain ZMODEM protocol to provide efficient and reliable file 
transfers over PC Pursuit and similar environments.  More information 
on ZMODEM is available in ZMODEM.ARC on various bulletin boards 
including TeleGodzilla.
 
Chuck Forsberg WA7KGX
 
---------------------------- 
Date: 30 Dec 86 03:00:38 GMT 
From: Ward Christensen <ucbvax!ihnp4!chinet!ward> 
Re:  What is the Diff between Xmodem/Ymodem
 
XMODEM is the protocol that was defined when I submitted MODEM.ASM to 
the CP/M (8080) users group in August or September '77.  People didn't 
like my rather kludgy syntax of "modem sq <filename>" - Keith Petersen 
stripped down the program for use on a remote CP/M system and called 
it XMODEM.
 
Since MODEM was a piece of 'hardware', the name XMODEM 'stuck' as the 
protocol name.
 
My original protocol, now technically called "Xmodem checksum" or 
sometimes "Christensen Protocol", is the most simple of the 
protocols.  It is not all that great - chances of un-detected line 
errors getting through are a bit too high.
 
Others added a CRC to make the protocol more bulletproof, thus: 
XMODEM-CRC.
 
Chuck Forsberg rewrote my protocol in C for CP/M - I don't know the 
entire history, but he developed rb/sb (receive batch, send batch) for 
Unix, which 'defined' the YMODEM protocol.  It typically uses 1K 
blocks, and a CRC.
 
Chuck also cleverly sent a block zero (I started with block # 1 in 
Xmodem) to send the filename, length, date, etc (filename being the 
minimum).  Thus rb/sb can send batches of files in 1K blocks with CRC 
- much more efficient than my original 128-byte record size (because 
that was a CP/M sector).
 
ZMODEM is chuck's latest brainchild, which is a "sliding window" 
protocol, which I understand to mean "allows multiple packets to be 
sent before receiving an acknowledgement".
 
UMODEM is a 'program' implementing xmodem (all the other items in your 
question are protocols, (though XMODEM was originally a program, too) 
so I'll not go into Umodem further).
 
KERMIT was developed at Columbia (My terrible memory prevents me from 
properly acknowledging the authors), for micro to mainframe 
communications.  At least ONE reason for its development was that 
XMODEM was unsuitable for some mainframes - such as IBM, because at 
the time, their communications 'front ends' didn't support the 8-bit 
bytes, timeouts, lack of "end of block" characters, which XMODEM, 
developed for micro-micro communications, required.
 
I hope this overview answered your questions.
 
------------------------------- 
Date: Sun 4 Jan 87 18:05:34-MST 
From: Frank J. Wancho 
Re:  XMODEM, YMODEM, UMODEM, and KERMIT
 
Chuck, there are several historical holes in your otherwise excellent 
discussion.  To complete the record, here they are:
 
1.  Ward wrote the MODEM program to transfer files between CP/M 
systems.  The fact that many early CP/M systems were built on the 
Altair or S-100 bus is irrelevant.
 
2.  Keith Petersen wrote the original XMODEM program, based on Ward's 
program, for unattended "quiet" mode on Remote CP/M systems.  That 
program had some simple security features and originally used the then 
prevalent Checksum mode.  Later, the 16-bit CRC mode from MODEM7 was 
added by others as well as the ability to download selected component 
files from .LBR files.  To this day, it still does not allow wildcard 
filenames to be specified for "batch mode" transfers to prevent a 
caller from hogging the system.
 
3.  MODEM7 added the 16-bit CRC option and "batch mode" capability. 
There are several derivatives of the original MODEM7 program, all 
meant to be used, for the most part, in attended mode.
 
4.  Because of the popularity of the Remote CP/M (and other systems 
which had the capability to transfer programs with the XMODEM 
program), the press mistakenly referred to the protocol as the XMODEM 
protocol.  It is unfortunate and incorrect, but the designation seems 
to have stuck.
 
5.  Enhancements to the original Christensen Protocol to increase the 
probability of completing a transfer in the presence of line noise 
were developed by Bob Plouffe and added to XMODEM and MODEM7 and its 
descendants several years ago, and they are all in the public domain. 
If the transfer runs to completion, it is guaranteed to be an accurate 
copy within the limits of the 16-bit CRC algorithm used to verify each 
128-byte block of data.  Perhaps the bad press that "xmodem" file 
transfers have received is the result of comparisons with obsolete 
implementations (see below).
 
6.  Most of the terminal emulation programs written for the MSDOS 
environment which claim "xmodem" file transfer capabilities were 
apparently written from a very old description of the original MODEM 
protocol.  These programs use checksum mode only and do not have the 
subsequently developed robustness enhancements, especially in the area 
of timeout windows and retry attempts.  Of course, they don't have 
batch mode either.  There are a couple of notable exceptions: YMODEM 
and ZMODEM are two, neither of which has the MODEM7-style "batch mode" 
(for good reasons) - they have their own instead, and MEX-PC, which 
has all of the MODEM7 protocol robustness enhancements as well as 
"batch mode" and the "xmodem/1K" data block option.  MEX 1.14 for C/PM 
systems is available from many RCP/M systems.  The commercial version 
is called MEX-PLUS and tracks MEX-PC.  Both also have a KERMIT file 
transfer mode option and many other features.
 
7.  UMODEM was originally written by Lauren Weinstein and subsequently 
enhanced by Rick Conn and others as UC.  It is the latter UC which has 
been the choice for Unix implementation for "xmodem" file transfers 
until rb/sb and now rz/sz became available.
 
8.  The YMODEM method of using Block 0 to send filenames and other 
file descriptor information is definitely superior to the method used 
by the MODEM7 batch mode.  However, there are very few, if any, 
implementations of this approach used, except with another YMODEM or 
ZMODEM implementation.
 
9.  The KERMIT protocol is completely unrelated to the "xmodem" 
implementations, except that it allows for file transfers, among many 
other features.  The KERMIT protocol was developed independently of 
the "xmodem" protocol.  The KERMIT protocol's principal advantage is 
that implementations exist for just about every mainframe and micro 
ever made, and chances are that someone somewhere is working on 
implementations for the rest.
 
All this is not to say that up-to-date implementations of the "xmodem" 
protocol is all that great.  But, the protocol is not quite all that 
bad as many people have been led to believe...
 
--Frank
 
-------------------------------- 
Date: Sun, 4 Jan 1987 23:17 EST 
From: Keith Petersen, W8SDZ 
Subject: XMODEM, YMODEM, UMODEM, and KERMIT
 
Frank, thanks for setting the record straight.  It's nice to see some 
good things being said about XMODEM.
 
One side note: when the CRC mode was about to be added to Modem7 I 
received a call from the author John Mahr, telling me what he was 
doing and asking for some advice on how to make the program downward 
compatible.  It was I who suggested the "C" initial signal from the 
receiving end to signify that it was capable of doing CRC.  He and I 
discussed what should be done if this "C" was not honored by the 
sender.  We decided that the receiver should drop back to checksum 
mode after 6 tries with the "C".
 
--Keith
 
------------------------------ 
Date: Tue 6 Jan 87 02:51:50 GMT 
From: Chuck Forsberg <uw-beaver!tektronix!reed!omen!caf> 
Re:  Recent Protocol Comments
 
A few comments about recent comments on *MODEM protocols:
 
I mentioned the Altair environment of the original Christensen protocol 
as a gentle reminder of the constricted development enviroment available 
at the time.
 
For the sake of minimum confusion, please use the nomenclature in the 
current revision (9-18-86) of YMODEM.DOC:
 YMODEM==batch, pathname in sector 0, 128 or 1024 byte packets.
 XMODEM-1k == XMODEM with CRC and 1024 byte packets
 
Since IMP, KMD, MEX (I think), and PD YAM all support YMODEM, it seems 
there is a good penetration of YMODEM in the CP/M arena.
 
Many ICM PC comm programs claim to support YMODEM, Microsoft Access and 
XTALK XVI being notably out of date.
 
There are a number of weaknesses in the XMODEM protocol, which is the 
underlying technology for XMODEM-1k and YMODEM as well.  There are a 
number of widely published tricks and enhancements that improve 
XMODEM's reliability in the presence of line impairments.  Other 
reliability enhancements are proprietary to certain programs, and not 
generally available.
 
One of ZMODEM's advantages is the protocol's built-in reliability, 
which gives good results without resort to myriad tricks.  An upcoming 
32 bit CRC option will further improve operations. 

