|10000$STW$$SMF$$DTW$$SAVE4$|*|w05002C0N11

                       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 <CR> (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 <CR> (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
|10000$RESTORE4$$RTW$$RMF$
