zmodem.doc

国产CPU－龙芯（loongson)BIOS源代码

		If ZF0 contained ZCACK1, the receiver immediately responds with a
		ZCOMPL header with 0 status.

		Otherwise, the receiver responds with a ZCOMPL header when the
		operation is completed.  The exit status of the completed command is
		stored in ZP0...ZP3.  A 0 exit status implies nominal completion of
		the command.

		If the command causes a file to be transmitted, the command sender
		will see a ZRQINIT frame from the other computer attempting to send
		data.

		The sender examines ZF0 of the received ZRQINIT header to verify it
		is not an echo of its own ZRQINIT header.  It is illegal for the
		sending program to command the receiving program to send a command.

		If the receiver program does not implement command downloading, it
		may display the command to the standard error output, then return a
		ZCOMPL header.

	ZFILE FRAME FILE INFORMATION SUBPACKET
	--------------------------------------

		zmodem sends the same file information with the ZFILE frame data

		The pathname (file name) field is mandatory. each field after 
		pathname is optional and separated from the previous one by 
		a space. fields may not be skipped. the use of the optional
		fields is (by definition) optional to the receiver.

		PATHNAME
		--------

			The pathname (conventionally, the file name) is sent as a
			null terminated ASCII string. 
			No spaces are included in the pathname. 

			Filename Considerations

				- File names should be translated to lower case unless the
				  sending system supports upper/lower case file names. This
				  is a convenience for users of systems (such as Unix) which
				  store filenames in upper and lower case.

				- The receiver should accommodate file names in lower and
				  upper case.
	
				- When transmitting files between different operating
				  systems, file names must be acceptable to both the sender
				  and receiving operating systems.  If not, transformations
				  should be applied to make the file names acceptable. If
				  the transformations are unsuccessful, a new file name may
				  be invented be the receiving program.
	
				- If directories are included, they are delimited by /; i.e.,
	    		  "subdir/foo" is acceptable, "subdir\foo" is not.
	
		LENGTH
		------

			The length field is stored as a decimal string
			counting the number of data bytes in the file.

			The zmodem receiver uses the file length as an estimate only.
			It may be used to display an estimate of the transmission time,
			and may be compared with the amount of free disk space.  The
			actual length of the received file is determined by the data
			transfer. A file may grow after transmission commences, and
			all the data will be sent.

		MODIFICATION DATE
		-----------------

			The mod date is sent as an octal number giving the time the
			contents of the file were last changed measured in seconds from
			Jan 1 1970 Universal Coordinated Time (GMT).  A date of 0
			implies the modification date is unknown and should be left as
			the date the file is received.

			This standard format was chosen to eliminate ambiguities
			arising from transfers between different time zones.

		FILE MODE
		---------

			The file mode is stored as an octal string.
			Unless the file originated from a Unix system, the file mode is
			set to 0. 

		SERIAL NUMBER
		-------------

			set this field to 0.

		NUMBER OF FILES REMAINING
		-------------------------

			This field is coded as a decimal number, and includes the
			current file.  This field is an estimate, and incorrect values
			must not be allowed to cause loss of data.

		NUMBER OF BYTES REMAINING 
		-------------------------

			This field is coded as a decimal number, and includes the
			current file.  This field is an estimate, and incorrect values
			must not be allowed to cause loss of data. 

		FILE TYPE
		---------

			set this field to 0.

		The file information is terminated by a null.  If only the pathname
		is sent, the pathname is terminated with two nulls.  The length of
		the file information subpacket, including the trailing null, must
		not exceed 1024 bytes; a typical length is less than 64 bytes.

STREAMING TECHNIQUES / ERROR RECOVERY
-------------------------------------

	zmodem provides several data streaming methods
	selected according to the limitations of the sending environment,
	receiving environment, and transmission channel(s).
	
	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 receiver. 
		This condition is not fatal 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 packet with a receiver file offset that reduces the window
		size. ZRPOS and other error packets are handled normally.

	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 (using rdchk() or a similar mechanism)
		. 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.
		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.
		
		Then the receiver's response header is read and acted upon; starting
		with a resinchronize.
		
		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 (if sampling is possible). if one is detected
		another error header is read. Otherwise,
		transmission resumes at the (possibly reset) file offset with a ZDATA
		header followed by data subpackets.
	
	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. 
	
	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.

	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.

		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.

