旼컴컴컴컴컴컴컴컴컴컴컴컴컴� � Protocol Information � 읕컴컴컴컴컴컴컴컴컴컴컴컴컴� XMODEM FILE TRANSFER XMODEM/CRC respectively. XMODEM offers the advantage of error checking on a block by block basis to assure that the data sent contains no errors. It does this by adding a checksum byte to the end of each 128 byte block of data; the receiver calculates its own checksum and compares it to the one received. In addition to the above checksum comparison, XMODEM/CRC adds another level of error detection using a complex CYCLICAL REDUNDANCY CHECK algorithm. XMODEM and XMODEM/CRC are slow transfer protocols when compared to many others available. They should only be used when your software supports no other protocol. XMODEM/CRC is preferable to XMODEM due to its greatly improved error checking. 1K-XMODEM This protocol performs exactly like regular XMODEM/CRC, but increases the block size to 1024 bytes, hence the name 1K. It is slightly faster (on fairly clean phone lines) than regular XMODEM due to a smaller number of blocks being sent, and therefore fewer YMODEM YMODEM is a protocol devised by Chuck Forsberg of Omen Technology which adds a number of enhancements to protocol based transfer. Block sizes are variable at 128/1024, but 1K is the usual size. Error checking makes use of CRC-16, accurate to 99.99%. By definition, all YMODEM transfers are capable of sending multiple files at one request, with the file size and date included in the "header block" sent prior to each file. YMODEM supports multiple file transfer (both down AND up). CAUTION: A number of communication programs incorrectly use the term YMODEM but actually send using 1K-XMODEM. This practice is not proper and will result in a failure when used with a true YMODEM transfer. Use of YMODEM, if supported by a caller's software, is recommended over XMODEM and 1K-XMODEM for speed, reliability, and features. This variation of YMODEM is available only to callers making a "reliable" connection using a modem supporting MNP (Microcom Networking Protocol) or the U.S. Robotics ARQ hardware error checking. MNP is a hardware based system in which the modems perform the actual error checking and correction when needed. For this reason, these two protocol choices ONLY, if a MNP connection is detected at logon. YMODEM/G is among the fastest protocols with the exception of the newer versions of ZMODEM discussed below. If you have a modem that supports MNP or ARQ, YMODEM/G should be your usual choice. Connections using two U.S. Robotics HST modems, with ports locked at 19200 or 38400 at both ends, results in throughput in excess of 1400 characters per second (equivalent of almost 1,400 baud)! YMODEM/G also supports multiple file transfer (both down AND up) of up to 50 files. 1K-XMODEM/G This version of 1K-XMODEM makes use of MNP hardware error correction to do away with the block-by-block checking in the normal version. The result is a very fast single file transfer protocol for use if YMODEM/G is not readily available. ZMODEM This is another protocol developed by Chuck Forsberg. It is a "streaming protocol", one which sends variable sized blocks of data with CRC-32 error checking for an accuracy of 99.9999%, but does not wait for an acknowledgment from the receiving computer. The sending system assumes data received is OK unless a repeat request is sent for a specific block. This streaming activity tends to make ZMODEM one of the fastest protocols available (but very slightly slower than Ymodem/G or 1K-Xmodem/G). ZMODEM also supports multiple file transfer capability (limited to 7 download files). This is an external protocol), and should be considered in situations where MNP is not available, or another batch transfer protocol cannot be used. Zmodem also has the unique capability to resume file transfers that have been aborted for some reason and thus only partially completed. This is called crash recovery. KERMIT This protocol's main claim is not speed, but rather its ability to interact with many types of computers from mainframes to micros. It can cope with systems limited to seven-bit characters even when the data to be transmitted is in eight-bit form. All characters to be sent are translated into standard printable characters and reconstructed on the receiving end. WHile not terribly efficient, it is sometimes an absolute necessity for data transfer involving different types of systems and terminal types. It is not recommended for PC to PC transfers. ASCII DATA CAPTURE ASCII transfer is simply the sending of information as characters, and is limited to 7 bit information. The transfer of files in ASCII mode can be done if your system is capable of any type of data capture. ASCII transfer is limited, and some sort of error checking protocol is required if you intend to transfer files with extensions of EXE, OBJ, COM, ARC or ZIP, as well as tokenized BASIC programs and files containing the IBM PC special ASCII characters (ones with ASCII values above 128). These files cannot be transferred in ASCII mode since ASCII transfer is only 7 bit and these types of files require the full 8 bit transfer of the data, with no translation of the contents of the file.