zmodem.doc

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

zmodem.doc !copyrighted by MCS 1994 use it anyway you like but don't complain
this file should be accompanied by a readme which contains some background
information on implementing zmodem.

GENERAL
-------

	Documentation about the zmodem protocol internals; should be sufficient
	to implement a completely functional zmodem protocol suite.
	
	Zmodem is a file transfer protocol that attempts to maximize bandwidth
	and minimize transfer times. it is a unidirectional protocol; i.e. the
	return channel only transfers control information; no data. either side
	may initiate the transfer; but the downloading site may respond to 
	an initialization frame by auto starting the download software.
	
	Schematically a zmodem file transfer in progress looks like this:

             |----------<< back channel <<-------------|
       ------+-------                          --------+------
       |   Sender   |                          |   Receiver  |
       |  (upload)  |                          |  (download) |
       --------------                          --------+------
             |---------->> data channel >>-------------|

	Multiple files may be transferred in one session.

SAMPLE
------

	all zmodem transactions are done using frames. a frame consists
	of a header followed by one or more data subpackets.
	a typical (simple) zmodem file transfer looks like this :

	    sender                      receiver

		ZRQINIT(0)
							        ZRINIT
		ZFILE
							        ZRPOS
		ZDATA data ...
		ZEOF
							        ZRINIT
		ZFIN
							        ZFIN
		OO

	zmodem continuously	transmits data unless the receiver interrupts
	the sender to request retransmission of garbled data.
	zmodem in effect uses the entire file as a window.

REQUIREMENTS
------------

	zmodem requires an 8 bit transfer medium; but allows encoded packets
	for less transparent media.
	zmodem escapes network control characters to allow operation with
	packet switched networks.

	To support full streaming, the transmission path should either assert
	flow control or pass full speed transmission without loss of data.
	Otherwise the zmodem sender must manage the window size.

	zmodem places no constraints on the content files.

LINK ESCAPE ENCODING
--------------------

	zmodem achieves data transparency by extending the 8 bit character set
	(256 codes) with escape sequences based on the zmodem data link escape
	character ZDLE

	Link Escape coding permits variable length data subpackets without the
	overhead of a separate byte count.  It allows the beginning of frames to
	be detected without special timing techniques, facilitating rapid error
	recovery.

	Link Escape coding does add some overhead.  The worst case, a file
	consisting entirely of escaped characters, would incur a 50% overhead.

	The ZDLE character is special. ZDLE represents a control
	sequence of some sort. If a ZDLE character appears in binary data,
	it is prefixed with ZDLE, then sent as ZDLEE

	5 consecutive CAN characters abort a zmodem session

	Since CAN is not used in normal terminal operations, interactive
	applications and communications programs can monitor the data flow for
	ZDLE.  The following characters can be scanned to detect the ZRQINIT
	header, the invitation to automatically download commands or files.

	Receipt of five successive CAN characters will abort a zmodem session.
	Eight CAN characters are sent (just to be on the safe side)

	The receiving program decodes any sequence of ZDLE followed by a byte with
	bit 6 set and bit 5 reset (upper case letter, either parity) to the
	equivalent control character by inverting bit 6.  This allows the
	transmitter to escape any control character that cannot be sent by the
	communications medium. In addition, the receiver recognizes escapes for
	0x7f and 0xff should these characters need to be escaped.

	zmodem software escapes ZDLE (0x18), 0x10, 0x90, 0x11, 0x91, 0x13,
	and 0x93. 
	If preceded by 0x40 or 0xc0 (@), 0x0d and 0x8d are also escaped to
	protect the Telenet command escape CR-@-CR. The receiver ignores
	0x11, 0x91, 0x13, and 0x93 characters in the data stream.

