zmodem.doc

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

ZMODEM accommodates a wide variety of systems:

 o+ Microcomputers that cannot overlap disk and serial i/o

 o+ Microcomputers that cannot overlap serial send and receive

 o+ Computers and/or networks requiring XON/XOFF	flow control

 o+ 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 10-27-87  Typeset 10-27-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 _f_o_r _t_h_e _p_u_b_l_i_c _d_o_m_a_i_n 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 _Z_M_O_D_E_M
name.


4.  EEEEVVVVOOOOLLLLUUUUTTTTIIIIOOOONNNN OOOOFFFF ZZZZMMMMOOOODDDDEEEEMMMM

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
simple ACK/NAK sequences mentioned above were corrected, XMODEM's simple
ACK and	NACK characters	had evolved into a real	packet.	 The Frog was
riveting.

Managing the window[2] was another problem.  Experience	gained in
debugging The Source's SuperKermit protocol indicated a	window size of
about 1000 characters was needed at 1200 bps.  High speed modems require a


__________

 1. Without stopping for a response

 2. The	WINDOW is the data in transit between sender and receiver.




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







Chapter	4		     ZMODEM Protocol				 8



window of 20000	or more	characters for full throughput.	 Much of the
SuperKermit's inefficiency, complexity and debugging time centered around
its ring buffering and window management.  There had to	be a better way	to
get the	job done.

A sore point with XMODEM and its progeny is error recovery.  More to the
point, how can the receiver determine whether the sender has responded,	or
is ready to respond, to	a retransmission request?  XMODEM attacks the
problem	by throwing away characters until a certain period of silence.
Too short a time allows	a spurious pause in output (network or timesharing
congestion) to masquerade as error recovery.  Too long a timeout
devastates throughput, and allows a noisy line to lock up the protocol.
SuperKermit solves the problem with a distinct start of	packet character
(SOH).	WXMODEM	and ZMODEM use unique character	sequences to delineate the
start of frames.  SEAlink and MEGAlink do not address this problem.

A further error	recovery problem arises	in streaming protocols.	 How does
the receiver know when (or if) the sender has recognized its error signal?
Is the next packet the correct response	to the error signal?  Is it
something left over "in	the queue"?  Or	is this	new subpacket one of many
that will have to be discarded because the sender did not receive the
error signal?  How long	should this continue before sending another error
signal?	 How can the protocol prevent this from	degenerating into an
argument about mixed signals?

SuperKermit uses selective retransmission, so it can accept any	good
packet it receives.  Each time the SuperKermit receiver	gets a data
packet,	it must	decide which outstanding packet	(if any) it "wants most"
to receive, and	asks for that one.  In practice, complex software "hacks"
are needed to attain acceptable	robustness.[3]

For ZMODEM, we decided to forgo	the complexity of SuperKermit's	packet
assembly scheme	and its	associated buffer management logic and memory
requirements.

Another	sore point with	XMODEM and WXMODEM is the garbage added	to files.
This was acceptable with old CP/M files	which had no exact length, but not
with modern systems such as DOS	and Unix.  YMODEM uses file length
information transmitted	in the header block to trim the	output file, but
this causes data loss when transferring	files that grow	during a transfer.
In some	cases, the file	length may be unknown, as when data is obtained
from a process.	 Variable length data subpackets solve both of these


__________

 3. For	example, when SuperKermit encounters certain errors, the _w_n_d_e_s_r
    function is	called to determine the	next block to request.	A burst	of
    errors generates several wasteful requests to retransmit the same
    block.




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







Chapter	4		     ZMODEM Protocol				 9



problems.

Since some characters had to be	escaped	anyway,	there wasn't any point
wasting	bytes to fill out a fixed packet length	or to specify a	variable
packet length.	In ZMODEM, the length of data subpackets is denoted by
ending each subpacket with an escape sequence similar to BISYNC	and HDLC.

The end	result is a ZMOEM header containing a "frame type", four bytes of
supervisory information, and its own CRC.  Data	frames consist of a header
followed by 1 or more data subpackets.	In the absence of transmission
errors,	an entire file can be sent in one data frame.

Since the sending system may be	sensitive to numerous control characters
or strip parity	in the reverse data path, all of the headers sent by the
receiver are sent in hex.  A common lower level	routine	receives all
headers, allowing the main program logic to deal with headers and data
subpackets as objects.

With equivalent	binary (efficient) and hex (application	friendly) frames,
the sending program can	send an	"invitation to receive"	sequence to
activate the receiver without crashing the remote application with
unexpected control characters.

Going "back to scratch"	in the protocol	design presents	an opportunity to
steal good ideas from many sources and to add a	few new	ones.

