|
Even the best telephone connection sneaks errors into modem communications. When sending text back and forth, the result is only a few garbled characters. But if you try to send a complex web page or an executable program through a modem connection and an error creeps in, the result is unpredictable.
Packet-based communications systems take care of such problems by including error detection data in every packet. If a communication problem causes an error anywhere in the system-including between your modem and PC-the bad packet can be detected, and your system can ask for its retransmission. The TCP/IP protocol used by the Internet assures that the pages of the World Wide Web arrive at your PC error free.
Although the Web has become the most popular and important application for modems, it certainly is not the only one. At least for now, various online services and bulletin boards persist in using direct dial connections. These don't benefit from TCP/IP or other packet protocols. If errors are to be exorcised, the two ends of the standalone connection must negotiate it themselves.
They have two choices: hardware-based error correction such as MNP5, and v.42 or software protocols. Before the world agreed on standards for error correction in modem connections, a number of different methods called file transfer protocols were developed to help prevent errors when exchanging files. Many of these are still used in direct dial (as opposed to network-based (Internet) connections.
Xmodem. The first of these protocols was created in 1978 by Ward Christensen and quickly became the de facto standard for error free file transmission. Called Xmodem or MODEM7, Christensen's technique worked by breaking files into blocks 128 bytes long, transmitting the blocks one at a time, and verifying the accuracy of each. If the receiving system found an error, it requested that the bad block be retransmitted as many times as necessary to get through error free (or until the process automatically times out).
To detect errors, Xmodem uses a checksum byte added to each block which, through application of an algorithm, indicates whether the transmission was successful. When a block is successfully received, the receiving system sends back an ACK byte (ASCII code TK); if unsuccessful, it sends back a NAK (ASCII TK) byte.
Xmodem CRC. Some errors in a block can result in a valid checksum. A more robust form of Xmodem substitutes a Cyclical Redundancy Check for the checksum (stealing another byte). Most systems that use Xmodem try to use the CRC algorithm first (because it is more reliable), but if one of the systems trying to communicate doesn't support CRC, the protocol reverts to ordinary Xmodem.
Xmodem-1K. Another way to avoid the substantial overhead of acknowledging multiple blocks is to use larger blocks. The Xmodem-1K protocol expands the 128-byte block of Xmodem CRC to 1024 bytes. The larger blocks give this protocol a substantial advantage over its predecessor in moving larger files.
WXmodem. One problem with Xmodem is that the sending modem must wait for an acknowledgment between sending blocks. With long delays, this wait can substantially slow transmissions. The WXmodem protocol (which stands for Windowed Xmodem) removes the wait. As with ordinary Xmodem, it uses checksummed 128-byte blocks, but the sending system assumes that every block is properly received and sends all blocks one after another. The receiving modem responds normally with ACK or NAK acknowledgments. Although the sending modem often gets one to four blocks ahead of the receiving modem, it tracks the acknowledgments it receives and can resend the proper block when necessary.
Ymodem. As with Xmodem-1K, Ymodem takes advantage of larger blocks to speed transmissions. It uses 1024-byte blocks and cyclic redundancy checking for error detection. Although sometimes confused with Xmodem-1K, it differs by including a batch mode that allows multiple files to be transferred with a single command. Sometimes it is described as Ymodem Batch.
Ymodem-g. After modems with built-in hardware error correction became available, a new variant of the Ymodem protocol without software error recovery was developed as Ymodem-g. Although Ymodem-g still breaks files into 1024-byte blocks for transfer, it sends them as a continuous stream. If an error sneaks past the hardware error detection scheme and is reported back to the sending system, the entire transfer is canceled. It also supports batch transfers.
Zmodem. The principle behind Zmodem is that the only blocks that matter in error correction are those that are received defectively. As with WXmodem and Ymodem-g, Zmodem blasts out blocks non-stop, and it only acts on the NAKs it gets from the receiving system. Zmodem compromises on block size, using 512-byte blocks. The protocol also has recovery capabilities. If a protocol transfer is interrupted, the system can resume it later without the need to retransmit the blocks already sent.
Kermit. Developed at Columbia University in 1981, Kermit-named after Jim Henson's favorite frog-was designed to ship files between dissimilar computer systems. Unlike Xmodem, however, the way Kermit moves data is negotiable. Kermit uses blocks (which the protocol calls packets) and checksum error detection but adjusts its packet size to accommodate the fixed packet sizes used by some computer systems or to work with marginal connections. It also can use seven-bit connections to transfer eight-bit data by specially coding characters when necessary. Kermit can also recover from major line errors by resynchronizing the transmissions of modems after their interruption.
|
Disclaimer