HEADERS
-------

	All zmodem frames begin with a header which may be sent in binary or HEX
	form. Either form of the header contains the same raw information:

	- A type byte

	- Four bytes of data indicating flags and/or numeric quantities depending
	  on the frame type

	the maximum header information length is 16 bytes
	the data subpackets following the header are maximum 1024 bytes long.

             M         L
      FTYPE  F3 F2 F1 F0   (flags frame)

             L         M
      FTYPE  P0 P1 P2 P3   (numeric frame)

    Beware of the catch; flags and numbers are indexed the other way around !

	16 BIT CRC BINARY HEADER
	------------------------
	
		A binary header is sent by the sending program to the receiving
		program. All bytes in a binary header are ZDLE encoded.
	
		A binary header begins with the sequence ZPAD, ZDLE, ZBIN.
	
		0 or more binary data subpackets with 16 bit CRC will follow depending
		on the frame type.
	
		* ZDLE A TYPE F3/P0 F2/P1 F1/P2 F0/P3 CRC-1 CRC-2
	
	
	32 BIT CRC BINARY HEADER
	------------------------
	
		A "32 bit CRC" Binary header is similar to a Binary Header, except the
		ZBIN (A) character is replaced by a ZBIN32 (C) character, and four
		characters of CRC are sent.
	
		0 or more binary data subpackets with 32 bit CRC will follow depending
		on the frame type.
	
		* ZDLE C TYPE F3/P0 F2/P1 F1/P2 F0/P3 CRC-1 CRC-2 CRC-3 CRC-4
	
	HEX HEADER
	----------
	
		The receiver sends responses in hex headers.  The sender also uses hex
		headers when they are not followed by binary data subpackets.
	
		Hex encoding protects the reverse channel from random control 
		characters. The hex header receiving routine ignores parity.
	
		use of hex headers by the receiving program allows control characters
		to be used to interrupt the sender when errors are detected.
		A HEX header may be used in place of a binary header
		wherever convenient.
		If a data packet follows a HEX header, it is protected with CRC-16.
	
		A hex header begins with the sequence ZPAD, ZPAD, ZDLE, ZHEX.  
		The extra ZPAD character allows the sending program to detect
		an asynchronous header (indicating an error condition) and then
		get the rest of the header with a non-error specific routine.
	
		The type byte, the four position/flag bytes, and the 16 bit CRC
		thereof are sent in hex using the character set 01234567890abcdef.
		Upper case hex digits are not allowed.
		Since this form of hex encoding detects many patterns of errors,
		especially missing characters, a hex header with 32 bit CRC has not
		been defined.
	
		A carriage return and line feed are sent with HEX headers.  The
		receive routine expects to see at least one of these characters, two
		if the first is CR.
	
		An XON character is appended to all HEX packets except ZACK and ZFIN.
		The XON releases the sender from spurious XOFF flow control characters
		generated by line noise. XON is not sent after ZACK headers to protect
		flow control in streaming situations. XON is not sent after a ZFIN
		header to allow proper session cleanup.
	
		0 or more data subpackets will follow depending on the frame type.
	
		* * ZDLE B TYPE F3/P0 F2/P1 F1/P2 F0/P3 CRC-1 CRC-2 CR LF XON
	
		(TYPE, F3...F0, CRC-1, and CRC-2 are each sent as two hex digits.)
	
	BINARY DATA SUBPACKETS
	----------------------
	
		Binary data subpackets immediately follow the associated binary header
		packet.  A binary data packet contains 0 to 1024 bytes of data.
		Recommended length values are 256 bytes below 2400 bps, 512 at 
		2400 bps, and 1024 above 4800 bps or when the data link is known to
		be relatively error free.
	
		No padding is used with binary data subpackets.  The data bytes are
		ZDLE encoded and transmitted.  A ZDLE and frameend are then sent,
		followed by two or four ZDLE encoded CRC bytes.  The CRC accumulates
		the data bytes and frameend.
	
