The ZMODEM Inter Application	File Transfer Protocol			      Chuck Forsberg			   Omen	Technology Inc	  A overview of	this document is available as ZMODEM.OV			     (in ZMDMOV.ARC)		       Omen Technology Incorporated		      The High Reliability Software		   17505-V Northwest Sauvie Island Road			  Portland Oregon 97231			VOICE: 503-621-3406 :VOICE		Modem: 503-621-3746 Speed 1200,2400,19200		     Compuserve:70007,2304  GEnie:CAF		    UUCP: ...!tektronix!reed!omen!cafChapter	0		Rev 8-3-87  Typeset 8-4-87			 1Chapter	0		     ZMODEM Protocol				 21.  INTENDED AUDIENCEThis document is intended for telecommunications managers, systemsprogrammers, and others	who choose and implement asynchronous filetransfer protocols over	dial-up	networks and related environments.2.  WHY	DEVELOP	ZMODEM?Since its development half a decade ago, the Ward Christensen MODEMprotocol has enabled a wide variety of computer	systems	to interchangedata.  There is	hardly a communications	program	that doesn't at	leastclaim to support this protocol,	now called XMODEM.Advances in computing, modems and networking have spread the XMODEMprotocol far beyond the	micro to micro environment for which it	wasdesigned.  These application have exposed some weaknesses:   + The awkward user interface	is suitable for	computer hobbyists.     Multiple commands must be keyboarded to transfer each file.   + Since commands must be given to both programs, simple menu	selections     are not possible.   + The short block length causes throughput to suffer	when used with     timesharing systems, packet switched networks, satellite circuits,     and buffered (error correcting) modems.   + The 8 bit checksum	and unprotected	supervison allow undetected errors     and disrupted file	transfers.   + Only one file can be sent per command.  The file name has to be given     twice, first to the sending program and then again	to the receiving     program.   + The transmitted file accumulates as many as 127 bytes of garbage.   + The modification date and other file attributes are lost.   + XMODEM requires complete 8	bit transparency, all 256 codes.  XMODEM     will not operate over some	networks that use ASCII	flow control or     escape codes.  Setting network transparency disables important     control functions for the duration	of the call.A number of other protocols have been developed	over the years,	but nonehave proven satisfactory.   + Lack of public domain documentation and example programs have kept     proprietary protocols such	as Relay, Blast, and others tightly bound     to	the fortunes of	their suppliers.  These	protocols have not     benefited from public scrutiny of their design features.Chapter	2		Rev 8-3-87  Typeset 8-4-87			 2Chapter	2		     ZMODEM Protocol				 3   + Link level	protocols such as X.25,	X.PC, and MNP do not manage     application to application	file transfers.   + Link Level	protocols do not eliminate end-to-end errors.  Interfaces     between error-free	networks are not necessarily error-free.     Sometimes,	error-free networks aren't.   + The Kermit	protocol was developed to allow	file transfers in     environments hostile to XMODEM.  The performance compromises     necessary to accommodate traditional mainframe environments limit     Kermit's efficiency.  Even	with completely	transparent channels,     Kermit control character quoting limits the efficiency of binary file     transfers to about	75 per cent.[1]     A number of submodes are used in various Kermit programs, including     different methods of transferring binary files.  Two Kermit programs     will mysteriously fail to operate with each other if the user has not     correctly specified these submodes.     Kermit Sliding Windows ("SuperKermit") improves throughput	over     networks at the cost of increased complexity.  SuperKermit	requires     full duplex communications	and the	ability	to check for the presence     of	characters in the input	queue, precluding its implementation on     some operating systems.     SuperKermit state transitions are encoded in a special language     "wart" which requires a C compiler.     SuperKermit sends an ACK packet for each data packet of 96	bytes     (fewer if control characters are present).	 This reduces throughput     on	high speed modems, from	1350 to	177 characters per second in one     test.A number of extensions to the XMODEM protocol have been	made to	improveperformance and	(in some cases)	the user interface.  They provide usefulimprovements in	some applications but not in others.  XMODEM's unprotectedcontrol	messages compromise their reliability.	Complex	proprietarytechniques such	as Cybernetic Data Recovery(TM)[2] improve reliability,but are	not universally	available.  Some of the	XMODEM mutant protocolshave significant design	flaws of their own. + XMODEM-k uses 1024 byte blocks to reduce the	overhead from transmission   delays by 87	per cent compared to XMODEM, but network delays	still__________ 1. Some Kermit	programs support run length encoding. 2. Unique to DSZ, ZCOMM, Professional-YAM and PowerComChapter	2		Rev 8-3-87  Typeset 8-4-87			 3Chapter	2		     ZMODEM Protocol				 4   degrade performance.	 Some networks cannot transmit 1024 byte packets   without flow	control, which is difficult to apply without impairing the   perfect transparency	required by XMODEM.  XMODEM-k adds garbage to   received files. + YMODEM sends	the file name, file length, and	creation date at the   beginning of	each file, and allows optional 1024 byte blocks	for   improved throughput.	 The handling of files that are	not a multiple of   1024	or 128 bytes is	awkward, especially if the file	length is not   known in advance, or	changes	during transmission.  The large	number of   non conforming and substandard programs claiming to support YMODEM   further complicates its use. + YMODEM-g provides efficient batch file transfers, preserving	exact file   length and file modification	date.  YMODEM-g	is a modification to   YMODEM wherein ACKs for data	blocks are not used.  YMODEM-g is   essentially insensitive to network delays.  Because it does not support   error recovery, YMODEM-g must be used hard wired or with a reliable   link	level protocol.	 Successful application	at high	speed requires   cafeful attention to	transparent flow control.  When	YMODEM-g detects a   CRC error, data transfers are aborted.  YMODEM-g is easy to implement   because it closely resembles	standard YMODEM. + WXMODEM, SEAlink, and MEGAlink have applied a subset	of ZMODEM's   techniques to "Classic XMODEM" to improve upon their	suppliers'   previous offerings.	They provide good performance under ideal   conditions.Another	XMODEM "extension" is protocol cheating, such as Omen Technology'sOverThruster(TM) and OverThruster II(TM).  These improve XMODEM	throughputunder some conditions by compromising error recovery.The ZMODEM Protocol corrects the weaknesses described above whilemaintaining as much of XMODEM/CRC's simplicity and prior art as	possible.3.  ZMODEM Protocol Design CriteriaThe design of a	file transfer protocol is an engineering compromisebetween	conflicting requirements:3.1  Ease of Use + ZMODEM allows either	program	to initiate file transfers, passing   commands and/or modifiers to	the other program. + File	names need be entered only once. + Menu	selections are supported.Chapter	3		Rev 8-3-87  Typeset 8-4-87			 4Chapter	3		     ZMODEM Protocol				 5 + Wild	Card names may be used with batch transfers. + Minimum keystrokes required to initiate transfers. + ZRQINIT frame sent by sending program can trigger automatic downloads. + ZMODEM can step down	to YMODEM if the other end does	not support   ZMODEM.[1]3.2  ThroughputAll file transfer protocols make tradeoffs between throughput,reliability, universality, and complexity according to the technology andknowledge base available to their designers.In the design of ZMODEM, three applications deserve special attention.  + Network applications with significant delays (relative to character    transmission time) and low error rate  + Timesharing	and buffered modem applications	with significant delays    and	throughput that	is quickly degraded by reverse channel traffic.    ZMODEM's economy of	reverse	channel	bandwidth allows modems	that    dynamically	partition bandwidth between the	two directions to operate    at optimal speeds.	Special	ZMODEM features	allow simple, efficient    implementation on a	wide variety of	timesharing hosts.  + Direct modem to modem communications with high error rateUnlike Sliding Windows Kermit, ZMODEM is not optimized for optimumthroughput when	error rate and delays are both high.  This tradeoffmarkedly reduces code complexity and memory requirements.  ZMODEMgenerally provides faster error	recovery than network compatible XMODEMimplementations.In the absence of network delays, rapid	error recovery is possible, muchfaster than MEGAlink and network compatible versions of	YMODEM and XMODEM.File transfers begin immediately regardless of which program is	startedfirst, without the 10 second delay associated with XMODEM.__________ 1. Provided the transmission medium accommodates X/YMODEM.Chapter	3		Rev 8-3-87  Typeset 8-4-87			 5Chapter	3		     ZMODEM Protocol				 63.3  Integrity and RobustnessOnce a ZMODEM session is begun,	all transactions are protected with 16 or32 bit CRC.[2] Complex proprietary techniques such as Cybernetic DataRecovery(TM)[3]	are not	needed for reliable transfers.An optional 32-bit CRC used as the frame check sequence	in ADCCP (ANSIX3.66, also known as FIPS PUB 71 and FED-STD-1003, the U.S. versions ofCCITT's	X.25) is used when available.  The 32 bit CRC reduces undetectederrors by at least five	orders of magnitude when properly applied (-1preset,	inversion).A security challenge mechanism guards against "Trojan Horse" messageswritten	to mimic legitimate command or file downloads.3.4  Ease of ImplementationZMODEM accommodates a wide variety of systems: + Microcomputers that cannot overlap disk and serial i/o + Microcomputers that cannot overlap serial send and receive + Computers and/or networks requiring XON/XOFF	flow control + Computers that cannot check the serial input	queue for the presence of   data	without	having to wait for the data to arrive.Although ZMODEM	provides "hooks" for multiple "threads", ZMODEM	is notintended to replace link level protocols such as X.25.ZMODEM accommodates network and	timesharing system delays by continuouslytransmitting data unless the receiver interrupts the sender to requestretransmission of garbled data.	 ZMODEM	in effect uses the entire file asa window.[4] Using the entire file as a	window simplifies buffermanagement, avoiding the window	overrun	failure	modes that affectMEGAlink, SuperKermit, and others.ZMODEM provides	a general purpose application to application file transferprotocol which may be used directly or with with reliable link level__________ 2. Except for the CAN-CAN-CAN-CAN-CAN abort sequence which requires five    successive CAN characters. 3. Unique to Professional-YAM and PowerCom 4. Streaming strategies are discussed in coming chapters.Chapter	3		Rev 8-3-87  Typeset 8-4-87			 6Chapter	3		     ZMODEM Protocol				 7protocols such as X.25,	MNP, Fastlink, etc.  When used with X.25, MNP,Fastlink, etc.,	ZMODEM detects and corrects errors in the interfacesbetween	error controlled media and the remainder of the	communicationslink.ZMODEM was developed for the public domain under a Telenet contract.  TheZMODEM protocol	descriptions and the Unix rz/sz	program	source code arepublic domain.	No licensing, trademark, or copyright restrictions applyto the use of the protocol, the	Unix rz/sz source code and the ZMODEMname.4.  EVOLUTION OF ZMODEMIn early 1986, Telenet funded a	project	to develop an improved publicdomain application to application file transfer	protocol.  This	protocolwould alleviate	the throughput problems	network	customers wereexperiencing with XMODEM and Kermit file transfers.In the beginning, we thought a few modifications to XMODEM would allowhigh performance over packet switched networks while preserving	XMODEM'ssimplicity.The initial concept would add a	block number to	the ACK	and NAK	charactersused by	XMODEM.	 The resultant protocol	would allow the	sender to sendmore than one block before waiting for a response.But how	to add the block number	to XMODEM's ACK	and NAK?  WXMODEM,SEAlink, MEGAlink and some other protocols add binary byte(s) to indicatethe block number.Pure binary was	unsuitable for ZMODEM because binary code combinationswon't pass bidirectionally through some	modems,	networks and operatingsystems.  Other	operating systems may not be able to recognize somethingcoming back[1] unless a	break signal or	a system dependent code	orsequence is present.  By the time all this and other problems with the