zmodem.doc

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

Chapter	8		     ZMODEM Protocol				21



9.  STREAMING TECHNIQUES / ERROR RECOVERY

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  Full Streaming with Sampling

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 Attn
sequence required.  The	sender begins data transmission	with a ZDATA
header and continuous ZCRCG data subpackets.  When the receiver
detects	an error, it executes the Attn sequence	and then sends a
ZRPOS 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 sz.c	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 sz.c performs this function.



Chapter	9		Rev 8-3-87  Typeset 8-4-87			21







Chapter	9		     ZMODEM Protocol				22



A ZRPOS	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 ZACK header with	an address that	disagrees
with the sender	address, it is ignored,	and the	sender waits for
another	header.	 A ZFIN, ZABORT, or TIMEOUT terminates the session; a
ZSKIP 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	ZDATA
header followed	by data	subpackets.


9.1.1  Window Management
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
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 sz	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 8-3-87  Typeset 8-4-87			22







Chapter	9		     ZMODEM Protocol				23



9.2  Full Streaming with Reverse Interrupt

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 Attn sequence.
After executing	the Attn sequence, the receiver	sends a	hex ZRPOS
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 sz.c program uses a
setjmp/longjmp call to catch the interrupt generated by	the Attn
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, sz.c uses	an Attn
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  Full Streaming with Sliding Window

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 Attn	sequence to flush the
sender's interrupt buffer before sending the ZRPOS header.







__________________________________________________________________________

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




Chapter	9		Rev 8-3-87  Typeset 8-4-87			23







Chapter	9		     ZMODEM Protocol				24



9.4  Full Streaming over Error Free Channels

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  Segmented Streaming

If the receiver	cannot overlap serial and disk I/O, it uses the
ZRINIT frame to	specify	a buffer length	which the sender will not
overflow.  The sending program sends a ZCRCW data subpacket and	waits
for a ZACK 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.  ATTENTION SEQUENCE

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

The default Attn 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 Attn 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 8-3-87  Typeset 8-4-87			24







Chapter	10		     ZMODEM Protocol				25



Two meta-characters perform special functions:

   + \335 (octal) Send a break signal

   + \336 (octal) Pause	one second


11.  FRAME TYPES

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

11.1  ZRQINIT

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  ZRINIT

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  ZSINIT

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

/* 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 8-3-87  Typeset 8-4-87			25







Chapter	11		     ZMODEM Protocol				26



*/

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

11.4  ZACK

Acknowledgment to a ZSINIT frame, ZCHALLENGE header, ZCRCQ or ZCRCW
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  ZFILE

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 ZCBIN which overrides any other Conversion Option given to the
sender or receiver.


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

ZCBIN "Binary" transfer	- inhibit conversion unconditionally

ZCNL 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]

ZCRECOV	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 8-3-87  Typeset 8-4-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	ZF1: Management	Option
If the receiver	does not recognize the Management Option, the
file should be transferred normally.

The ZMSKNOLOC 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 ZMMASK) define the following set of
mutually exclusive management options.

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

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

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

ZMCLOB Replace existing	destination file (if any).

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

ZMPROT Protect destination file	by transferring	file only if