PROTOCOL TRANSACTION OVERVIEW
-----------------------------	

	zmodem timing is receiver driven.  The
	transmitter should not time out at all, except to abort the program if no
	headers are received for an extended period of time, say one minute.
	
	SESSION STARTUP
	---------------

		To start a zmodem file transfer session, the sending program is called
		with the names of the desired file(s) and option(s).
	
		Then the sender may send a ZRQINIT header. The ZRQINIT header causes a
		previously started receive program to send its ZRINIT header without
		delay.
	
		In an interactive or conversational mode, the receiving application
		may monitor the data stream for ZDLE.  The following characters may be 
		scanned for B00 indicating a ZRQINIT header, a command to download
		data.
	
		The sending program awaits a command from the receiving program to
		start file transfers. 
	
		In case of garbled data, the sending program can repeat the invitation
		to receive a number of times until a session starts.
	
		When the zmodem receive program starts, it immediately sends a ZRINIT
		header to initiate zmodem file transfers, or a ZCHALLENGE header to
		verify the sending program.  The receive program resends its header at
		response time (default 10 second) intervals for a suitable period of
		time (40 seconds total) before exitting.
	
		If the receiving program receives a ZRQINIT header, it resends the
		ZRINIT header.  If the sending program receives the ZCHALLENGE header,
		it places the data in ZP0...ZP3 in an answering ZACK header.
	
		If the receiving program receives a ZRINIT header, it is an echo
		indicating that the sending program is not operational.
	
		Eventually the sending program correctly receives the ZRINIT header.
	
		The sender may then send an optional ZSINIT frame to define the
		receiving program's Attn sequence, or to specify complete control
		character escaping. if the receiver specifies the same or higher
		level of escaping the ZSINIT frame need not be sent unless an Attn
		sequence is needed.
	
		If the ZSINIT header specifies ESCCTL or ESC8, a HEX header is used,
		and the receiver activates the specified ESC modes before reading the
		following data subpacket.
	
		The receiver sends a ZACK header in response, containing 0.
	
	FILE TRANSMISSION
	-----------------

		The sender then sends a ZFILE header with zmodem Conversion,
		Management, and Transport options (see ZFILE header type) followed
		by a ZCRCW data subpacket containing the file name, file length and
		modification date.

		The receiver examines the file name, length, and date information
		provided by the sender in the context of the specified transfer
		options, the current state of its file system(s), and local security
		requirements.  The receiving program should insure the pathname and
		options are compatible with its operating environment and local
		security requirements.

		The receiver may respond with a ZSKIP header, which makes the sender
		proceed to the next file (if any) in the batch.

			The receiver has a file with the same name and length, may
			respond with a ZCRC header with a byte count, which
			requires the sender to perform a 32 bit CRC on the
			specified number of bytes in the file and transmit the
			complement of the CRC in an answering ZCRC header.the crc is
			initialised to 0xfffffff; a byte count of 0 implies the entire
			file the receiver uses this information to determine whether to
			accept the file or skip it.  This sequence may be triggered
			by the ZMCRC Management Option.

		A ZRPOS header from the receiver initiates transmission of the file
		data starting at the offset in the file specified in the ZRPOS header.
		Normally the receiver specifies the data transfer to begin begin at
		offset 0 in the file.

			The receiver may start the transfer further down in the
			file.  This allows a file transfer interrupted by a loss
			of carrier or system crash to be completed on the next
			connection without requiring the entire file to be
			retransmitted. If downloading a file from a timesharing
			system that becomes sluggish, the transfer can be
			interrupted and resumed later with no loss of data.

		The sender sends a ZDATA binary header (with file position) followed
		by one or more data subpackets.
	
		The receiver compares the file position in the ZDATA header with the
		number of characters successfully received to the file. If they do not
		agree, a ZRPOS error response is generated to force the sender to the
		right position within the file. (if the ZMSPARS option is used the
		receiver instead seeks to the position given in the ZDATA header)

		A data subpacket terminated by ZCRCG and CRC does not elicit a
		response unless an error is detected; more data subpacket(s) follow
		immediately.

		ZCRCQ data subpackets expect a ZACK response with the
		receiver's file offset if no error, otherwise a ZRPOS
		response with the last good file offset.  Another data
		subpacket continues immediately.  ZCRCQ subpackets are
		not used if the receiver does not indicate full duplex ability
		with the CANFDX bit.

		ZCRCW data subpackets expect a response before the next frame is sent.
		If the receiver does not indicate overlapped I/O capability with the
		CANOVIO bit, or sets a buffer size, the sender uses the ZCRCW to allow
		the receiver to write its buffer before sending more data.