zmodem.doc

DOS下采用中断接收数据的串口通讯的例子,很难找到的好东西!

	   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(Telebit PEP)
		     Compuserve:70007,2304  GEnie:CAF
		    UUCP: ...!tektronix!reed!omen!caf
























Chapter	0	      Rev 10-27-87  Typeset 10-27-87			 1







Chapter	0		     ZMODEM Protocol				 2



1.  IIIINNNNTTTTEEEENNNNDDDDEEEEDDDD AAAAUUUUDDDDIIIIEEEENNNNCCCCEEEE

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.  WWWWHHHHYYYY	DDDDEEEEVVVVEEEELLLLOOOOPPPP	ZZZZMMMMOOOODDDDEEEEMMMM????

Since its development half a decade ago, the Ward Christensen MMMMOOOODDDDEEEEMMMM
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 XXXXMMMMOOOODDDDEEEEMMMM.

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:

   o+ The awkward user interface	is suitable for	computer hobbyists.
     Multiple commands must be keyboarded to transfer each file.

   o+ Since commands must be given to both programs, simple menu	selections
     are not possible.

   o+ The short block length causes throughput to suffer	when used with
     timesharing systems, packet switched networks, satellite circuits,
     and buffered (error correcting) modems.

   o+ The 8 bit checksum	and unprotected	supervison allow undetected errors
     and disrupted file	transfers.

   o+ 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.

   o+ The transmitted file accumulates as many as 127 bytes of garbage.

   o+ The modification date and other file attributes are lost.

   o+ XMODEM requires _c_o_m_p_l_e_t_e 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.

   o+ Lack of public domain documentation and example programs have kept
     proprietary protocols such	as RRRReeeellllaaaayyyy,,,, BBBBllllaaaasssstttt,,,, 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 10-27-87  Typeset 10-27-87			 2







Chapter	2		     ZMODEM Protocol				 3



   o+ Link level	protocols such as XXXX....22225555,,,,	XXXX....PPPPCCCC,,,, and MMMMNNNNPPPP do not manage
     application to application	file transfers.

   o+ 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.

   o+ The KKKKeeeerrrrmmmmiiiitttt	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 CCCCyyyybbbbeeeerrrrnnnneeeettttiiiicccc DDDDaaaattttaaaa RRRReeeeccccoooovvvveeeerrrryyyy((((TTTTMMMM))))[2] improve reliability,
but are	not universally	available.  Some of the	XMODEM mutant protocols
have significant design	flaws of their own.

 o+ XXXXMMMMOOOODDDDEEEEMMMM----kkkk 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 10-27-87  Typeset 10-27-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.

 o+ YYYYMMMMOOOODDDDEEEEMMMM 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.

 o+ YYYYMMMMOOOODDDDEEEEMMMM----gggg 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.

 o+ WWWWXXXXMMMMOOOODDDDEEEEMMMM,,,, SSSSEEEEAAAAlllliiiinnnnkkkk,,,, and MMMMEEEEGGGGAAAAlllliiiinnnnkkkk 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
OOOOvvvveeeerrrrTTTThhhhrrrruuuusssstttteeeerrrr((((TTTTMMMM)))) and OOOOvvvveeeerrrrTTTThhhhrrrruuuusssstttteeeerrrr IIIIIIII((((TTTTMMMM)))).  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.  ZZZZMMMMOOOODDDDEEEEMMMM PPPPrrrroooottttooooccccoooollll DDDDeeeessssiiiiggggnnnn CCCCrrrriiiitttteeeerrrriiiiaaaa

The design of a	file transfer protocol is an engineering compromise
between	conflicting requirements:

3.1  EEEEaaaasssseeee ooooffff UUUUsssseeee

 o+ ZMODEM allows either	program	to initiate file transfers, passing
   commands and/or modifiers to	the other program.

 o+ File	names need be entered only once.

 o+ Menu	selections are supported.




Chapter	3	      Rev 10-27-87  Typeset 10-27-87			 4







Chapter	3		     ZMODEM Protocol				 5



 o+ Wild	Card names may be used with batch transfers.

 o+ Minimum keystrokes required to initiate transfers.

 o+ ZRQINIT frame sent by sending program can trigger automatic downloads.

 o+ ZMODEM can step down	to YMODEM if the other end does	not support
   ZMODEM.[1]

3.2  TTTThhhhrrrroooouuuugggghhhhppppuuuutttt

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.

  o+ Network applications with significant delays (relative to character
    transmission time) and low error rate

  o+ 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.

  o+ 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 10-27-87  Typeset 10-27-87			 5







Chapter	3		     ZMODEM Protocol				 6



3.3  IIIInnnntttteeeeggggrrrriiiittttyyyy aaaannnndddd RRRRoooobbbbuuuussssttttnnnneeeessssssss

Once a ZMODEM session is begun,	all transactions are protected with 16 or
32 bit CRC.[2] Complex proprietary techniques such as CCCCyyyybbbbeeeerrrrnnnneeeettttiiiicccc DDDDaaaattttaaaa
RRRReeeeccccoooovvvveeeerrrryyyy((((TTTTMMMM))))[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  EEEEaaaasssseeee ooooffff IIIImmmmpppplllleeeemmmmeeeennnnttttaaaattttiiiioooonnnn