All About Protocols ----------------------- A protocol is a set of rules and conventions that apply to a specific area of communications that allow participants to properly communicate regardless of the hardware brand or software package being used. The protocol file transfer is a set of rules for transferring files which specify a set of ASCII handshaking characters and the sequence of handshaking required to perform certain file transfer functions. Protocol handshaking signals allow communication software to transfer text, data and machine code files, and to perform sophisticated error-checking. Some protocols are faster then others and some are more foolproof in the way they detect errors. This BBS supports eight protocols: 1)K Xmodem CRC A)SCII B)atch Ymodem C)RC Xmodem K)ermit X)modem (Checksum) Y)modem Z)modem The following is a discussion of each. ASCII ----- ASCII stands for American Standard for Computer Information Interchange. Is consists of 128, 7 bit codes (0 - 127). Many computers implement a "bit-8" set (128-255) but these will differ from system to system. The bottom 128 are always the same. ASCII transfer is not really error checked at all. The only "handshaking" that takes place is the use of Xon/Xoff (ASCII codes 17 and 19, decimal, or ^S/^Q). When the sending system receives a ^S from the receiver it stops sending until the receiver transmits a ^Q. Only plain text files should be transmitted with this protocol since they generally will not contain bit-8 characters. You may use 7 word bits, Even parity, 1 stop bit communications parameters with ASCII. All the remaining protocols require 8-N-1. Xmodem (Checksum) ----------------- In the early 1960's, Ward Christensen developed one of the first public domain "8-bit" error checking protocols. He originally developed it for CP/M systems and called it MODEM-7. The late Andrew Fluegelman popularized it as Xmodem when he implemented it in his PC-TALK III program. Xmodem sends information in "packets" of 128 bytes. The error checking comes about by adding up the ASCII value of these bytes, dividing by 256, and throwing away the remainder. This is called a modulo 256 checksum. The sender calculates this checksum and transmits it along with the 128 byte packet. Once received, the receiver calculates it again on the received packet. If the two checksums DON'T agree, the receiver sends a NAK (Negative AcKnowledgement) which causes the sender to retransmit the packet. If the checksums DO agree the receiver sends an ACK character. The transfer continues in this manner until completed. Modulo 256 checksum checking is not 100% foolproof. Certain kinds of line noise can cause corrupted packets to be received which contain the correct checksum but incorrect data. Most communications programs support Xmodem. Several of them also support what is known as "relaxed" Xmodem. Relaxed Xmodem uses the same checksum protocol, but relaxes several of the timing constraints built into Xmodem in order to work on busy time sharing systems such as CompuServe. You need not use relaxed Xmodem when connected to a bulletin board system such as this one. Xmodem CRC ---------- Xmodem CRC uses a complex polynomial equation to calculate a 16 bit (2 bytes) Cyclical Redundancy Check (CRC) on the Xmodem 128 byte packet. The CRC value is a much more robust method of detecting transmission errors. The remainder of the handshaking takes place in the same manner as checksum Xmodem. CRC Xmodem is transparent to the user. That is, if you select CRC as your protocol and your system fails to send the proper codes, CRC Xmodem will "fall back" to checksum Xmodem. So, if you don't know if your communications program supports CRC, select it anyway. Older comm programs such as PC-TALK III do not support CRC Xmodem. Ymodem and Ymodem Batch ----------------------- Ymodem was developed by Chuck Forsberg of Omen Technology in Portland, OR, as the next protocol after Xmodem. Ymodem is essentially CRC Xmodem with 1024 byte (or 1 kilobyte, or 1K) packets. (see also 1K Xmodem, below). However, UNLIKE Xmodem, which always starts off with its first packet being labeled #1, true Ymodem starts off with its first packet labeled as #0. This packet contains the time and date stamp of the file being transferred along with its filesize and filespec. In addition, true Ymodem may operate in "batch mode" which, if implemented, allows the receiver to specify more than one file to be transferred in a session. Many comm programs and BBS's have not implemented Ymodem properly. Some, Procomm for example, have "Ymodem" and "Ymodem Batch." Quoting Chuck Forsberg,"Ymodem Batch is redundant. If it's Ymodem, it supports batch operations. If it doesn't support batch operations it isn't Ymodem, but 1K Xmodem." This system supports both Ymodem and Ymodem Batch. If you select "Y" what you will actually get is 1K Xmodem. If you select "B" (for Batch Ymodem) you will get the true Ymodem. Note, however, that multiple files transferal is not allowed on this system. QMODEM and BOYAN users should select either "1" or "Y" as your protocol. These programs do NOT properly handle true Ymodem (Batch). 1K Xmodem --------- 1K Xmodem is CRC Xmodem using 1024 byte (1K) packets. The first packet sent is labeled #1. Select this protocol if you have had problems with Ymodem Batch or if you are running Qmodem or Boyan. Better yet, use Zmodem (see below). Kermit ------ Kermit was developed at Columbia University in New York. It is a public domain protocol that has several interesting features I won't bother to detail here. Kermit is supported here via the use of PCKERMIT. Both "classic" and "sliding windows" Kermit are supported automatically. Zmodem ------ Zmodem (the next one after Ymodem) is a public domain protocol developed by Chuck Forsberg. Zmodem uses a 32 bit CRC to detect transmission errors. It also allows for batch transfer of more than one file along with time/date stamping. Unlike X/Ymodem, Zmodem doesn't wait for the receiver to acknowledge receipt of an error free packet. Rather, it continues sending until the receiver sends a "packet NAK" which causes the sender to resend that one bad packet. This lack of "turnaround" time delay is what greatly speeds up Zmodem transfers. Implementing Zmodem ------------------- Chuck Forsberg has written a program called DSZ. It is available on this BBS as DSZmmdd.ARC, where mmdd is the date of his latest version. Issue a DIR;DSZ*.* to locate it. Note: DSZ is a trademark of Chuck Forsberg and Omen Technology Inc., P.O. Box 4681, Portland, OR. DSZ is SHAREWARE (although Chuck doesn't call it that) and you should send the $20 the author requests if you use it. DSZ is a program which supports X/Y and Zmodem. It must be run as a "child process" of another program such as a comm or BBS program. If your comm program allows a "shell" or "door" or "gateway" to DOS or a DOS function, you can implement DSZ. The following is a list of some of the more popular comm programs which can do this: Program Key for SHELL to DOS ---------------- -------------------- * Boyan Alt J or Ins GT PowerComm Runs DSZ directly. Procomm 2.4.2 Alt F4 * Qmodem SST Alt R Telix Alt V * Both Boyan and Qmodem are configurable to run DSZ via their separate configuration areas. Refer to your documentation. After you have told this BBS which file to transfer, SHELL out to DOS and run DSZ. DSZ expects the serial port to be connected and will use all the parameters it finds. One exception to this is if you are running on COM2. Consult the DSZ.DOC file which comes with DSZmmdd.ARC. One very easy way to use DSZ is to create two small .BAT files to handle all the chores (or write two CED or PCED SYNonyms). Here are two that are known to work well: RZ.BAT (or CED SYN RZ) dsz rz -y [or, for COM2,] dsz port 2 rz -y SHELL to DOS and type RZ, this BBS will send the proper filename and the file. Enter "Exit" to return to your comm program when done. SZ.BAT (or CED SYN SZ) dsz z pL1024 sz %1 [or, for COM2,] dsz port 2 z pL1024 sz %1 (Note the capitalization in the "pL1024" !) To upload FOO.BAR, SHELL to DOS and enter SZ FOO.BAR and the file will be sent. Again, enter "Exit" to return to your comm program when done. I hope this discussion helps. The use of Zmodem will assure error free files transfer and will save you time and phone charges. Wes Meier WC-BBS, [415]-937-0156 July 6, 1987