zmodem.doc

XMODEM传输协议。 通信用代码。 C语言实现

	   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!caf
























Chapter	0		Rev 8-3-87  Typeset 8-4-87			 1







Chapter	0		     ZMODEM Protocol				 2



1.  INTENDED AUDIENCE

This document is intended for telecommunications managers, systems
programmers, and others	who choose and implement asynchronous file
transfer protocols over	dial-up	networks and related environments.


2.  WHY	DEVELOP	ZMODEM?

Since its development half a decade ago, the Ward Christensen MODEM
protocol has enabled a wide variety of computer	systems	to interchange
data.  There is	hardly a communications	program	that doesn't at	least
claim to support this protocol,	now called XMODEM.

Advances in computing, modems and networking have spread the XMODEM
protocol far beyond the	micro to micro environment for which it	was
designed.  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 none
have 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			 2







Chapter	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	improve
performance and	(in some cases)	the user interface.  They provide useful
improvements in	some applications but not in others.  XMODEM's unprotected
control	messages compromise their reliability.	Complex	proprietary
techniques such	as Cybernetic Data Recovery(TM)[2] improve reliability,
but are	not universally	available.  Some of the	XMODEM mutant protocols
have 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 PowerCom




Chapter	2		Rev 8-3-87  Typeset 8-4-87			 3







Chapter	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's
OverThruster(TM) and OverThruster II(TM).  These improve XMODEM	throughput
under some conditions by compromising error recovery.

The ZMODEM Protocol corrects the weaknesses described above while
maintaining as much of XMODEM/CRC's simplicity and prior art as	possible.



3.  ZMODEM Protocol Design Criteria

The design of a	file transfer protocol is an engineering compromise
between	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			 4







Chapter	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  Throughput

All file transfer protocols make tradeoffs between throughput,
reliability, universality, and complexity according to the technology and
knowledge 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 rate

Unlike Sliding Windows Kermit, ZMODEM is not optimized for optimum
throughput when	error rate and delays are both high.  This tradeoff
markedly reduces code complexity and memory requirements.  ZMODEM
generally provides faster error	recovery than network compatible XMODEM
implementations.

In the absence of network delays, rapid	error recovery is possible, much
faster than MEGAlink and network compatible versions of	YMODEM and XMODEM.

File transfers begin immediately regardless of which program is	started
first, 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			 5







Chapter	3		     ZMODEM Protocol				 6



3.3  Integrity and Robustness

Once a ZMODEM session is begun,	all transactions are protected with 16 or
32 bit CRC.[2] Complex proprietary techniques such as Cybernetic Data
Recovery(TM)[3]	are not	needed for reliable transfers.

An optional 32-bit CRC used as the frame check sequence	in ADCCP (ANSI
X3.66, also known as FIPS PUB 71 and FED-STD-1003, the U.S. versions of
CCITT's	X.25) is used when available.  The 32 bit CRC reduces undetected
errors by at least five	orders of magnitude when properly applied (-1
preset,	inversion).

A security challenge mechanism guards against "Trojan Horse" messages
written	to mimic legitimate command or file downloads.

3.4  Ease of Implementation

ZMODEM 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 not
intended to replace link level protocols such as X.25.

ZMODEM accommodates network and	timesharing system delays by continuously
transmitting data unless the receiver interrupts the sender to request
retransmission of garbled data.	 ZMODEM	in effect uses the entire file as
a window.[4] Using the entire file as a	window simplifies buffer
management, avoiding the window	overrun	failure	modes that affect
MEGAlink, SuperKermit, and others.

ZMODEM provides	a general purpose application to application file transfer
protocol 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			 6







Chapter	3		     ZMODEM Protocol				 7



protocols such as X.25,	MNP, Fastlink, etc.  When used with X.25, MNP,
Fastlink, etc.,	ZMODEM detects and corrects errors in the interfaces
between	error controlled media and the remainder of the	communications
link.

ZMODEM was developed for the public domain under a Telenet contract.  The
ZMODEM protocol	descriptions and the Unix rz/sz	program	source code are
public domain.	No licensing, trademark, or copyright restrictions apply
to the use of the protocol, the	Unix rz/sz source code and the ZMODEM
name.


4.  EVOLUTION OF ZMODEM

In early 1986, Telenet funded a	project	to develop an improved public
domain application to application file transfer	protocol.  This	protocol
would alleviate	the throughput problems	network	customers were
experiencing with XMODEM and Kermit file transfers.

In the beginning, we thought a few modifications to XMODEM would allow
high performance over packet switched networks while preserving	XMODEM's
simplicity.

The initial concept would add a	block number to	the ACK	and NAK	characters
used by	XMODEM.	 The resultant protocol	would allow the	sender to send
more 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 indicate
the block number.

Pure binary was	unsuitable for ZMODEM because binary code combinations
won't pass bidirectionally through some	modems,	networks and operating
systems.  Other	operating systems may not be able to recognize something
coming back[1] unless a	break signal or	a system dependent code	or
sequence is present.  By the time all this and other problems with the