From Kermit and	UUCP comes the concept of an initial dialog to exchange
system parameters.

ZMODEM generalizes Compuserve B	Protocol's host	controlled transfers to
single command AutoDownload and	command	downloading.  A	Security Challenge
discourages password hackers and Trojan	Horse authors from abusing
ZMODEM's power.

We were	also keen to the pain and $uffering of legions of
telecommunicators whose	file transfers have been ruined	by communications
and timesharing	faults.	 ZMODEM's file transfer	recovery and advanced file
management are dedicated to these kindred comrades.

After ZMODEM had been operational a short time,	Earl Hall pointed out the
obvious: ZMODEM's user friendly	AutoDownload was almost	useless	if the
user must assign transfer options to each of the sending and receiving
programs.  Now,	transfer options may be	specified to/by	the sending
program, which passes them to the receiving program in the ZFILE header.










Chapter	5	      Rev 10-27-87  Typeset 10-27-87			 9







Chapter	5		     ZMODEM Protocol				10



5.  RRRROOOOSSSSEEEETTTTTTTTAAAA SSSSTTTTOOOONNNNEEEE

Here are some definitions which	reflect	current	vernacular in the computer
media.	The attempt here is identify the file transfer protocol	rather
than specific programs.

FRAME	A ZMODEM frame consists	of a header and	0 or more data subpackets.

XMODEM	refers to the original 1977 file transfer etiquette introduced by
	Ward Christensen's MODEM2 program.  It's also called the MODEM or
	MODEM2 protocol.  Some who are unaware of MODEM7's unusual batch
	file mode call it MODEM7.  Other aliases include "CP/M Users's
	Group" and "TERM II FTP	3".  This protocol is supported	by most
	communications programs	because	it is easy to implement.

XMODEM/CRC replaces XMODEM's 1 byte checksum with a two	byte Cyclical
	Redundancy Check (CRC-16), improving error detection.

XMODEM-1k Refers to XMODEM-CRC with optional 1024 byte blocks.

YMODEM	refers to the XMODEM/CRC protocol with batch transmission and
	optional 1024 byte blocks as described in YMODEM.DOC.[1]


6.  ZZZZMMMMOOOODDDDEEEEMMMM RRRREEEEQQQQUUUUIIIIRRRREEEEMMMMEEEENNNNTTTTSSSS

ZMODEM requires	an 8 bit transfer medium.[1] ZMODEM escapes network
control	characters to allow operation with packet switched networks.  In
general, ZMODEM	operates over any path that supports XMODEM, and over many
that don't.

To support full	streaming,[2] the transmission path should either assert
flow control or	pass full speed	transmission without loss of data.
Otherwise the ZMODEM sender must manage	the window size.

6.1  FFFFiiiilllleeee CCCCoooonnnntttteeeennnnttttssss

6.1.1  BBBBiiiinnnnaaaarrrryyyy FFFFiiiilllleeeessss
ZMODEM places no constraints on	the information	content	of binary files,
except that the	number of bits in the file must	be a multiple of 8.



__________

 1. Available on TeleGodzilla as part of YZMODEM.ZOO

 1. The	ZMODEM design allows encoded packets for less transparent media.

 2. With XOFF and XON, or out of band flow control such	as X.25	or CTS




Chapter	6	      Rev 10-27-87  Typeset 10-27-87			10







Chapter	6		     ZMODEM Protocol				11



6.1.2  TTTTeeeexxxxtttt FFFFiiiilllleeeessss
Since ZMODEM is	used to	transfer files between different types of computer
systems, text files must meet minimum requirements if they are to be
readable on a wide variety of systems and environments.

Text lines consist of printing ASCII characters, spaces, tabs, and
backspaces.

6.1.2.1	 AAAASSSSCCCCIIIIIIII EEEEnnnndddd ooooffff LLLLiiiinnnneeee
The ASCII code definition allows text lines terminated by a CR/LF (015,
012) sequence, or by a NL (012)	character.  Lines logically terminated by
a lone CR (013)	are not	ASCII text.

A CR (013) without a linefeed implies overprinting, and	is not acceptable
as a logical line separator.  Overprinted lines	should print all important
characters in the last pass to allow CRT displays to display meaningful
text.  Overstruck characters may be generated by backspacing or	by
overprinting the line with CR (015) not	followed by LF.

Overstruck characters generated	with backspaces	should be sent with the
most important character last to accommodate CRT displays that cannot
overstrike.  The sending program may use the ZZZZCCCCNNNNLLLL bit to force the
receiving program to convert the received end of line to its local end of
line convention.[3]