zmodem.doc

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

__________

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




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







Chapter	6		     ZMODEM Protocol				12



7.  ZZZZMMMMOOOODDDDEEEEMMMM BBBBAAAASSSSIIIICCCCSSSS

7.1  PPPPaaaacccckkkkeeeettttiiiizzzzaaaattttiiiioooonnnn

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

 o+ Block numbers are limited to	256

 o+ No provision	for variable length blocks

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

 o+ 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  LLLLiiiinnnnkkkk EEEEssssccccaaaappppeeee EEEEnnnnccccooooddddiiiinnnngggg

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	_z_m_o_d_e_m._h include file.
    Please note	that constants with a leading 0	are octal constants in C.




Chapter	7	      Rev 10-27-87  Typeset 10-27-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  HHHHeeeeaaaaddddeeeerrrr

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:

 o+ A type byte[2] [3]

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







Chapter	7		     ZMODEM Protocol				14



		   FFFFiiiigggguuuurrrreeee 1111....  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  11116666 BBBBiiiitttt CCCCRRRRCCCC BBBBiiiinnnnaaaarrrryyyy HHHHeeeeaaaaddddeeeerrrr
A binary header	is sent	by the sending program to the receiving	program.
ZDLE encoding accommodates XON/XOFF flow control.

A binary header	begins with the	sequence ZPAD, ZDLE, ZBIN.

The frame type byte is ZDLE encoded.

The four position/flags	bytes are ZDLE encoded.

A two byte CRC of the frame type and position/flag bytes is ZDLE encoded.

0 or more binary data subpackets with 16 bit CRC will follow depending on
the frame type.

The function _z_s_b_h_d_r transmits a	binary header.	The function _z_g_e_t_h_d_r
receives a binary or hex header.

		   FFFFiiiigggguuuurrrreeee 2222....  16 Bit CRC Binary	Header
	    * ZDLE A TYPE F3/P0	F2/P1 F1/P2 F0/P3 CRC-1	CRC-2


7.3.2  33332222 BBBBiiiitttt CCCCRRRRCCCC BBBBiiiinnnnaaaarrrryyyy HHHHeeeeaaaaddddeeeerrrr
A "32 bit CRC" Binary header is	similar	to a Binary Header, except the
ZZZZBBBBIIIINNNN (A) character is replaced by a ZZZZBBBBIIIINNNN33332222 (C) character, and four
characters of CRC are sent.  0 or more binary data subpackets with 32 bit
CRC will follow	depending on the frame type.

The common variable _T_x_f_c_s_3_2 may	be set TRUE for	32 bit CRC iff the
receiver indicates the capability with the CCCCAAAANNNNFFFFCCCC33332222 bit.	 The zgethdr,
zsdata and zrdata functions automatically adjust to the	type of	Frame
Check Sequence being used.
		   FFFFiiiigggguuuurrrreeee 3333....  32 Bit CRC Binary	Header
      *	ZDLE C TYPE F3/P0 F2/P1	F1/P2 F0/P3 CRC-1 CRC-2	CRC-3 CRC-4


7.3.3  HHHHEEEEXXXX HHHHeeeeaaaaddddeeeerrrr
The receiver sends responses in	hex headers.  The sender also uses hex
headers	when they are not followed by binary data subpackets.




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







Chapter	7		     ZMODEM Protocol				15



Hex encoding protects the reverse channel from random control characters.
The hex	header receiving routine ignores parity.

Use of Kermit style encoding for control and paritied characters was
considered and rejected	because	of increased possibility of interacting
with some timesharing systems' line edit functions.  Use of HEX	headers
from the receiving program allows control characters to	be used	to
interrupt the sender when errors are detected.	A HEX header may be used
in place of a binary header wherever convenient.  If a data packet follows
a HEX header, it is protected with CRC-16.

