zmodem.doc

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

transient storage have been observed.  Such a large amount of storage
causes the transmitter to "get ahead" of the reciever.	This can be
fatal with MEGAlink and	other protocols	that depend on timely
notification of	errors from the	receiver.  This	condition is not
fatal with ZMODEM, but it does slow error recovery.

To manage the window size, the sending program uses ZCRCQ data
subpackets to trigger ZACK headers from	the receiver.  The returning
ZACK headers inform the	sender of the receiver's progress.  When the
window size (current transmitter file offset - last reported receiver
file offset) exceeds a specified value,	the sender waits for a
ZACK[5]	packet with a receiver file offset that	reduces	the window
size.

Unix _s_z	versions beginning with	May 9 1987 control the window size
with the "-w N"	option,	where N	is the maximum window size.  Pro-YAM,
ZCOMM and DSZ versions beginning with May 9 1987 control the window
size with "zmodem pwN".	 This is compatible with previous versions of
these programs.[6]


__________

 4. If sampling	is possible.

 5. ZRPOS and other error packets are handled normally.

 6. When used with modems or networks that simultaneously assert flow



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







Chapter	9		     ZMODEM Protocol				23



9.2  FFFFuuuullllllll SSSSttttrrrreeeeaaaammmmiiiinnnngggg wwwwiiiitttthhhh RRRReeeevvvveeeerrrrsssseeee IIIInnnntttteeeerrrrrrrruuuupppptttt

The above method cannot	be used	if the reverse data stream cannot be
sampled	without	entering an I/O	wait.  An alternate method is to
instruct the receiver to interrupt the sending program when an error
is detected.

The receiver can interrupt the sender with a control character,	break
signal,	or combination thereof,	as specified in	the AAAAttttttttnnnn sequence.
After executing	the AAAAttttttttnnnn sequence, the receiver	sends a	hex ZZZZRRRRPPPPOOOOSSSS
header to force	the sender to resend the lost data.

When the sending program responds to this interrupt, it	reads a	HEX
header (normally ZRPOS)	from the receiver and takes the	action
described in the previous section.  The	Unix sssszzzz....cccc program uses a
setjmp/longjmp call to catch the interrupt generated by	the AAAAttttttttnnnn
sequence.  Catching the	interrupt activates the	getinsync() function
to read	the receiver's error header and	take appropriate action.

When compiled for standard SYSTEM III/V	Unix, sssszzzz....cccc uses	an AAAAttttttttnnnn
sequence of Ctrl-C followed by a 1 second pause	to interrupt the
sender,	then give the sender (Unix) time to prepare for	the
receiver's error header.


9.3  FFFFuuuullllllll SSSSttttrrrreeeeaaaammmmiiiinnnngggg wwwwiiiitttthhhh SSSSlllliiiiddddiiiinnnngggg WWWWiiiinnnnddddoooowwww

If none	of the above methods is	applicable, hope is not	yet lost.  If
the sender can buffer responses	from the receiver, the sender can use
ZCRCQ data subpackets to get ACKs from the receiver without
interrupting the transmission of data.	After a	sufficient number of
ZCRCQ data subpackets have been	sent, the sender can read one of the
headers	that should have arrived in its	receive	interrupt buffer.

A problem with this method is the possibility of wasting an excessive
amount of time responding to the receiver's error header.  It may be
possible to program the	receiver's AAAAttttttttnnnn	sequence to flush the
sender's interrupt buffer before sending the ZRPOS header.







__________________________________________________________________________

    control with XON and XOFF characters aaaannnndddd pass XON characters that
    violate flow control, the receiving	program	should have a revision
    date of May	9 or later.




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







Chapter	9		     ZMODEM Protocol				24



9.4  FFFFuuuullllllll SSSSttttrrrreeeeaaaammmmiiiinnnngggg oooovvvveeeerrrr EEEErrrrrrrroooorrrr FFFFrrrreeeeeeee CCCChhhhaaaannnnnnnneeeellllssss

File transfer protocols	predicated on the existence of an error	free
end to end communications channel have been proposed from time to
time.  Such channels have proven to be more readily available in
theory than in actuality.  The frequency of undetected errors
increases when modem scramblers	have more bits than the	error
detecting CRC.

A ZMODEM sender	assuming an error free channel with end	to end flow
control	can send the entire file in one	frame without any checking of
the reverse stream.  If	this channel is	completely transparent,	only
ZDLE need be escaped.  The resulting protocol overhead for average
long files is less than	one per	cent.[7]

