178 lines
9.4 KiB
Plaintext
178 lines
9.4 KiB
Plaintext
|
|
|||
|
|
XMODEM File Transfer Protocol
|
|||
|
|
|
|||
|
|
By Larry Jordan
|
|||
|
|
|
|||
|
|
When transferring files between computers using the telephone
|
|||
|
|
system, there is always the chance that electrical noise will
|
|||
|
|
result in data transmission errors. To ensure proper transfer of
|
|||
|
|
files it is necessary to detect data transmission errors and to
|
|||
|
|
retransmit data that contains errors. Most people think that
|
|||
|
|
asynchronous parity error detection provides that capability. It
|
|||
|
|
does not. Parity error detection does tell you when a data
|
|||
|
|
transfer error has occurred, but it is up to you to retransmit
|
|||
|
|
the data to correct errors. The problem is that parity error
|
|||
|
|
detection is not actually performed by most IBM PC communication
|
|||
|
|
packages. If a package does perform the error detection, it may
|
|||
|
|
not inform you of errors in such a way that you know to
|
|||
|
|
immediately retransmit the data. ASCOM, for example, places an
|
|||
|
|
asterisk in a file where parity errors are detected, but you
|
|||
|
|
may not realize the errors occurred until long after the file is
|
|||
|
|
transferred. To ensure "error-free" data transfer you need a
|
|||
|
|
protocol file transfer technique. Andrew Fluegelman has added
|
|||
|
|
such a technique to PC-TALK.III called the XMODEM protocol.
|
|||
|
|
|
|||
|
|
A protocol is a set of rules and conventions that apply to a
|
|||
|
|
specific area of communications that allow participants to
|
|||
|
|
properly communicate regardless of the hardware brand or software
|
|||
|
|
package being used. The protocol file transfer is a set of rules
|
|||
|
|
for transferring files which specifies a set of ASCII handshaking
|
|||
|
|
characters and the sequence of handshaking required to perform
|
|||
|
|
certain file transfer functions. Protocol handshaking signals
|
|||
|
|
allow communication software to transfer text, data and machine
|
|||
|
|
code files, and to perform sophisticated error-checking. The
|
|||
|
|
handicap in using protocol file transfer techniques is that the
|
|||
|
|
computers on both ends of the communications link must be using
|
|||
|
|
compatible software; there is no standard that controls these
|
|||
|
|
protocols and almost all communication packages that have a
|
|||
|
|
protocol file transfer option use a protocol unique to that
|
|||
|
|
package. This means that a business or group of people must
|
|||
|
|
standardize its microcomputer communications software to take
|
|||
|
|
advantage of protocol transfers.
|
|||
|
|
|
|||
|
|
The Ward Christensen XMODEM protocol is one specific file
|
|||
|
|
transfer protocol that may become a default standard in personal
|
|||
|
|
communications because of its widespread use on bulletin
|
|||
|
|
boards and because of its inclusion in low cost personal computer
|
|||
|
|
communication packages such as PC-TALK. It has not gained
|
|||
|
|
widespread acceptance in business communication packages partly
|
|||
|
|
because the protocol is public domain; most business
|
|||
|
|
communication package designers use unique protocols to force
|
|||
|
|
businesses to use their software on both ends of communication
|
|||
|
|
links. By providing you with this insight into protocol transfer
|
|||
|
|
and explaining in detail the operation of the XMODEM protocol, I
|
|||
|
|
hope to add momentum to the development of a "standard protocol"
|
|||
|
|
whether it be the XMODEM model or some other model. Users of
|
|||
|
|
communication software deserve a standard protocol that will
|
|||
|
|
allow them to use the technique with any microcomputer regardles
|
|||
|
|
of the software packages employed.
|
|||
|
|
|
|||
|
|
The XMODEM protocol is illustrated in Figure 1. As you can see
|
|||
|
|
from that figure, XMODEM does not begin the transfer of data
|
|||
|
|
until the receiving computer signals the transmitting computer
|
|||
|
|
that it is ready to receive data. The Negative Acknowledge (NAK)
|
|||
|
|
character is used for this signal and is sent to the transmitting
|
|||
|
|
computer every 10 seconds until the file transfer begins. If the
|
|||
|
|
file transfer does not begin after 9 NAK's are sent, the process
|
|||
|
|
has to be manually restarted.
|
|||
|
|
|
|||
|
|
After a NAK is received, the transmitting computer uses a Start
|
|||
|
|
of Header (SOH) character and two block numbers (a true block
|
|||
|
|
number followed by a 1's complement of the number) to signal the
|
|||
|
|
start of a 128-byte block of data to be transferred then sends
|
|||
|
|
the block followed by an error-checking checksum. The checksum
|
|||
|
|
is calculated by adding the ASCII values of each character in the
|
|||
|
|
128 character block; the sum is then divided by 255 and the
|
|||
|
|
remainder is retained as the checksum. After each block of data
|
|||
|
|
is transferred, the receiving computer computes its own checksum
|
|||
|
|
and compares the result to the checksum received from the
|
|||
|
|
transmitting computer. If the two values are the same, the
|
|||
|
|
receiving computer sends an Acknowledge (ACK) character to tell
|
|||
|
|
the receiver to send the next sequential block. If the two
|
|||
|
|
values are not the same, the receiving computer sends the
|
|||
|
|
transmitter an NAK to request a retransmission of the last block
|
|||
|
|
This retransmission process is repeated until the block of data
|
|||
|
|
is properly received or until 9 attempts have been made to
|
|||
|
|
transmit the block. If the communications link is noisy,
|
|||
|
|
resulting in improper block transmission after 9 attempts, the
|
|||
|
|
file transfer is aborted.
|
|||
|
|
|
|||
|
|
XMODEM uses two block numbers at the start of each block to be
|
|||
|
|
sure the same block is not transmitted twice because of a
|
|||
|
|
handshake character loss during the transfer. The receiving
|
|||
|
|
computer checks the transmitted block to be sure that it is the
|
|||
|
|
one requested and blocks that are retransmitted by mistake are
|
|||
|
|
thrown away. When all data has been successfully transmitted, the
|
|||
|
|
transmitting computer sends the receiver an End of Transmission
|
|||
|
|
(EOT) character to indicate the end of file.
|
|||
|
|
|
|||
|
|
The XMODEM protocol offers the IBM PC several advantages over other
|
|||
|
|
protocols and file transfer methods. First, the protocol is in
|
|||
|
|
the public domain which makes it readily available for software
|
|||
|
|
designers to incorporate into a communications package. Second,
|
|||
|
|
the protocol is easy to implement using high level languages such
|
|||
|
|
as BASIC or Pascal. Third, the protocol only requires a 256-byte
|
|||
|
|
communication receive buffer which makes it attractive for IBM PC
|
|||
|
|
owners who only have 64K systems. Forth, the protocol allows a
|
|||
|
|
user to transfer non-ASCII 8-bit data files (i.e., COM, EXE and
|
|||
|
|
tokenized BASIC) between microcomputers because it calculates the
|
|||
|
|
end of a file based on file size and uses handshake signals to
|
|||
|
|
indicate the end of a file instead relying on an end of file
|
|||
|
|
marker character (control-Z) to terminate a file transfer.
|
|||
|
|
Fifth, XMODEM error-checking is superior to normal asynchronous
|
|||
|
|
parity error checking. The parity method of error-checking is
|
|||
|
|
95% effective if the software on the receiving end checks for
|
|||
|
|
parity errors. XMODEM error-checking is 99.6% effective, and the
|
|||
|
|
software on the receiving end must check for errors. Parity
|
|||
|
|
errors detected also do not result in automatic retransmission of
|
|||
|
|
the bad data; XMODEM detected errors result in data
|
|||
|
|
retransmission until no errors are detected or until 9
|
|||
|
|
retransmissions have been attempted. Finally, the protocol is
|
|||
|
|
used by many CP/M bulletin boards and having the protocol in a
|
|||
|
|
communications package allows the IBM PC user to receive
|
|||
|
|
error-checked files from these bulletin boards.
|
|||
|
|
|
|||
|
|
Andrew Fluegelman has given the XMODEM protocol a real boost in
|
|||
|
|
the IBM PC world by including it in his package. He has also
|
|||
|
|
added significant power to the package by including the protocol
|
|||
|
|
Rumor has it that Don Withrow will soon add to the XMODEM
|
|||
|
|
momentum by adding it to his HOSTCOMM software package. Keep up
|
|||
|
|
the good work guys -- we will get a standard one way or the
|
|||
|
|
other!
|
|||
|
|
|
|||
|
|
[This article was derived from material contained in a book
|
|||
|
|
written by Larry Jordan and Bruce Churchill to be published this
|
|||
|
|
Summer by The Brady Company. The article will also be in the
|
|||
|
|
5th issue of PC World magazine.]
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
XMODEM Protocol File Transfer
|
|||
|
|
|
|||
|
|
|
|||
|
|
Receiving Transmitting
|
|||
|
|
Computer Computer
|
|||
|
|
Ready to Ready to
|
|||
|
|
Receive Transmit
|
|||
|
|
| |
|
|||
|
|
| |
|
|||
|
|
|---------------------\NAK\--------------------->|
|
|||
|
|
| |
|
|||
|
|
|<------/SOH/Blk #1/Blk #1/Good Data/CkSum/------|
|
|||
|
|
| |
|
|||
|
|
|---------------------\ACK\--------------------->|
|
|||
|
|
| |
|
|||
|
|
|<------/SOH/Blk #2/Blk #2/Good Data/CkSum/------|
|
|||
|
|
| |
|
|||
|
|
|---------------------\ACK\--------------------->|
|
|||
|
|
| |
|
|||
|
|
|<------/SOH/Blk #3/Blk #3/Garbled Data/CkSum/---|
|
|||
|
|
| |
|
|||
|
|
|---------------------\NAK\--------------------->|
|
|||
|
|
| |
|
|||
|
|
|<------/SOH/Blk #3/Blk #3/Good Data/CkSum/------|
|
|||
|
|
| |
|
|||
|
|
|---------------------\ACK\--------------------->|
|
|||
|
|
| |
|
|||
|
|
|<--------------------/EOT/----------------------|
|
|||
|
|
| |
|
|||
|
|
|---------------------\ACK\--------------------->|
|
|||
|
|
| |
|
|||
|
|
V V
|
|||
|
|
|
|||
|
|
File File
|
|||
|
|
Receipt Transmit
|
|||
|
|
Ends Ends
|
|||
|
|
|
|||
|
|
Figure 1
|
|||
|
|
|