zmodem.doc

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

			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 ZCRCE data subpacket which does not elicit a response
		except in case of error.

		The sender sends a ZEOF 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 ZRINIT.  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 ZFERR header is sent.

		After all files are processed, any further protocol
		errors should not prevent the sending program from
		returning with a success status.

	SESSION CLEANUP
	---------------

		The sender closes the session with a ZFIN header.  The receiver
		acknowledges this with its own ZFIN header.

		When the sender receives the acknowledging header, it sends two
		characters, "OO" (Over and Out) and exits.
		The receiver waits briefly for the "O" characters, then exits
		whether they were received or not.

	SESSION ABORT SEQUENCE
	----------------------

		If the receiver is receiving data in streaming mode, the Attn
		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.

	       char ses_abort_seq[] = {
				24,24,24,24,24,24,24,24,8,8,8,8,8,8,8,8,8,8,0
	       };

	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.

FRAME TYPES
-----------

	The numeric values are listed at the end of this file.
	Unused bits and unused bytes in the header (ZP0...ZP3) are set to 0.

	ZRQINIT
	-------

		Sent by the sending program, to trigger the receiving program to send
		its ZRINIT header.  
		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.

	ZRINIT
	------

		Sent by the receiving program. ZF0 and ZF1 contain the  bitwise or
		of the receiver capability flags:

			CANCRY		receiver can decrypt
			CANFDX		receiver can send and receive true full duplex
			CANOVIO		receiver can receive data during disk I/O
			CANBRK		receiver can send a break signal
			CANCRY		receiver can decrypt
			CANLZW		receiver can uncompress
			CANFC32		receiver can use 32 bit Frame Check
			ESCCTL		receiver expects ctl chars to be escaped
			ESC8		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.

		while all these capabilities are nice in theory most zmodem implem-
		tations balk at anything other than 0,0. i.e. telix starts sending
		35 byte packets when CANFC32 is on.

	ZSINIT
	------

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

			TESCCTL		Transmitter expects ctl chars to be escaped
			TESC8		Transmitter expects 8th bit to be escaped

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

	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.

	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.  A ZCBIN from the sender overrides any other Conversion
		Option given to the receiver except ZCRESUM.  A ZCBIN from the
		receiver overrides any other Conversion Option sent by the sender.


		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. (filtering
			     RUBOUT NULL Ctrl-Z etc)

			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
			     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.

		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
				the destination file is absent.

				ZMNEW Transfer file if destination file absent.  Otherwise,
				transfer file overwriting destination if the source file
				is newer.

		ZF2: TRANSPORT OPTION
		---------------------

			If the receiver does not implement the particular transport
			option, the file is copied without conversion for later
			processing. better not to use these; see readme

			ZTLZW Lempel-Ziv compression.  Transmitted data will be
			identical to that produced by compress 4.0 operating on
			a computer with VAX byte ordering, using 12 bit
			encoding.

			ZTCRYPT Encryption.  An initial null terminated string
			identifies the key.  Details to be determined.

			ZTRLE Run Length encoding, Details to be determined.

			A ZCRCW data subpacket follows with file name, file length,
			modification date, and other information described in a later
			chapter.

		ZF3: EXTENDED OPTIONS
		---------------------

			The Extended Options are bit encoded.

			ZTSPARS Special processing for sparse files, or sender managed
			selective retransmission. Each file segment is transmitted as
			a separate frame, where the frames are not necessarily
			contiguous.  The sender should end each segment with a ZCRCW
			data subpacket and process the expected ZACK to insure no data
			is lost.  ZTSPARS cannot be used with ZCNL.

	ZSKIP
	-----

		Sent by the receiver in response to ZFILE, makes the sender skip to
		the next file.

	ZNAK
	----

		Indicates last header was garbled.  (See also ZRPOS).

	ZABORT
	------

		Sent by receiver to terminate batch file transfers when requested by
		the user.  Sender responds with a ZFIN sequence. (or ZCOMPL in case of
		server mode).

	ZFIN
	----

		Sent by sending program to terminate a zmodem session. Receiver
		responds with its own ZFIN.

	ZRPOS
	-----

		Sent by receiver to force file transfer to resume at file offset
		given in ZP0...ZP3.

	ZDATA
	-----

		ZP0...ZP3 contain file offset. One or more data subpackets follow.

	ZEOF
	----

		Sender reports End of File.  ZP0...ZP3 contain the ending file
		offset.

	ZFERR
	-----

		Error in reading or writing file, protocol equivalent to ZABORT.

	ZCRC
	----

		Request (receiver) and response (sender) for file polynomial.
		ZP0...ZP3 contain file polynomial.

	ZCHALLENGE
	----------

		Request sender to echo a random number in ZP0...ZP3 in a ZACK frame.
		Sent by the receiving program to the sending program to verify that
		it is connected to an operating program, and was not activated by
		spurious data or a Trojan Horse message. this is the most simply 
		defeated security system ever invented. don't rely on it and better
		still don't use or implement it. build your security measures around
		starting the download at all and disallow explicit path names.

	ZCOMPL
	------

		Request now completed.

	ZCAN
	----

		This is a pseudo frame type in response to a
		Session Abort sequence.

	ZFREECNT
	--------

		Sending program requests a ZACK frame with ZP0...ZP3 containing the
		number of free bytes on the current file system.  A value of 0
		represents an indefinite amount of free space.

	ZCOMMAND
	--------

		ZCOMMAND is sent in a binary frame.  ZF0 contains 0 or ZCACK1 (see
		below).

		A ZCRCW data subpacket follows, with the ASCII text command string
		terminated with a NULL character.  If the command is intended to be
		executed by the operating system hosting the receiving program
		(e.g., "shell escape"), it must have "!" as the first character.
		Otherwise the command is meant to be executed by the application
		program which receives the command.

		If the receiver detects an illegal or badly formed command, the
		receiver immediately responds with a ZCOMPL header with an error
		code in ZP0...ZP3.