9.5  SSSSeeeeggggmmmmeeeennnntttteeeedddd SSSSttttrrrreeeeaaaammmmiiiinnnngggg

If the receiver	cannot overlap serial and disk I/O, it uses the
ZZZZRRRRIIIINNNNIIIITTTT frame to	specify	a buffer length	which the sender will not
overflow.  The sending program sends a ZZZZCCCCRRRRCCCCWWWW data subpacket and	waits
for a ZZZZAAAACCCCKKKK header before sending the next segment of the file.

If the sending program supports	reverse	data stream sampling or
interrupt, error recovery will be faster (on average) than a protocol
(such as YMODEM) that sends large blocks.

A sufficiently large receiving buffer allows throughput	to closely
approach that of full streaming.  For example, 16kb segmented
streaming adds about 3 per cent	to full	streaming ZMODEM file
transfer times when the	round trip delay is five seconds.


10.  AAAATTTTTTTTEEEENNNNTTTTIIIIOOOONNNN SSSSEEEEQQQQUUUUEEEENNNNCCCCEEEE

The receiving program sends the	AAAAttttttttnnnn sequence whenever it detects an
error and needs	to interrupt the sending program.

The default AAAAttttttttnnnn string	value is empty (no Attn	sequence).  The
receiving program resets Attn to the empty default before each
transfer session.

The sender specifies the Attn sequence in its optional ZSINIT frame.
The AAAAttttttttnnnn string	is terminated with a null.



__________

 7. One	in 256 for escaping ZDLE, about	two (four if 32	bit CRC	is used)
    in 1024 for	data subpacket CRC's




Chapter	10	      Rev 10-27-87  Typeset 10-27-87			24







Chapter	10		     ZMODEM Protocol				25



Two meta-characters perform special functions:

   o+ \335 (octal) Send a break signal

   o+ \336 (octal) Pause	one second


11.  FFFFRRRRAAAAMMMMEEEE TTTTYYYYPPPPEEEESSSS

The numeric values for the values shown	in boldface are	given in
_z_m_o_d_e_m._h.  Unused bits and unused bytes	in the header (ZP0...ZP3) are
set to 0.

11.1  ZZZZRRRRQQQQIIIINNNNIIIITTTT

Sent by	the sending program, to	trigger	the receiving program to send
its ZRINIT header.  This avoids	the aggravating	startup	delay
associated with	XMODEM and Kermit transfers.  The sending program may
repeat the receive invitation (including ZRQINIT) if a response	is
not obtained at	first.

ZF0 contains ZCOMMAND if the program is	attempting to send a command,
0 otherwise.

11.2  ZZZZRRRRIIIINNNNIIIITTTT

Sent by	the receiving program.	ZF0 and	ZF1 contain the	 bitwise or
of the receiver	capability flags:
#define	CANCRY	    8	/* Receiver can	decrypt	*/
#define	CANFDX	   01	/* Rx can send and receive true	FDX */
#define	CANOVIO	   02	/* Rx can receive data during disk I/O */
#define	CANBRK	   04	/* Rx can send a break signal */
#define	CANCRY	  010	/* Receiver can	decrypt	*/
#define	CANLZW	  020	/* Receiver can	uncompress */
#define	CANFC32	  040	/* Receiver can	use 32 bit Frame Check */
#define	ESCCTL	 0100	/* Receiver expects ctl	chars to be escaped
*/
#define	ESC8	 0200	/* Receiver expects 8th	bit to be escaped */

ZP0 and	ZP1 contain the	size of	the receiver's buffer in bytes,	or 0
if nonstop I/O is allowed.

11.3  ZZZZSSSSIIIINNNNIIIITTTT

The Sender sends flags followed	by a binary data subpacket terminated
with ZZZZCCCCRRRRCCCCWWWW.

/* Bit Masks for ZSINIT	flags byte ZF0 */
#define	TESCCTL	0100   /* Transmitter expects ctl chars	to be escaped
*/
#define	TESC8	0200   /* Transmitter expects 8th bit to be escaped



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







Chapter	11		     ZMODEM Protocol				26



*/

The data subpacket contains the	null terminated	AAAAttttttttnnnn sequence,
maximum	length 32 bytes	including the terminating null.

11.4  ZZZZAAAACCCCKKKK

