This is a brief description of several common file transfer protocols. The methods available to you when using ClarisWorks can vary. Currently, the Macintosh Communication Toolbox (which is used by ClarisWorks) ships with tools supporting the XMODEM and ASCII Text protocols only. ClarisWorks 2.x includes the Claris Kermit Tool as well. Tools for other protocols (such as Kermit, YMODEM and ZMODEM) can be attained from online services and distributors.
Mark/Space Softworks sells a ZMODEM tool for $29.95. They can be contacted at (800) 799-4737.
XMODEM/XMODEM-CRC - The BBS supports two variations of the XMODEM protocol, originally developed by Ward Christensen, called XMODEM and 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. If an error is detected in the transmission, XMODEM will request that WILDCAT! retransmit the block of data. 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 block checks being made.
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) of up to 99 files with WILDCAT!.
NOTE: 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 as used by WILDCAT!. Use of YMODEM, if supported by a callers software, is recommended over XMODEM and 1K-XMODEM for speed, reliability, and features.
YMODEM/G - This variation of YMODEM is available only to callers making a "reliable" connection using a modem supporting MNP (Microcom Networking Protocol) or the USRobotics ARQ hardware error checking or the most recently introduced correction method, V.42/V.42bis. If a MNP connection is detected, WILDCAT! will add this protocol choice (as well as 1K-XMODEM/G) to the available options.
MNP is a hardware based system in which the modems perform the actual error checking and correction, if needed. The software such as WILDCAT! and Qmodem simply send the information blindly from one system to the other using the protocol for block sorting information only. For this reason, these two protocol choices ONLY appear 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 on the BBS. Connections using two USRobotics HST modems, with ports locked at 19200 or 38400 at both ends, results in throughput in excess of 1725 characters per second! YMODEM/G also supports multiple file transfer (both down and up) of up to 99 files at on time.
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 slightly slower than YMODEM/G or 1K-XMODEM/G). ZMODEM also supports multiple file transfer capability, 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 normally recommended for PC to PC transfers. Kermit transfer speed can be dramatically increased by tuning its optional parameters
ASCII - 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.