CONSTANTS
---------

	ASCII
	-----

		SOH			0x01
		STX			0x02
		EOT			0x04
		ENQ			0x05
		ACK			0x06
		LF			0x0a
		CR			0x0d
		XON			0x11
		XOFF		0x13
		NAK			0x15
		CAN			0x18

	ZMODEM	
	------

		ZPAD		0x2a	/* pad character; begins frames */
		ZDLE		0x18	/* ctrl-x zmodem escape */
		ZDLEE		0x58	/* escaped ZDLE */	

		ZBIN		0x41	/* binary frame indicator (CRC16) */
		ZHEX		0x42	/* hex frame indicator */
		ZBIN32		0x43	/* binary frame indicator (CRC32) */
		ZBINR32		0x44	/* run length encoded binary frame (CRC32) */

		ZVBIN		0x61	/* binary frame indicator (CRC16) */
		ZVHEX		0x62	/* hex frame indicator */
		ZVBIN32		0x63	/* binary frame indicator (CRC32) */
		ZVBINR32	0x64	/* run length encoded binary frame (CRC32) */

		ZRESC		0x7e	/* run length encoding flag / escape character */

	FRAME TYPES
	-----------

		ZRQINIT		0x00	/* request receive init (s->r) */
		ZRINIT		0x01	/* receive init (r->s) */
		ZSINIT		0x02	/* send init sequence (optional) (s->r) */
		ZACK		0x03	/* ack to ZRQINIT ZRINIT or ZSINIT (s<->r) */
		ZFILE		0x04	/* file name (s->r) */
		ZSKIP		0x05	/* skip this file (r->s) */
		ZNAK		0x06	/* last packet was corrupted (?) */
		ZABORT		0x07	/* abort batch transfers (?) */
		ZFIN		0x08	/* finish session (s<->r) */
		ZRPOS		0x09	/* resume data transmission here (r->s) */
		ZDATA		0x0a	/* data packet(s) follow (s->r) */
		ZEOF		0x0b	/* end of file reached (s->r) */
		ZFERR		0x0c	/* fatal read or write error detected (?) */
		ZCRC		0x0d	/* request for file CRC and response (?) */
		ZCHALLENGE	0x0e	/* security challenge (r->s) */
		ZCOMPL		0x0f	/* request is complete (?) */	
		ZCAN		0x10	/* pseudo frame; 
							   other end cancelled session with 5* CAN */
		ZFREECNT	0x11	/* request free bytes on file system (s->r) */
		ZCOMMAND	0x12	/* issue command (s->r) */
		ZSTDERR		0x13	/* output data to stderr (??) */

	ZDLE SEQUENCES
	--------------

		ZCRCE		0x68	/* CRC next, frame ends, header packet follows */
		ZCRCG		0x69	/* CRC next, frame continues nonstop */
		ZCRCQ		0x6a	/* CRC next, frame continuous, ZACK expected */
		ZCRCW		0x6b	/* CRC next, ZACK expected, end of frame */
		ZRUB0		0x6c	/* translate to rubout 0x7f */
		ZRUB1		0x6d	/* translate to rubout 0xff */

	RECEIVER CAPABILITY FLAGS
	-------------------------

		CANFDX		0x01	/* Rx can send and receive true full duplex */
		CANOVIO		0x02	/* Rx can receive data during disk I/O */
		CANBRK		0x04	/* Rx can send a break signal */
		CANCRY		0x08	/* Receiver can decrypt */
		CANLZW		0x10	/* Receiver can uncompress */
		CANFC32		0x20	/* Receiver can use 32 bit Frame Check */
		ESCCTL		0x40	/* Receiver expects ctl chars to be escaped
		ESC8		0x80	/* Receiver expects 8th bit to be escaped */