zmodem.doc

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

as a list of the files requested, etc.

Then the sender	may send a ZZZZRRRRQQQQIIIINNNNIIIITTTT header.  The	ZZZZRRRRQQQQIIIINNNNIIIITTTT	header causes a
previously started receive program to send its ZZZZRRRRIIIINNNNIIIITTTT 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 BBBB00000000	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 ZZZZRRRRIIIINNNNIIIITTTT
header to initiate ZMODEM file transfers, or a ZZZZCCCCHHHHAAAALLLLLLLLEEEENNNNGGGGEEEE header to verify
the sending program.  The receive program resends its header at	_r_e_s_p_o_n_s_e
_t_i_m_e (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 ZZZZRRRRQQQQIIIINNNNIIIITTTT header, it resends the ZZZZRRRRIIIINNNNIIIITTTT
header.	 If the	sending	program	receives the ZZZZCCCCHHHHAAAALLLLLLLLEEEENNNNGGGGEEEE	header,	it places
the data in ZP0...ZP3 in an answering ZZZZAAAACCCCKKKK header.

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

Eventually the sending program correctly receives the ZZZZRRRRIIIINNNNIIIITTTT header.

The sender may then send an optional ZZZZSSSSIIIINNNNIIIITTTT frame to define the	receiving
program's AAAAttttttttnnnn 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 ZZZZAAAACCCCKKKK 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 10-27-87  Typeset 10-27-87			17







Chapter	8		     ZMODEM Protocol				18



serial number of the receiving program,	or 0.

8.2  FFFFiiiilllleeee TTTTrrrraaaannnnssssmmmmiiiissssssssiiiioooonnnn

The sender then	sends a	ZZZZFFFFIIIILLLLEEEE 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	ZZZZSSSSKKKKIIIIPPPP 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 ZZZZCCCCRRRRCCCC header, which	requires the
       sender to perform a 32 bit CRC on the file and transmit the
       complement of the CRC in	a ZZZZCCCCRRRRCCCC 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 ZZZZRRRRPPPPOOOOSSSS	header from the	receiver initiates transmission	of the file data
starting at the	offset in the file specified in	the ZZZZRRRRPPPPOOOOSSSS 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 ZZZZDDDDAAAATTTTAAAA 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 10-27-87  Typeset 10-27-87			18







Chapter	8		     ZMODEM Protocol				19



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

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

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

ZZZZCCCCRRRRCCCCWWWW data subpackets expect a response	before the next	frame is sent.
If the receiver	does not indicate overlapped I/O capability with the
CCCCAAAANNNNOOOOVVVVIIIIOOOO	bit, or	sets a buffer size, the	sender uses the	ZZZZCCCCRRRRCCCCWWWW 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 ZZZZCCCCRRRRCCCCEEEE data subpacket which does not elicit a response
except in case of error.

The sender sends a ZZZZEEEEOOOOFFFF	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 ZZZZRRRRIIIINNNNIIIITTTT.  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 ZZZZFFFFEEEERRRRRRRR 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 10-27-87  Typeset 10-27-87			19







Chapter	8		     ZMODEM Protocol				20



8.3  SSSSeeeessssssssiiiioooonnnn CCCClllleeeeaaaannnnuuuupppp

The sender closes the session with a ZZZZFFFFIIIINNNN header.  The receiver
acknowledges this with its own ZZZZFFFFIIIINNNN 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  SSSSeeeessssssssiiiioooonnnn AAAAbbbboooorrrrtttt SSSSeeeeqqqquuuueeeennnncccceeee

If the receiver	is receiving data in streaming mode, the AAAAttttttttnnnn
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 10-27-87  Typeset 10-27-87			20







Chapter	8		     ZMODEM Protocol				21



9.  SSSSTTTTRRRREEEEAAAAMMMMIIIINNNNGGGG TTTTEEEECCCCHHHHNNNNIIIIQQQQUUUUEEEESSSS //// EEEERRRRRRRROOOORRRR RRRREEEECCCCOOOOVVVVEEEERRRRYYYY

It is a	fact of	life that no single method of streaming	is applicable
to a majority of today's computing and telecommunications
environments.  ZMODEM provides several data streaming methods
selected according to the limitations of the sending environment,
receiving environment, and transmission	channel(s).


9.1  FFFFuuuullllllll SSSSttttrrrreeeeaaaammmmiiiinnnngggg wwwwiiiitttthhhh SSSSaaaammmmpppplllliiiinnnngggg

If the receiver	can overlap serial I/O with disk I/O, and if the
sender can sample the reverse channel for the presence of data
without	having to wait,	full streaming can be used with	no AAAAttttttttnnnn
sequence required.  The	sender begins data transmission	with a ZZZZDDDDAAAATTTTAAAA
header and continuous ZZZZCCCCRRRRCCCCGGGG data subpackets.  When the receiver
detects	an error, it executes the AAAAttttttttnnnn sequence	and then sends a
ZZZZRRRRPPPPOOOOSSSS header with the correct position within the file.

At the end of each transmitted data subpacket, the sender checks for
the presence of	an error header	from the receiver.  To do this,	the
sender samples the reverse data	stream for the presence	of either a
ZPAD or	CAN character.[1] Flow control characters (if present) are
acted upon.

Other characters (indicating line noise) increment a counter which is
reset whenever the sender waits	for a header from the receiver.	 If
the counter overflows, the sender sends	the next data subpacket	as
ZCRCW, and waits for a response.

ZPAD indicates some sort of error header from the receiver.  A CAN
suggests the user is attempting	to "stop the bubble machine" by
keyboarding CAN	characters.  If	one of these characters	is seen, an
empty ZCRCE data subpacket is sent.  Normally, the receiver will have
sent an	ZRPOS or other error header, which will	force the sender to
resume transmission at a different address, or take other action.  In
the unlikely event the ZPAD or CAN character was spurious, the
receiver will time out and send	a ZRPOS	header.[2]

Then the receiver's response header is read and	acted upon.[3]


__________

 1. The	call to	rdchk()	in sssszzzz....cccc	performs this function.

 2. The	obvious	choice of ZCRCW	packet,	which would trigger an ZACK from
    the	receiver, is not used because multiple in transit frames could
    result if the channel has a	long propagation delay.

 3. The	call to	getinsync() in sssszzzz....cccc performs this function.



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







Chapter	9		     ZMODEM Protocol				22



A ZZZZRRRRPPPPOOOOSSSS	header resets the sender's file	offset to the correct
position.  If possible,	the sender should purge	its output buffers
and/or networks	of all unprocessed output data,	to minimize the
amount of unwanted data	the receiver must discard before receiving
data starting at the correct file offset.  The next transmitted	data
frame should be	a ZCRCW	frame followed by a wait to guarantee
complete flushing of the network's memory.

If the receiver	gets a ZZZZAAAACCCCKKKK header with	an address that	disagrees
with the sender	address, it is ignored,	and the	sender waits for
another	header.	 A ZZZZFFFFIIIINNNN, ZZZZAAAABBBBOOOORRRRTTTT, or TTTTIIIIMMMMEEEEOOOOUUUUTTTT terminates the session; a
ZZZZSSSSKKKKIIIIPPPP terminates the processing	of this	file.

The reverse channel is then sampled for	the presence of	another
header from the	receiver.[4] if	one is detected, the getinsync()
function is again called to read another error header.	Otherwise,
transmission resumes at	the (possibly reset) file offset with a	ZZZZDDDDAAAATTTTAAAA
header followed	by data	subpackets.


9.1.1  WWWWiiiinnnnddddoooowwww MMMMaaaannnnaaaaggggeeeemmmmeeeennnntttt
When sending data through a network, some nodes	of the network store
data while it is transferred to	the receiver.  7000 bytes and more of