A hex header begins with the sequence ZPAD, ZPAD, ZDLE,	ZHEX.  The _z_g_e_t_h_d_r
routine	synchronizes with the ZPAD-ZDLE	sequence.  The extra ZPAD
character allows the sending program to	detect an asynchronous header
(indicating an error condition)	and then call _z_g_e_t_h_d_r to receive the
header.

The type byte, the four	position/flag bytes, and the 16	bit CRC	thereof
are sent in hex	using the character set	01234567890abcdef.  Upper case hex
digits are not allowed;	they false trigger XMODEM and YMODEM programs.
Since this form	of hex encoding	detects	many patterns of errors,
especially missing characters, a hex header with 32 bit	CRC has	not been
defined.

A carriage return and line feed	are sent with HEX headers.  The	receive
routine	expects	to see at least	one of these characters, two if	the first
is CR.	The CR/LF aids debugging from printouts, and helps overcome
certain	operating system related problems.

An XON character is appended to	all HEX	packets	except ZACK and	ZFIN.  The
XON releases the sender	from spurious XOFF flow	control	characters
generated by line noise, a common occurrence.  XON is not sent after ZACK
headers	to protect flow	control	in streaming situations.  XON is not sent
after a	ZFIN header to allow clean session cleanup.

0 or more data subpackets will follow depending	on the frame type.

The function _z_s_h_h_d_r sends a hex	header.

			  FFFFiiiigggguuuurrrreeee 4444....  HEX Header

      *	* ZDLE B TYPE F3/P0 F2/P1 F1/P2	F0/P3 CRC-1 CRC-2 CR LF	XON

(TYPE, F3...F0,	CRC-1, and CRC-2 are each sent as two hex digits.)










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







Chapter	7		     ZMODEM Protocol				16



7.4  BBBBiiiinnnnaaaarrrryyyy DDDDaaaattttaaaa SSSSuuuubbbbppppaaaacccckkkkeeeettttssss

Binary data subpackets immediately follow the associated binary	header
packet.	 A binary data packet contains 0 to 1024 bytes of data.
Recommended length values are 256 bytes	below 2400 bps,	512 at 2400 bps,
and 1024 above 4800 bps	or when	the data link is known to be relatively
error free.[4]

No padding is used with	binary data subpackets.	 The data bytes	are ZDLE
encoded	and transmitted.  A ZDLE and frameend are then sent, followed by
two or four ZDLE encoded CRC bytes.  The CRC accumulates the data bytes
and frameend.

The function _z_s_d_a_t_a sends a data subpacket.  The function _z_r_d_a_t_a receives
a data subpacket.

7.5  AAAASSSSCCCCIIIIIIII EEEEnnnnccccooooddddeeeedddd DDDDaaaattttaaaa	SSSSuuuubbbbppppaaaacccckkkkeeeetttt

The format of ASCII Encoded data subpackets is not currently specified.
These could be used for	server commands, or main transfers in 7	bit
environments.


8.  PPPPRRRROOOOTTTTOOOOCCCCOOOOLLLL TTTTRRRRAAAANNNNSSSSAAAACCCCTTTTIIIIOOOONNNN OOOOVVVVEEEERRRRVVVVIIIIEEEEWWWW

As with	the XMODEM recommendation, ZMODEM timing is receiver driven.  The
transmitter should not time out	at all,	except to abort	the program if no
headers	are received for an extended period of time, say one minute.[1]


8.1  SSSSeeeessssssssiiiioooonnnn SSSSttttaaaarrrrttttuuuupppp

To start a ZMODEM file transfer	session, the sending program is	called
with the names of the desired file(s) and option(s).

The sending program may	send the string	"rz\r" to invoke the receiving
program	from a possible	command	mode.  The "rz"	followed by carriage
return activates a ZMODEM receive program or command if	it were	not
already	active.

The sender may then display a message intended for human consumption, such


__________

 4. Strategies for adjusting the subpacket length for optimal results
    based on real time error rates are still evolving.	Shorter	subpackets
    speed error	detection but increase protocol	overhead slightly.

 1. Special considerations apply when sending commands.




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







Chapter	8		     ZMODEM Protocol				17