📄 xymodem.htm
字号:
Figure 11. Message Block Level Protocol, CRC mode
Each block of the transfer in CRC mode looks like:
<soh><blk #=""><255-blk #><--128 data bytes--><crc hi=""><crc lo="">
in which:
<soh> = 01 hex
<blk #=""> = binary number, starts at 01 increments by 1, and
wraps 0FFH to 00H (not to 01)
<255-blk #> = ones complement of blk #.
<crc hi=""> = byte containing the 8 hi order coefficients of the CRC.
<crc lo=""> = byte containing the 8 lo order coefficients of the CRC.
8.1 CRC Calculation
8.1.1 Formal_Definition
To calculate the 16 bit CRC the message bits are considered to be the
coefficients of a polynomial. This message polynomial is first multiplied
by X^16 and then divided by the generator polynomial (X^16 + X^12 + X^5 +
__________
1. This reliability figure is misleading because XMODEM's critical
supervisory functions are not protected by this CRC.
Chapter 8 Xmodem Protocol Overview
X/YMODEM Protocol Reference June 18 1988 25
1) using modulo two arithmetic. The remainder left after the division is
the desired CRC. Since a message block in the Modem Protocol is 128 bytes
or 1024 bits, the message polynomial will be of order X^1023. The hi order
bit of the first byte of the message block is the coefficient of X^1023 in
the message polynomial. The lo order bit of the last byte of the message
block is the coefficient of X^0 in the message polynomial.
Figure 12. Example of CRC Calculation written in C
The following XMODEM crc routine is taken from "rbsb.c". Please refer to
the source code for these programs (contained in RZSZ.ZOO) for usage. A
fast table driven version is also included in this file.
/* update CRC */
unsigned short
updcrc(c, crc)
register c;
register unsigned crc;
{
register count;
for (count=8; --count>=0;) {
if (crc & 0x8000) {
crc <<= 1;
crc += (((c<<=1) & 0400) != 0);
crc ^= 0x1021;
}
else {
crc <<= 1;
crc += (((c<<=1) & 0400) != 0);
}
}
return crc;
}
8.2 CRC File Level Protocol Changes
8.2.1 Common_to_Both_Sender_and_Receiver
The only change to the File Level Protocol for the CRC option is the
initial handshake which is used to determine if both the sending and the
receiving programs support the CRC mode. All Modem Programs should support
the checksum mode for compatibility with older versions. A receiving
program that wishes to receive in CRC mode implements the mode setting
handshake by sending a <c> in place of the initial <nak>. If the sending
program supports CRC mode it will recognize the <c> and will set itself
into CRC mode, and respond by sending the first block as if a <nak> had
been received. If the sending program does not support CRC mode it will
not respond to the <c> at all. After the receiver has sent the <c> it will
wait up to 3 seconds for the <soh> that starts the first block. If it
receives a <soh> within 3 seconds it will assume the sender supports CRC
mode and will proceed with the file exchange in CRC mode. If no <soh> is
Chapter 8 Xmodem Protocol Overview
X/YMODEM Protocol Reference June 18 1988 26
received within 3 seconds the receiver will switch to checksum mode, send
a <nak>, and proceed in checksum mode. If the receiver wishes to use
checksum mode it should send an initial <nak> and the sending program
should respond to the <nak> as defined in the original Modem Protocol.
After the mode has been set by the initial <c> or <nak> the protocol
follows the original Modem Protocol and is identical whether the checksum
or CRC is being used.
8.2.2 Receive_Program_Considerations
There are at least 4 things that can go wrong with the mode setting
handshake.
1. the initial <c> can be garbled or lost.
2. the initial <soh> can be garbled.
3. the initial <c> can be changed to a <nak>.
4. the initial <nak> from a receiver which wants to receive in checksum
can be changed to a <c>.
The first problem can be solved if the receiver sends a second <c> after
it times out the first time. This process can be repeated several times.
It must not be repeated too many times before sending a <nak> and
switching to checksum mode or a sending program without CRC support may
time out and abort. Repeating the <c> will also fix the second problem if
the sending program cooperates by responding as if a <nak> were received
instead of ignoring the extra <c>.
It is possible to fix problems 3 and 4 but probably not worth the trouble
since they will occur very infrequently. They could be fixed by switching
modes in either the sending or the receiving program after a large number
of successive <nak>s. This solution would risk other problems however.
8.2.3 Sending_Program_Considerations
The sending program should start in the checksum mode. This will insure
compatibility with checksum only receiving programs. Anytime a <c> is
received before the first <nak> or <ack> the sending program should set
itself into CRC mode and respond as if a <nak> were received. The sender
should respond to additional <c>s as if they were <nak>s until the first
<ack> is received. This will assist the receiving program in determining
the correct mode when the <soh> is lost or garbled. After the first <ack>
is received the sending program should ignore <c>s.
Chapter 8 Xmodem Protocol Overview
X/YMODEM Protocol Reference June 18 1988 27
8.3 Data Flow Examples with CRC Option
Here is a data flow example for the case where the receiver requests
transmission in the CRC mode but the sender does not support the CRC
option. This example also includes various transmission errors. <xx>
represents the checksum byte.
Figure 13. Data Flow: Receiver has CRC Option, Sender Doesn't
SENDER RECEIVER
<--- <c>
times out after 3 seconds,
<--- <c>
times out after 3 seconds,
<--- <c>
times out after 3 seconds,
<--- <c>
times out after 3 seconds,
<--- <nak>
<soh> 01 FE -data- <xx> --->
<--- <ack>
<soh> 02 FD -data- <xx> ---> (data gets line hit)
<--- <nak>
<soh> 02 FD -data- <xx> --->
<--- <ack>
<soh> 03 FC -data- <xx> --->
(ack gets garbaged) <--- <ack>
times out after 10 seconds,
<--- <nak>
<soh> 03 FC -data- <xx> --->
<--- <ack>
<eot> --->
<--- <ack>
Here is a data flow example for the case where the receiver requests
transmission in the CRC mode and the sender supports the CRC option. This
example also includes various transmission errors. <xxxx> represents the
2 CRC bytes.
Chapter 8 Xmodem Protocol Overview
X/YMODEM Protocol Reference June 18 1988 28
Figure 14. Receiver and Sender Both have CRC Option
SENDER RECEIVER
<--- <c>
<soh> 01 FE -data- <xxxx> --->
<--- <ack>
<soh> 02 FD -data- <xxxx> ---> (data gets line hit)
<--- <nak>
<soh> 02 FD -data- <xxxx> --->
<--- <ack>
<soh> 03 FC -data- <xxxx> --->
(ack gets garbaged) <--- <ack>
times out after 10 seconds,
<--- <nak>
<soh> 03 FC -data- <xxxx> --->
<--- <ack>
<eot> --->
<--- <ack>
Chapter 8 Xmodem Protocol Overview
X/YMODEM Protocol Reference June 18 1988 29
9. MORE INFORMATION
Please contact Omen Technology for troff source files and typeset copies
of this document.
9.1 TeleGodzilla Bulletin Board
More information may be obtained by calling TeleGodzilla at 503-621-3746.
Speed detection is automatic for 1200, 2400 and 19200(Telebit PEP) bps.
TrailBlazer modem users may issue the TeleGodzilla trailblazer command to
swith to 19200 bps once they have logged in.
Interesting files include RZSZ.ZOO (C source code), YZMODEM.ZOO (Official
XMODEM, YMODEM, and ZMODEM protocol descriptions), ZCOMMEXE.ARC,
ZCOMMDOC.ARC, and ZCOMMHLP.ARC (PC-DOS shareware comm program with XMODEM,
True YMODEM(TM), ZMODEM, Kermit Sliding Windows, Telink, MODEM7 Batch,
script language, etc.).
9.2 Unix UUCP Access
UUCP sites can obtain the current version of this file with
uucp omen!/u/caf/public/ymodem.doc /tmp
A continually updated list of available files is stored in
/usr/spool/uucppublic/FILES. When retrieving these files with uucp,
remember that the destination directory on your system must be writeable
by anyone, or the UUCP transfer will fail.
The following L.sys line calls TeleGodzilla (Pro-YAM in host operation).
TeleGodzilla determines the incoming speed automatically.
In response to "Name Please:" uucico gives the Pro-YAM "link" command as a
user name. The password (Giznoid) controls access to the Xenix system
connected to the IBM PC's other serial port. Communications between
Pro-YAM and Xenix use 9600 bps; YAM converts this to the caller's speed.
Finally, the calling uucico logs in as uucp.
omen Any ACU 2400 1-503-621-3746 se:--se: link ord: Giznoid in:--in: uucp
10. REVISIONS
6-18-88 Further revised for clarity. Corrected block numbering in two
examples.
10-27-87 Optional fields added for number of files remaining to be sent
and total number of bytes remaining to be sent.
10-18-87 Flow control discussion added to 1024 byte block descritpion,
minor revisions for clarity per user comments.
Chapter 10 Xmodem Protocol Overview
X/YMODEM Protocol Reference June 18 1988 30
8-03-87 Revised for clarity.
5-31-1987 emphasizes minimum requirements for YMODEM, and updates
information on accessing files.
9-11-1986 clarifies nomenclature and some minor points.
The April 15 1986 edition clarifies some points concerning CRC
calculations and spaces in the header.
11. YMODEM Programs
ZCOMM, A shareware little brother to Professional-YAM, is available as
ZCOMMEXE.ARC on TeleGodzilla and other bulletin board systems. ZCOMM may
be used to test YMODEM amd ZMODEM implementations.
Unix programs supporting YMODEM are available on TeleGodzilla in RZSZ.ZOO.
This ZOO archive includes a ZCOMM/Pro-YAM/PowerCom script ZUPL.T to upload
a bootstrap program MINIRB.C, compile it, and then upload the rest of the
files using the compiled MIN⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -