zmodem.doc

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

     the destination file is absent.

ZMNEW Transfer file if destination file	absent.	 Otherwise,
     transfer file overwriting destination if the source file
     is	newer.

11.5.3	ZF2: Transport Option
If the receiver	does not implement the particular transport
option,	the file is copied without conversion for later
processing.

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.



Chapter	11		Rev 8-3-87  Typeset 8-4-87			27







Chapter	11		     ZMODEM Protocol				28



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.

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

11.6  ZSKIP

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

11.7  ZNAK

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

11.8  ZABORT

Sent by	receiver to terminate batch file transfers when	requested by
the user.  Sender responds with	a ZFIN sequence.[2]

11.9  ZFIN

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

11.10  ZRPOS

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








__________

 2. Or ZCOMPL in case of server	mode.




Chapter	11		Rev 8-3-87  Typeset 8-4-87			28







Chapter	11		     ZMODEM Protocol				29



11.11  ZDATA

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

11.12  ZEOF

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

11.13  ZFERR

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

11.14  ZCRC

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

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

11.16  ZCOMPL

Request	now completed.

11.17  ZCAN

This is	a pseudo frame type returned by	gethdr() in response to	a
Session	Abort sequence.

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

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



Chapter	11		Rev 8-3-87  Typeset 8-4-87			29







Chapter	11		     ZMODEM Protocol				30



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.

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.



12.  SESSION TRANSACTION EXAMPLES

12.1  A	simple file transfer

A simple transaction, one file,	no errors, no CHALLENGE, overlapped
I/O:

Sender	       Receiver

"rz\r"
ZRQINIT(0)
	       ZRINIT
ZFILE
	       ZRPOS
ZDATA data ...
ZEOF
	       ZRINIT
ZFIN
	       ZFIN
OO








Chapter	12		Rev 8-3-87  Typeset 8-4-87			30







Chapter	12		     ZMODEM Protocol				31



12.2  Challenge	and Command Download


Sender		    Receiver

"rz\r"
ZRQINIT(ZCOMMAND)
		    ZCHALLENGE(random-number)
ZACK(same-number)
		    ZRINIT
ZCOMMAND, ZDATA
		    (Performs Command)
		    ZCOMPL
ZFIN
		    ZFIN
OO


13.  ZFILE FRAME FILE INFORMATION

ZMODEM sends the same file information with the	ZFILE frame data
that YMODEM Batch sends	in its block 0.

N.B.: The pathname (file name) field is	mandatory.

Pathname The pathname (conventionally, the file	name) is sent as a
     null terminated ASCII string.  This is the	filename format	used
     by	the handle oriented MSDOS(TM) functions	and C library fopen
     functions.	 An assembly language example follows:
			   DB	  'foo.bar',0
     No	spaces are included in the pathname.  Normally only the	file
     name stem (no directory prefix) is	transmitted unless the
     sender has	selected YAM's f option	to send	the full absolute or
     relative pathname.	 The source drive designator (A:, B:, etc.)
     usually is	not sent.

			 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



Chapter	13		Rev 8-3-87  Typeset 8-4-87			31







Chapter	13		     ZMODEM Protocol				32



	  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 file	length and each	of the succeeding fields are
     optional.[1] 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 A single space separates the modification date
     from the file length.

     The mod date is optional, and the filename	and length may be
     sent without requiring the	mod date to be sent.

     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 A single space separates the file mode from the
     modification date.	 The file mode is stored as an octal string.
     Unless the	file originated	from a Unix system, the	file mode is
     set to 0.	rz(1) checks the file mode for the 0x8000 bit which
     indicates a Unix type regular file.  Files	with the 0x8000	bit
     set are assumed to	have been sent from another Unix (or
     similar) system which uses	the same file conventions.  Such
     files are not translated in any way.


Serial Number A	single space separates the serial number from the
     file mode.	 The serial number of the transmitting program is
     stored as an octal	string.	 Programs which	do not have a serial


__________

 1. Fields may not be skipped.




Chapter	13		Rev 8-3-87  Typeset 8-4-87			32







Chapter	13		     ZMODEM Protocol				33



     number should omit	this field, or set it to 0.  The receiver's
     use of this field is optional.

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.


14.  PERFORMANCE RESULTS

14.1  Compatibility

Extensive testing has demonstrated ZMODEM to be	compatible with
satellite links, packet	switched networks, microcomputers,
minicomputers, regular and error correcting buffered modems at 75 to
19200 bps.  ZMODEM's economy of	reverse	channel	bandwidth allows
modems that dynamically	partition bandwidth between the	two
directions to operate at optimal speeds.

14.2  Throughput

Between	two single task	PC-XT computers	sending	a program image	on
an in house Telenet link, SuperKermit provided 72 ch/sec throughput
at 1200	baud.  YMODEM-k	yielded	85 chars/sec, and ZMODEM provided
113 chars/sec.	XMODEM was not measured, but would have	been much
slower based on	observed network propagation delays.

Recent tests downloading large binary files to an IBM PC (4.7 mHz
V20) running YAMK 16.30	with table driven 32 bit CRC calculation
yielded	a throughput of	1870 cps on a 19200 bps	direct connection.

Tests with TELEBIT TrailBlazer modems have shown transfer rates
approaching 1400 characters per	second for long	files.	When files
are compressed,	effective transfer rates of 2000 characters per
second are possible.


14.3  Error Recovery

Some tests of ZMODEM protocol error recovery performance have been
made.  A PC-AT with SCO	SYS V Xenix or DOS 3.1 was connected to	a PC
with DOS 2.1 either directly at	9600 bps or with unbuffered dial-up
1200 bps modems.  The ZMODEM software was configured to	use 1024
byte data subpacket lengths above 2400 bps, 256	otherwise.

Because	no time	delays are necessary in	normal file transfers, per
file negotiations are much faster than with YMODEM, the	only
observed delay being the time required by the program(s) to update
logging	files.




Chapter	14		Rev 8-3-87  Typeset 8-4-87			33







Chapter	14		     ZMODEM Protocol				34



During a file transfer,	a short	line hit seen by the receiver
usually	induces	a CRC error.  The interrupt sequence is	usually	seen
by the sender before the next data subpacket is	completely sent, and
the resultant loss of data throughput averages about half a data
subpacket per line hit.	 At 1200 bps this is would be about .75
second lost per	hit.  At 10-5 error rate, this would degrade
throughput by about 9 per cent.

The throughput degradation increases with increasing channel delay,
as more	data subpackets	in transit through