' HELPPROT.TXT initially started 11-16-91.
'
àPROTOCOL

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.

ê
'
à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.

Auntie only allows ASCII downloads, never uploads.

ê
'
àXMODEM

ñChecksum Xmodemñ

In August of 1977, 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.

Because Checksum Xmodem is so unreliable, it is recommended that you ñNOTñ
select it.

ê
àCRC Xmodem

ñ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.

Although CRC is fairly robust and reliable, it is quite slow due to the
small packet size and frequent handshaking.

ê
'
àYMODEM

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.

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.  Ymodem also will send the
file in a true file size, not having to "stuff" null bytes in the final
block to make a full 1024 byte block.

If your comm program doesn't seem to respond properly to Ymodem, try Batch
Ymodem or, better yet, HS/Link or Zmodem.

ê
'
àBATCH

ñBatch Ymodemñ

There's very little difference between Batch Ymodem and simple Ymodem.  Of
these two, you should select Batch.  If your comm program doesn't seem to
respond properly to Batch Ymodem, try regular Ymodem or, better yet,
HS/Link or Zmodem.

ê
'
à1K Xmodem

ñ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.  Better yet, use HS/Link or Zmodem.

ê
'
àKERMIT

Kermit was developed at Columbia University in New York.  It is a rather
slow, but reliable, streaming protocol used primarily for mainframe
computer communications.  Don't select this protocol unless it is your only
choice.

Note: support for the Kermit protocol is at the discretion of the local
SysOp and may not be available.

ê
'
à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.
Zmodem also has the ability to pick up where it left off on an aborted
transfer if you have the -r command in the command line.  A real time saver
on large files that abort half way through!  Another nice feature of Zmodem
is the ability to adjust the block size on the fly by the line noise
conditions.  Thus, on a clean line the blocks work up to 1024 bytes which
reduces the overhead of the CRC data which is sent with each block.  This
may seem like the best to go with all the time until you think about
re-transmitting of bad blocks.  Zmodem can drop down to 32 byte blocks
under noisy conditions which means a re-send is a smaller block thus
speeding up the overall transmission.

If your comm program doesn't internally support Zmodem, then use
Forsberg's "engine" program, DSZ, avaliable here as DSZmmdd.ZIP.

ê
'
àJMODEM

Jmodem is a second generation protocol developed by Richard B. Johnson of
Boulder, CO, in late 1988.

Jmodem maintains the exact filesize, date and timestamp.  It supports up to
com4.  Pre-existing files are renamed to .OLD rather than being
overwritten.

Jmodem starts off with 512 byte blocks and increases their size by 512
bytes until the maximum size of 8192 bytes is reached.  Each block carries
with it a 6 byte overhead.  The block size is reduced by 512 bytes every
time an error is detected.  It will go all the way back down to 512 bytes
if necessary.

Jmodem uses a 16 bit CRC check for error detection.  While not quite as
robust as Zmodem's 32 bit CRC, this 16 bit CRC still assures the
probability of only one undetected error in 5.44E39 (2^132).

Jmodem also performs on-the-fly data compression.  This can make apparent
transfer speeds seem faster than your baud rate.  The degree of compression
is much greater for files not already compressed.  The speed increase for
ARC or ZIP files, while still there, is not as great as for plain text
files.  Some unsophisticated speed benchmark tests show Jmodem to average
1-3% faster than Zmodem on compressed files (ZIPs, in this case) and 16-34%
on plain text files.

Note: Support for the Jmodem protocol is at the discretion of the local
SysOp and may not be available.

ê
'
àMPT

Formerly known as the PUMA protocol, Matt Thomas' MPT is a robust streaming
block 32 bit CRC protocol.  Block sizes range from 64 bytes up to 1K (1024
bytes) depending on the quality of the line.  MPT is batch capable, that
is, you may send or receive more than one file at a time.  RLE compression
may be selected but this system will generally turn RLE compression off if
the file being sent is already compressed.

Note: Support for the MPT protocol is at the discretion of the local SysOp
and may not be available.

ê
'
àYmodem-G

ñYmodem-Gñ

Ymodem-G is nothing more than Batch Ymodem with ñNOñ handshaking.  It
should be used only when connected with an "error checking" modem.

The lack of handshaking makes Ymodem-G probably the fastest of the
protocols, but if any error creeps in, it has no way of recovering.  Don't
select Ymodem-G unless you're really adventurous.

ê
'
àHSLink

ñHS?Linkñ

HS/Link is a high speed, full streaming, full-duplex, bi-directional, batch
file transfer protocol with advanced full-streaming-error-correction.
Each side of the link is allowed to provide a list of files to be sent.
Files will be sent in BOTH directions until both sides of the link are
satisfied.

HS/Link is not just another bidirectional protocol, it is also a very fast
protocol for normal downloading and uploading, incorporating some new ideas
(such as Full-Streaming-Error-Correction and Dynamic-Code-Substitution) to
make things happen a bit faster and with greater reliability.

ê
'