Acknowledgment to a ZZZZSSSSIIIINNNNIIIITTTT frame, ZZZZCCCCHHHHAAAALLLLLLLLEEEENNNNGGGGEEEE header, ZZZZCCCCRRRRCCCCQQQQ or ZZZZCCCCRRRRCCCCWWWW
data subpacket.	 ZP0 to	ZP3 contain file offset.  The response to
ZCHALLENGE contains the	same 32	bit number received in the ZCHALLENGE
header.

11.5  ZZZZFFFFIIIILLLLEEEE

This frame denotes the beginning of a file transmission	attempt.
ZF0, ZF1, and ZF2 may contain options.	A value	of 0 in	each of	these
bytes implies no special treatment.  Options specified to the
receiver override options specified to the sender with the exception
of ZZZZCCCCBBBBIIIINNNN which overrides any other Conversion Option given to the
sender or receiver.


11.5.1	ZZZZFFFF0000:::: CCCCoooonnnnvvvveeeerrrrssssiiiioooonnnn	OOOOppppttttiiiioooonnnn
If the receiver	does not recognize the Conversion Option, an
application dependent default conversion may apply.

ZZZZCCCCBBBBIIIINNNN "Binary" transfer	- inhibit conversion unconditionally

ZZZZCCCCNNNNLLLL Convert received end of line to local end of line
     convention.  The supported	end of line conventions	are
     CR/LF (most ASCII based operating systems except Unix
     and Macintosh), and NL (Unix).  Either of these two end
     of	line conventions meet the permissible ASCII
     definitions for Carriage Return and Line Feed/New Line.
     Neither the ASCII code nor	ZMODEM ZCNL encompass lines
     separated only by carriage	returns.  Other	processing
     appropriate to ASCII text files and the local operating
     system may	also be	applied	by the receiver.[1]

ZZZZCCCCRRRREEEECCCCOOOOVVVV	Recover/Resume interrupted file	transfer.  ZCREVOV is
     also useful for updating a	remote copy of a file that
     grows without resending of	old data.  If the destination
     file exists and is	no longer than the source, append to
     the destination file and start transfer at	the offset
     corresponding to the receiver's end of file.  This


__________

 1. Filtering RUBOUT, NULL, Ctrl-Z, etc.




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







Chapter	11		     ZMODEM Protocol				27



     option does not apply if the source file is shorter.
     Files that	have been converted (e.g., ZCNL) or subject
     to	a single ended Transport Option	cannot have their
     transfers recovered.

11.5.2	ZZZZFFFF1111:::: MMMMaaaannnnaaaaggggeeeemmmmeeeennnntttt	OOOOppppttttiiiioooonnnn
If the receiver	does not recognize the Management Option, the
file should be transferred normally.

The ZZZZMMMMSSSSKKKKNNNNOOOOLLLLOOOOCCCC bit instructs the	receiver to bypass the
current	file if	the receiver does not have a file with the
same name.

Five bits (defined by ZZZZMMMMMMMMAAAASSSSKKKK) define the following set of
mutually exclusive management options.

ZZZZMMMMNNNNEEEEWWWWLLLL Transfer	file if	destination file absent.  Otherwise,
     transfer file overwriting destination if the source file
     is	newer or longer.

ZZZZMMMMCCCCRRRRCCCC Compare the source and destination files.	 Transfer if
     file lengths or file polynomials differ.

ZZZZMMMMAAAAPPPPNNNNDDDD Append source file contents to the end of the existing
     destination file (if any).

ZZZZMMMMCCCCLLLLOOOOBBBB Replace existing	destination file (if any).

ZZZZMMMMDDDDIIIIFFFFFFFF Transfer	file if	destination file absent.  Otherwise,
     transfer file overwriting destination if files have
     different lengths or dates.

ZZZZMMMMPPPPRRRROOOOTTTT Protect destination file	by transferring	file only if
     the destination file is absent.

ZZZZMMMMNNNNEEEEWWWW Transfer file if destination file	absent.	 Otherwise,
     transfer file overwriting destination if the source file
     is	newer.

11.5.3	ZZZZFFFF2222:::: TTTTrrrraaaannnnssssppppoooorrrrtttt OOOOppppttttiiiioooonnnn
If the receiver	does not implement the particular transport
option,	the file is copied without conversion for later
processing.

ZZZZTTTTLLLLZZZZWWWW Lempel-Ziv compression.  Transmitted data	will be
     identical to that produced	by ccccoooommmmpppprrrreeeesssssss