PROTOCOLS EXPLAINED ********************************************* This is a brief summary of asynchronous protocols commonly used for sending and receiving files with personal computers. Sending files from one computer to another involves some sort of checking to insure that the receiving end gets only what was sent. This usually involves the use of some "protocol" or handshaking. This is a set of rules and signals performed in concert by both ends. Hence both ends must be using the same protocol! -=-=-=-=-=-=-=-=-=-= ASYNCHRONOUS PROTOCOLS =-=-=-=-=-=-=-=-=-=- When transferring files via a PC using a modem and a communications program, it is necessary to select one protocol for use at both ends. Different communications packages support different transfer proto- cols so you will need to check your documentaion to determine which protocols your communications package supports. Following is a brief description of the most commonly used file transfer protocols. ASCII DATA CAPTURE ****************** NOTE: You MAY NOT transfer a binary file (such as a .COM or .EXE file) using this method! You MAY NOT tranfer compressed files such as .ZIP or .ARC files either. ASCII may only be used for small text files where data integrity is not important. ASCII transfer is simply the sending of textual information, and is limited to 7 bit information. This excludes all characters above 127 decimal such as the IBM PC graphics characters. It may be used for small text files over clean telephone lines. If data integrity is required, this method should NOT be used, or if used, the file should be sent twice and received as different filenames so that they can be compared with some utility such as COMP which comes with DOS. The transfer of files in ASCII mode can be done if your system is capable of any type of data capture. Just be aware that data may be dropped or garbage characters may be added from line noise during the transfer. Since no error checking such as a checksum or block length is being done, you are at the mercy of the irregular quality of phone transmission and switching equipment. ASCII is presented here even though it is not truly a "protocol". Even if the XON/XOFF (Control-S - Control-Q) signals are respected by both ends to prevent overruns, and the eighth bit is used for parity checking, the user has some aid, but not really enough. 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 transmittted 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 systmes and terminal types. It is not recom- mended for PC to PC transfers. XMODEM and XMODEM/CRC ********************* Xmodem is a file transfer protocol originally developed by Ward Christensen. There are two basic type of XMODEM protocols, XMODEM and XMODEM/CRC. 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 the sending PC retrans- mit the block of data.In addition to the above checksum comparison, XMODEM/CRC adds another level of error detection using a complex CYCLICAL REDUNANCY CHECK algorithm. XMODEM and XMODEM/CRC are slow protocols compared to many others available but they are quite reliable and available in almost all communications packages. They should only be used when you software supports no other protocol. XMODEM/CRC is preferrable to XMODEM due to its greatly improved error checking. 1K-XMODEM ********* This protocol performs exactly like regular XMODEM/CRC, but it 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. 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. YMODEM ****** YMODEM is a protocol devised by Chuck Forsberg of Omen Technology which adds enhancements to portocol based transfer. He is the author of DSZ and PRO-YAM communications products. These are mature and robust file transfer programs. YMODEM block sizes are variable at 128/1024, but 1K (1024) 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 50 files om a "batch". 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. YMODEM/G ******** This variation of YMODEM is usually only available when callers are using modems 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, if needed. The software simply sends the information blindly from one system to the other using the protocol for block sorting information only. YMODEM/G is among the fastest protocols with the exception of the newer versions of ZMODEM. YMODEM/G also supports multiple file transfer (both down and up) of up to 50 files per "batch". ZMODEM ****** Use this protocol if it is available at both ends. As of 1991, it is the protocol of choice for asynchronous file transfers. It is solid, widely used, and fast. ZMODEM is another protocol developed by Chuck Forsberg of Omen tech- nology. 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 makes ZMODEM one of the fastest protocols available. ZMODEM supports multiple files transfer capability. This is commonly referred to as "batch transfers". ZMODEM also has the unique capa- bility to resume file transfers that have been aborted for some reason and thus only partially completed. This crash recovery facility is usually not needed, but is very handy when it is. ------------------ END -------------------