zmodem.doc

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

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 8-3-87  Typeset 8-4-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 wndesr
    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 8-3-87  Typeset 8-4-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 8-3-87  Typeset 8-4-87			 9







Chapter	5		     ZMODEM Protocol				10



5.  ROSETTA STONE

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.  ZMODEM REQUIREMENTS

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  File Contents

6.1.1  Binary Files
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 8-3-87  Typeset 8-4-87			10







Chapter	6		     ZMODEM Protocol				11



6.1.2  Text Files
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	 ASCII End of Line
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 ZCNL bit to force the
receiving program to convert the received end of line to its local end of
line convention.[3]






















__________

 3. Files that have been translated in such a way as to	modify their
    length cannot be updated with the ZCRECOV Conversion Option.




Chapter	6		Rev 8-3-87  Typeset 8-4-87			11







Chapter	6		     ZMODEM Protocol				12



7.  ZMODEM BASICS

7.1  Packetization

ZMODEM frames differ somewhat from XMODEM blocks.  XMODEM blocks are not
used for the following reasons:

 + Block numbers are limited to	256

 + No provision	for variable length blocks

 + Line	hits corrupt protocol signals, causing failed file transfers.  In
   particular, modem errors sometimes generate false block numbers, false
   EOTs	and false ACKs.	 False ACKs are	the most troublesome as	they cause
   the sender to lose synchronization with the receiver.

   State of the	art programs such as Professional-YAM and ZCOMM	overcome
   some	of these weaknesses with clever	proprietary code, but a	stronger
   protocol is desired.

 + It is difficult to determine	the beginning and ends of XMODEM blocks
   when	line hits cause	a loss of synchronization.  This precludes rapid
   error recovery.

7.2  Link Escape Encoding

ZMODEM achieves	data transparency by extending the 8 bit character set
(256 codes) with escape	sequences based	on the ZMODEM data link	escape
character ZDLE.[1]

Link Escape coding permits variable length data	subpackets without the
overhead of a separate byte count.  It allows the beginning of frames to
be detected without special timing techniques, facilitating rapid error
recovery.

Link Escape coding does	add some overhead.  The	worst case, a file
consisting entirely of escaped characters, would incur a 50% overhead.

The ZDLE character is special.	ZDLE represents	a control sequence of some
sort.  If a ZDLE character appears in binary data, it is prefixed with
ZDLE, then sent	as ZDLEE.

The value for ZDLE is octal 030	(ASCII CAN).  This particular value was
chosen to allow	a string of 5 consecutive CAN characters to abort a ZMODEM


__________

 1. This and other constants are defined in the	zmodem.h include file.
    Please note	that constants with a leading 0	are octal constants in C.




Chapter	7		Rev 8-3-87  Typeset 8-4-87			12







Chapter	7		     ZMODEM Protocol				13



session, compatible with YMODEM	session	abort.

Since CAN is not used in normal	terminal operations, interactive
applications and communications	programs can monitor the data flow for
ZDLE.  The following characters	can be scanned to detect the ZRQINIT
header,	the invitation to automatically	download commands or files.

Receipt	of five	successive CAN characters will abort a ZMODEM session.
Eight CAN characters are sent.

The receiving program decodes any sequence of ZDLE followed by a byte with
bit 6 set and bit 5 reset (upper case letter, either parity) to	the
equivalent control character by	inverting bit 6.  This allows the
transmitter to escape any control character that cannot	be sent	by the
communications medium.	In addition, the receiver recognizes escapes for
0177 and 0377 should these characters need to be escaped.

ZMODEM software	escapes	ZDLE, 020, 0220, 021, 0221, 023, and 0223.  If
preceded by 0100 or 0300 (@), 015 and 0215 are also escaped to protect the
Telenet	command	escape CR-@-CR.	 The receiver ignores 021, 0221, 023, and
0223 characters	in the data stream.

The ZMODEM routines in zm.c accept an option to	escape all control
characters, to allow operation with less transparent networks.	This
option can be given to either the sending or receiving program.

7.3  Header

All ZMODEM frames begin	with a header which may	be sent	in binary or HEX
form.  ZMODEM uses a single routine to recognize binary	and hex	headers.
Either form of the header contains the same raw	information:

 + A type byte[2] [3]

 + Four	bytes of data indicating flags and/or numeric quantities depending
   on the frame	type







__________

 2. The	frame types are	cardinal numbers beginning with	0 to minimize
    state transition table memory requirements.

 3. Future extensions to ZMODEM	may use	the high order bits of the type
    byte to indicate thread selection.




Chapter	7		Rev 8-3-87  Typeset 8-4-87			13







Chapter	7		     ZMODEM Protocol				14



		   Figure 1.  Order of Bytes in	Header

		   TYPE:  frame	type
		   F0: Flags least significant byte
		   P0: file Position least significant
		   P3: file Position most significant

			   TYPE	 F3 F2 F1 F0
			   -------------------
			   TYPE	 P0 P1 P2 P3

7.3.1  16 Bit CRC Binary Header
A binary header	is sent	by the sending program to the receiving	program.