zmodem.doc

计算机的modem协议,给大家做一个参考吧。

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 zsbhdr transmits a	binary header.	The function zgethdr
receives a binary or hex header.

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


7.3.2  32 Bit CRC Binary Header
A "32 bit CRC" Binary header is	similar	to a Binary Header, except the
ZBIN (A) character is replaced by a ZBIN32 (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 Txfcs32 may	be set TRUE for	32 bit CRC iff the
receiver indicates the capability with the CANFC32 bit.	 The zgethdr,
zsdata and zrdata functions automatically adjust to the	type of	Frame
Check Sequence being used.
		   Figure 3.  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  HEX Header
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 8-3-87  Typeset 8-4-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 zgethdr
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 zgethdr 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 zshhdr sends a hex	header.

			  Figure 4.  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 8-3-87  Typeset 8-4-87			15







Chapter	7		     ZMODEM Protocol				16



7.4  Binary Data Subpackets

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 zsdata sends a data subpacket.  The function zrdata receives
a data subpacket.

7.5  ASCII Encoded Data	Subpacket

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.  PROTOCOL TRANSACTION OVERVIEW

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  Session Startup

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







Chapter	8		     ZMODEM Protocol				17



as a list of the files requested, etc.

Then the sender	may send a ZRQINIT header.  The	ZRQINIT	header causes a
previously started receive program to send its ZRINIT header without
delay.

In an interactive or conversational mode, the receiving	application may
monitor	the data stream	for ZDLE.  The following characters may	be scanned
for B00	indicating a ZRQINIT header, a command to download a command or
data.

The sending program awaits a command from the receiving	program	to start
file transfers.	 If a "C", "G",	or NAK is received, an XMODEM or YMODEM
file transfer is indicated, and	file transfer(s) use the YMODEM	protocol.
Note: With ZMODEM and YMODEM, the sending program provides the file name,
but not	with XMODEM.

In case	of garbled data, the sending program can repeat	the invitation to
receive	a number of times until	a session starts.

When the ZMODEM	receive	program	starts,	it immediately sends a ZRINIT
header to initiate ZMODEM file transfers, or a ZCHALLENGE header to verify
the sending program.  The receive program resends its header at	response
time (default 10 second) intervals for a suitable period of time (40
seconds	total) before falling back to YMODEM protocol.

If the receiving program receives a ZRQINIT header, it resends the ZRINIT
header.	 If the	sending	program	receives the ZCHALLENGE	header,	it places
the data in ZP0...ZP3 in an answering ZACK header.

If the receiving program receives a ZRINIT header, it is an echo
indicating that	the sending program is not operational.

Eventually the sending program correctly receives the ZRINIT header.

The sender may then send an optional ZSINIT frame to define the	receiving
program's Attn sequence, or to specify complete	control	character
escaping.[2]

If the ZSINIT header specifies ESCCTL or ESC8, a HEX header is used, and
the receiver activates the specified ESC modes before reading the
following data subpacket.

The receiver sends a ZACK header in response, optionally containing the


__________

 2. If the receiver specifies the same or higher level of escaping, the
    ZSINIT frame need not be sent unless an Attn sequence is needed.




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







Chapter	8		     ZMODEM Protocol				18



serial number of the receiving program,	or 0.

8.2  File Transmission

The sender then	sends a	ZFILE header with ZMODEM Conversion, Management,
and Transport options[3] followed by a ZCRCW data subpacket containing the
file name, file	length,	modification date, and other information identical
to that	used by	YMODEM Batch.

The receiver examines the file name, length, and date information provided
by the sender in the context of	the specified transfer options,	the
current	state of its file system(s), and local security	requirements.  The
receiving program should insure	the pathname and options are compatible
with its operating environment and local security requirements.

The receiver may respond with a	ZSKIP header, which makes the sender
proceed	to the next file (if any) in the batch.

       If the receiver has a file with the same	name and length,
       it may respond with a ZCRC header, which	requires the
       sender to perform a 32 bit CRC on the file and transmit the
       complement of the CRC in	a ZCRC header.[4] The receiver
       uses this information to	determine whether to accept the
       file or skip it.	 This sequence is triggered by the ZMCRC
       Management Option.

A ZRPOS	header from the	receiver initiates transmission	of the file data
starting at the	offset in the file specified in	the ZRPOS header.
Normally the receiver specifies	the data transfer to begin begin at
offset 0 in the	file.
       The receiver may	start the transfer further down	in the
       file.  This allows a file transfer interrupted by a loss
       or carrier or system crash to be	completed on the next
       connection without requiring the	entire file to be
       retransmitted.[5] If downloading	a file from a timesharing
       system that becomes sluggish, the transfer can be
       interrupted and resumed later with no loss of data.

The sender sends a ZDATA binary	header (with file position) followed by
one or more data subpackets.



__________

 3. See	below, under ZFILE header type.

 4. The	crc is initialized to 0xFFFFFFFF.

 5. This does not apply	to files that have been	translated.




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







Chapter	8		     ZMODEM Protocol				19



The receiver compares the file position	in the ZDATA header with the
number of characters successfully received to the file.	 If they do not
agree, a ZRPOS error response is generated to force the	sender to the
right position within the file.[6]

A data subpacket terminated by ZCRCG and CRC does not elicit a response
unless an error	is detected; more data subpacket(s) follow immediately.

       ZCRCQ data subpackets expect a ZACK response with the
       receiver's file offset if no error, otherwise a ZRPOS
       response	with the last good file	offset.	 Another data
       subpacket continues immediately.	 ZCRCQ subpackets are
       not used	if the receiver	does not indicate FDX ability
       with the	CANFDX bit.

ZCRCW data subpackets expect a response	before the next	frame is sent.
If the receiver	does not indicate overlapped I/O capability with the
CANOVIO	bit, or	sets a buffer size, the	sender uses the	ZCRCW to allow
the receiver to	write its buffer before	sending	more data.

       A zero length data frame	may be used as an idle
       subpacket to prevent the	receiver from timing out in
       case data is not	immediately available to the sender.

In the absence of fatal	error, the sender eventually encounters	end of
file.  If the end of file is encountered within	a frame, the frame is
closed with a ZCRCE data subpacket which does not elicit a response
except in case of error.

The sender sends a ZEOF	header with the	file ending offset equal to
the number of characters in the	file.  The receiver compares this
number with the	number of characters received.	If the receiver	has
received all of	the file, it closes the	file.  If the file close was
satisfactory, the receiver responds with ZRINIT.  If the receiver has
not received all the bytes of the file,	the receiver ignores the ZEOF
because	a new ZDATA is coming.	If the receiver	cannot properly	close
the file, a ZFERR header is sent.

       After all files are processed, any further protocol
       errors should not prevent the sending program from
       returning with a	success	status.





__________

 6. If the ZMSPARS option is used, the receiver	instead	seeks to the
    position given in the ZDATA	header.




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







Chapter	8		     ZMODEM Protocol				20



8.3  Session Cleanup

The sender closes the session with a ZFIN header.  The receiver
acknowledges this with its own ZFIN header.

When the sender	receives the acknowledging header, it sends two
characters, "OO" (Over and Out)	and exits to the operating system or
application that invoked it.  The receiver waits briefly for the "O"
characters, then exits whether they were received or not.

8.4  Session Abort Sequence

If the receiver	is receiving data in streaming mode, the Attn
sequence is executed to	interrupt data transmission before the Cancel
sequence is sent.  The Cancel sequence consists	of eight CAN
characters and ten backspace characters.  ZMODEM only requires five
Cancel characters, the other three are "insurance".

The trailing backspace characters attempt to erase the effects of the
CAN characters if they are received by a command interpreter.

       static char canistr[] = {
	24,24,24,24,24,24,24,24,8,8,8,8,8,8,8,8,8,8,0
       };






























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