Chapter	8		     ZMODEM Protocol				219.  STREAMING TECHNIQUES / ERROR RECOVERYIt is a	fact of	life that no single method of streaming	is applicableto a majority of today's computing and telecommunicationsenvironments.  ZMODEM provides several data streaming methodsselected according to the limitations of the sending environment,receiving environment, and transmission	channel(s).9.1  Full Streaming with SamplingIf the receiver	can overlap serial I/O with disk I/O, and if thesender can sample the reverse channel for the presence of datawithout	having to wait,	full streaming can be used with	no Attnsequence required.  The	sender begins data transmission	with a ZDATAheader and continuous ZCRCG data subpackets.  When the receiverdetects	an error, it executes the Attn sequence	and then sends aZRPOS header with the correct position within the file.At the end of each transmitted data subpacket, the sender checks forthe presence of	an error header	from the receiver.  To do this,	thesender samples the reverse data	stream for the presence	of either aZPAD or	CAN character.[1] Flow control characters (if present) areacted upon.Other characters (indicating line noise) increment a counter which isreset whenever the sender waits	for a header from the receiver.	 Ifthe counter overflows, the sender sends	the next data subpacket	asZCRCW, and waits for a response.ZPAD indicates some sort of error header from the receiver.  A CANsuggests the user is attempting	to "stop the bubble machine" bykeyboarding CAN	characters.  If	one of these characters	is seen, anempty ZCRCE data subpacket is sent.  Normally, the receiver will havesent an	ZRPOS or other error header, which will	force the sender toresume transmission at a different address, or take other action.  Inthe unlikely event the ZPAD or CAN character was spurious, thereceiver 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			21Chapter	9		     ZMODEM Protocol				22A ZRPOS	header resets the sender's file	offset to the correctposition.  If possible,	the sender should purge	its output buffersand/or networks	of all unprocessed output data,	to minimize theamount of unwanted data	the receiver must discard before receivingdata starting at the correct file offset.  The next transmitted	dataframe should be	a ZCRCW	frame followed by a wait to guaranteecomplete flushing of the network's memory.If the receiver	gets a ZACK header with	an address that	disagreeswith the sender	address, it is ignored,	and the	sender waits foranother	header.	 A ZFIN, ZABORT, or TIMEOUT terminates the session; aZSKIP terminates the processing	of this	file.The reverse channel is then sampled for	the presence of	anotherheader 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	ZDATAheader followed	by data	subpackets.9.1.1  Window ManagementWhen sending data through a network, some nodes	of the network storedata while it is transferred to	the receiver.  7000 bytes and more oftransient storage have been observed.  Such a large amount of storagecauses the transmitter to "get ahead" of the reciever.	This can befatal with MEGAlink and	other protocols	that depend on timelynotification of	errors from the	receiver.  This	condition is notfatal with ZMODEM, but it does slow error recovery.To manage the window size, the sending program uses ZCRCQ datasubpackets to trigger ZACK headers from	the receiver.  The returningZACK headers inform the	sender of the receiver's progress.  When thewindow size (current transmitter file offset - last reported receiverfile offset) exceeds a specified value,	the sender waits for aZACK[5]	packet with a receiver file offset that	reduces	the windowsize.Unix sz	versions beginning with	May 9 1987 control the window sizewith the "-w N"	option,	where N	is the maximum window size.  Pro-YAM,ZCOMM and DSZ versions beginning with May 9 1987 control the windowsize with "zmodem pwN".	 This is compatible with previous versions ofthese 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 flowChapter	9		Rev 8-3-87  Typeset 8-4-87			22Chapter	9		     ZMODEM Protocol				239.2  Full Streaming with Reverse InterruptThe above method cannot	be used	if the reverse data stream cannot besampled	without	entering an I/O	wait.  An alternate method is toinstruct the receiver to interrupt the sending program when an erroris detected.The receiver can interrupt the sender with a control character,	breaksignal,	or combination thereof,	as specified in	the Attn sequence.After executing	the Attn sequence, the receiver	sends a	hex ZRPOSheader to force	the sender to resend the lost data.When the sending program responds to this interrupt, it	reads a	HEXheader (normally ZRPOS)	from the receiver and takes the	actiondescribed in the previous section.  The	Unix sz.c program uses asetjmp/longjmp call to catch the interrupt generated by	the Attnsequence.  Catching the	interrupt activates the	getinsync() functionto read	the receiver's error header and	take appropriate action.When compiled for standard SYSTEM III/V	Unix, sz.c uses	an Attnsequence of Ctrl-C followed by a 1 second pause	to interrupt thesender,	then give the sender (Unix) time to prepare for	thereceiver's error header.9.3  Full Streaming with Sliding WindowIf none	of the above methods is	applicable, hope is not	yet lost.  Ifthe sender can buffer responses	from the receiver, the sender can useZCRCQ data subpackets to get ACKs from the receiver withoutinterrupting the transmission of data.	After a	sufficient number ofZCRCQ data subpackets have been	sent, the sender can read one of theheaders	that should have arrived in its	receive	interrupt buffer.A problem with this method is the possibility of wasting an excessiveamount of time responding to the receiver's error header.  It may bepossible to program the	receiver's Attn	sequence to flush thesender'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			23Chapter	9		     ZMODEM Protocol				249.4  Full Streaming over Error Free ChannelsFile transfer protocols	predicated on the existence of an error	freeend to end communications channel have been proposed from time totime.  Such channels have proven to be more readily available intheory than in actuality.  The frequency of undetected errorsincreases when modem scramblers	have more bits than the	errordetecting CRC.A ZMODEM sender	assuming an error free channel with end	to end flowcontrol	can send the entire file in one	frame without any checking ofthe reverse stream.  If	this channel is	completely transparent,	onlyZDLE need be escaped.  The resulting protocol overhead for averagelong files is less than	one per	cent.[7]9.5  Segmented StreamingIf the receiver	cannot overlap serial and disk I/O, it uses theZRINIT frame to	specify	a buffer length	which the sender will notoverflow.  The sending program sends a ZCRCW data subpacket and	waitsfor a ZACK header before sending the next segment of the file.If the sending program supports	reverse	data stream sampling orinterrupt, 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 closelyapproach that of full streaming.  For example, 16kb segmentedstreaming adds about 3 per cent	to full	streaming ZMODEM filetransfer times when the	round trip delay is five seconds.10.  ATTENTION SEQUENCEThe receiving program sends the	Attn sequence whenever it detects anerror and needs	to interrupt the sending program.The default Attn string	value is empty (no Attn	sequence).  Thereceiving program resets Attn to the empty default before eachtransfer 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'sChapter	10		Rev 8-3-87  Typeset 8-4-87			24Chapter	10		     ZMODEM Protocol				25Two meta-characters perform special functions:   + \335 (octal) Send a break signal   + \336 (octal) Pause	one second11.  FRAME TYPESThe numeric values for the values shown	in boldface are	given inzmodem.h.  Unused bits and unused bytes	in the header (ZP0...ZP3) areset to 0.11.1  ZRQINITSent by	the sending program, to	trigger	the receiving program to sendits ZRINIT header.  This avoids	the aggravating	startup	delayassociated with	XMODEM and Kermit transfers.  The sending program mayrepeat the receive invitation (including ZRQINIT) if a response	isnot obtained at	first.ZF0 contains ZCOMMAND if the program is	attempting to send a command,0 otherwise.11.2  ZRINITSent by	the receiving program.	ZF0 and	ZF1 contain the	 bitwise orof 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 0if nonstop I/O is allowed.11.3  ZSINITThe Sender sends flags followed	by a binary data subpacket terminatedwith 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 escapedChapter	11		Rev 8-3-87  Typeset 8-4-87			25Chapter	11		     ZMODEM Protocol				26*/The data subpacket contains the	null terminated	Attn sequence,maximum	length 32 bytes	including the terminating null.11.4  ZACKAcknowledgment to a ZSINIT frame, ZCHALLENGE header, ZCRCQ or ZCRCWdata subpacket.	 ZP0 to	ZP3 contain file offset.  The response toZCHALLENGE contains the	same 32	bit number received in the ZCHALLENGEheader.11.5  ZFILEThis frame denotes the beginning of a file transmission	attempt.ZF0, ZF1, and ZF2 may contain options.	A value	of 0 in	each of	thesebytes implies no special treatment.  Options specified to thereceiver override options specified to the sender with the exceptionof ZCBIN which overrides any other Conversion Option given to thesender or receiver.11.5.1	ZF0: Conversion	OptionIf the receiver	does not recognize the Conversion Option, anapplication dependent default conversion may apply.ZCBIN "Binary" transfer	- inhibit conversion unconditionallyZCNL 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			26Chapter	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	OptionIf the receiver	does not recognize the Management Option, thefile should be transferred normally.The ZMSKNOLOC bit instructs the	receiver to bypass thecurrent	file if	the receiver does not have a file with thesame name.Five bits (defined by ZMMASK) define the following set ofmutually 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