TELECOMPUTING TODAY
Arian R. Levitan
Inside XMODEM
Last month we covered the basics of uploading and downloading and how the XMODEM protocol developed into a system for reliably transferring files over phone lines. Now let's take a look inside XMODEM to see how it works.
XMODEM requires certain communications settings (eight data bits, no parity, one stop bit). Some terminal programs set these parameters automatically during XMODEM transfers. Others require you to set them manually.
XMODEM transfers files by sending and receiving them in blocks. Each block consists of five elements: a special character that marks the beginning of the block (called a start of header character); a number which identifies the sequence number of the block (incremented by one for each block sent); a number which insures the block number is correct; a 128-byte chunk of the file being transferred (the file is chopped up on the sending end and reassembled on the receiving end); and a number to verify that the 128-byte chunk of data received is the same as was sent. This number is called a checksum. It is the sum of the hexadecimal values of all 128 characters.
Downloading
After notifying the remote system that you want to download a certain file with XMODEM, the other system prepares the file for transmission and then waits for your signal that things are ready to begin. When you instruct your terminal program to begin the transfer, it sends an acknowledgment signal consisting of a single character called an ACK. The first ACK means "ready for next block."
The remote system then sends a block to your computer. Your terminal software looks for the start of header character, then checks the block number for both validity and proper sequence. Next it examines the 128 bytes of data and calculates a checksum. It compares this to the checksum actually sent by the remote system; if both are the same, it assumes the data was transmitted without errors.
As each block is successfully received, another ACK is sent. If an error is detected or the next block is not transmitted after a certain amount of time, your terminal program sends a character referred to as a NAK (negative acknowledgment). A NAK means, "I think we had a problem with the last block; please resend it." The transfer is aborted if a single block must be resent more than an agreed-upon number of times (usually ten). When the transfer is complete, the remote system sends a signal called EOT (end of transmission).
Nonstandard Protocols
Although the original standards for XMODEM file transfers are well established, not all terminal programs that advertise XMODEM capability actually conform to the standard. Here is an example of what can happen (the names have been changed to protect the innocent):
The Bitblaster computer has been available for about a year. Some kindly soul, intent upon putting far-flung Bitblaster owners in touch with each other, writes a bulletin board program for the new machine. Since he wants to encourage people to share programs for the Bitblaster, he includes an XMODEM feature. His friend writes a public domain terminal program with XMODEM capability and starts passing it around.
What they don't know is that their implementation of XMODEM was not strictly by the book. But since the terminal program and BBS work fine together, no one notices. The number of Bitblaster BBS systems rapidly multiplies, and there are thousands of copies of the free terminal program in use.
However, when Bitblaster owners start using the terminal program on other systems, they discover—much to their chagrin—that the good ol' XMODEM feature doesn't work too well on non-Bitblaster BBSs. When something like this happens, it can take years for everyone to agree on a common fix for the problem. Even commercial telecomputing packages are written by normal people, perfectly capable of making such mistakes.
Other Problems
Commercial information services are not well suited to XMODEM transfers. The protocol was developed for microcomputer-based BBSs which handle only one user at a time and can therefore devote all of their attention to the transfer. On a commercial service, hundreds of users may be logged on simultaneously, and the mainframe computer gives each user only a certain amount of attention for a certain time period.
The only way to make XMODEM work on the information services was to relax the timing standards. However, this severely limits the ability to recover from bad blocks and out-of-sync acknowledgment signals.
Although errors are relatively rare, many terminal programs and information services offer their own transfer methods in addition to (or instead of) XMODEM. There's only one hitch—often this means both computers involved in the transfer must be running the same terminal program, or in the case of information services, a terminal program written and sold by the service for your particular system.
Next month, as promised earlier, I'll show you how to save money when sending E-mail by composing your messages offline and then uploading them to the host computer. Until then, BCNU.