HELP WITH FILE TRANSFER PROTOCOLS The system supports a variety of file transfer protocols. NOT ALL OF THESE MAY BE AVAILABLE TO YOU AT ALL TIMES. The protocols supported are listed and described herein. ASCII PROTOCOLS These protocols should be used ONLY as a last resort, if your terminal or communications software cannot support one of the error-resistant protocols (whose descriptions follow). The following ASCII methods are available: 1) Prompted ASCII (Upload). The prompt character is the '>' (greater than) character. The reason for utilizing a prompt character is to allow a delay to occur when the system is writing to the disk. The prompt will not reappear until the system is ready to receive the next line of text. To use this mode your terminal software must stop sending after each (carriage return) until it receives the next '>'. You terminate the upload by typing 'END'. No input data line may be more than 255 characters long in this mode. 2) XON after (Upload). This mode is very similar to the prompted mode. Your terminal program must stop sending after each carriage return and wait for an XON (^Q) to be sent by TBBS before continuing. You terminate the upload by typing 'END' on a new line. The 255 character maximum line length still applies in this mode. Again, you terminate by typing END after a carriage return. 3) XOFF/XON (Upload). In this mode your terminal program sends characters until it receives an XOFF (^S) from TBBS. Your terminal program then waits for an XON (^Q) to resume sending. It must ignore any other characters (except to display them if desired) while waiting for an XON. In this mode, there is no limitation on line length. You still terminate this mode by entering END after a carriage return. 4) ASCII with ^R/^T Capture (Download). This method signals your terminal program with a ^R before the data starts, and a ^T when it ends so your program can capture only the file. Otherwise it is like the ASCII no control codes described next. 5) ASCII No Control Codes (Download). TBBS will send the data to your terminal with no halts. Your terminal may stop the data at any time by issuing an XOFF (^S) if it needs to stop to write the data to disk etc. It then restarts the data flow by sending an XON (^Q). XMODEM PROTOCOL This is the most widely available error resistant protocol used today. Any terminal or software which supports this protocol may be used. There are two variations of this protocol: Checksum, and CRC. Either variation is supported and may be used. XMODEM uses 128-byte data blocks, and is somewhat slow at high speeds. XMODEM is NOT a batch protocol, and therefore can only transfer one file per transaction. XMODEM-1k PROTOCOL This is a variation of regular XMODEM, and is sometimes called YMODEM. XMODEM-1k uses 1,024-byte data blocks, and is better (but not ideal) at higher speeds. If the line quality is poor, XMODEM-1k will slow down the transfer more than regular XMODEM would. XMODEM-1k is NOT a batch protocol, and therefore can only transfer one file per transactions. YMODEM (Batch) PROTOCOL This protocol is similar to XMODEM-1k, but it also has batch transfer capability. This is sometimes called "True YMODEM". Because it is a batch protocol, it can transfer multiple files in a single transaction, and the file name and exact file size are also transferred. YMODEM-g (Batch) PROTOCOL This protocol is a variation of the YMODEM (Batch) protocol described above. The difference is that this protocol does NOT provide error correction, but instead, expects the communications link to provide this function. Because of its design, this is the fastest file transfer theoretically possible. However, an error-free link (usually accomplished with MNP or V.42 protocols having been built into the sending and receiving modems) is REQUIRED. If this protocol is used on a non-error-free link, one single error in the transfer will cause it to abort! SEAlink PROTOCOL SEAlink is a "sliding window" variant of XMODEM. It was developed by System Enhancement Associates, and overcomes transmission delays caused by satellite links or packet switched networks. It is a full duplex protocol and has a "window size" of up to 6 blocks of 128-bytes each. This means that end-to-end link delays of up to 6.6 seconds (at 2400bps) will not slow down the file transfer speed. For reference, a delay of this size using regular XMODEM would make the transfer take seven times its normal time to complete. KERMIT and SuperKERMIT PROTOCOLS All of the above listed protocols require a full 8-bit data link to operate correctly. Also, they are primarily supported by PC terminal programs, and are often not available on mainframes and minicomputers. KERMIT was developed at Columbia University and released into the public domain in order to address these problems. A version of KERMIT as a terminal program is available from Columbia University for almost every micro, mini, and mainframe in use today. This protocol will "negotiate" the link characteristics and adjust automatically to 7- or 8-bit data, and to other features which may or may not be available on all implementations. It is also "friendly" with packet networks of all types, since it guarantees that no control characters will ever be sent which the link may try to respond to. The TBBS KERMIT implementation will support such optional KERMIT features as data compression, 8th bit quoting, and sliding windows (SuperKERMIT) if both the link and the calling terminal program will support them. TBBS does not support the GET "server" command, but uses the RECEIVE mode instead. SuperKERMIT adds sliding windows to eliminate link delays. SuperKERMIT will automatically negotiate its way back to regular KERMIT if your terminal program does not support SuperKERMIT. SuperKERMIT provides a window size which is large enough to eliminate the effect of end-to-end link delays of up to 23.5 seconds at 2400bps, or almost 6 seconds at 9600bps. ZMODEM-90(Tm) PROTOCOL This protocol is among the most popular available today. ZMODEM includes dynamic packet sizing, automatic download start-up and streaming mode for fast, efficient transfers. Failed transfer recovery is supported on downloads from the system as well (not on uploads, however). In addition to standard, public domain ZMODEM features, all ZMODEM-90(Tm) extensions are available as well. These include RLE data compression, 7-bit data link support, and MobyTurbo(Tm) for faster transfers on some link types. ZMODEM-90 and MobyTurbo are trademarks of Omen Technologies, Inc. for their licensed ZMODEM enhancements. PROT (2.2) 11/91