Factual Errors in "GTTUTOR" and "MEGAlink" files
                       (Part of COMTUT.ARC)
                Chuck Forsberg omen!caf Rev:6-23-87

Some files connected with a recently released shareware "Powercomm"
communications program have recently come to my attention.

The "Communications Tutor" files contained in "comtut.arc" are little more
than a sales pitch for a modem program.  These files are so full of errors
and distortions they have minimal didactic value.  They disguise that fact
so well they are carried on many boards that normally reject such blatant
advertising.

The so-called "tutorial's" claim that CRC-16 increases XMODEM reliability
to near perfect ignores the fact that most XMODEM-CRC file transfer
failures are the result of corruption of XMODEM control sequences that are
*not* protected by a 16 bit CRC.  Omen's "Cybernetic Data Recovery"
catches many of these errors, but some still cause XMODEM failures.  Other
programs do not fare as well.

GTTUTOR confuses YMODEM protocol with XMODEM-1k.  YMODEM, developed in the
early 1980's, preserves both the exact file length and the modification
time of transferred files.  Like XMODEM, XMODEM-1k adds garbage to the end
of files that are not an exact multiple of the protocol's block length.
Since this process is not cumulative, no disk storage space is lost on
today's MSDOS disks where the smallest cluster size is 1k.

Having missed the point about YMODEM, GTTUTOR goes on to describe how
their "1K Telink" protocol downshifts from 1024 byte to 128 byte blocks
when encountering a set of 6 errors.  Thank Heavens they didn't call it
"ymodem".  The GTTUTOR file fails to mention that YMODEM.DOC specifically
forbids this form of downshifting because changing the size of an
unacknowledged block allows data errors to escape detection by the CRC.

Most intriguing is the comment that ZMODEM is slow.  This comes as a great
surprise to ZCOMM and Pro-YAM users who routinely get throughputs better
than 18000 bps when transferring files to PC-XT class machines from Unix.
Telebit TrailBlazer modem users who download files from TeleGodzilla over
wretched (Thanks, PNB) phone lines with throughputs up to 1350 characters
per second would join in the laughter.

GTTUTOR's claim that ZMODEM is too slow is especially puzzling because it
later claims ZMODEM fails to operate with 9600 bps buffered modems because
it is too fast!!  So here we have a protocol that is both too slow and too
fast.  The relevant word isn't "slow" or "fast", it's "bogus".

GTTUTOR further states that ZMODEM uses 256 byte blocks.  In actuality,
ZMODEM uses a variable subpacket length up to 1024 bytes.  A ZMODEM data
frame can encompass an entire file.

Davis mentions that ZMODEM is "not a protocol that is written into a
program like GT".  Considering how little Davis understands about
ZMODEM, that is indeed fortunate.

Davis mentions he twice called his "powercomm" "procomm" in his
documentation.  He contemplates how embarrassed he would have been if the
documentation had been released that way.  So, he took POLYTRON's PowerCom
trademark, doubled the "m" letter, and called his program that.

When mentioning that SEALINK is becoming popular because the Opus BBS
system supports it, GTTUTOR fails to mention that Opus now supports ZMODEM
as well.

GTTUTOR complains that ZMODEM requires ten Ctrl-X's in a row to abort a
transfer.  As with many observations in these files, this observation is
wide of the mark, ZMODEM only requires five.  If Davis had read the ZMODEM
Protocol Description before flaming, he would have noticed the comment
that ZMODEM originally required only two Ctrl-X's in a row to abort, but
this was changed to five because several transfers had failed when line
noise generated two Ctrl-X characters in a row.

GTTUTOR further claims: "Because it is not network friendly it (ZMODEM)
does not bother with (doesn't have to) escape coding anything.  This is
probably a fatal mistake to its future particularly as the networks get
crowded." Such a comment makes one wonder if the author had ever read the
ZMODEM Protocol Description except perhaps while brain damaged from drug
intoxication.  Again, reality has little to do with GTTUTOR's world;
ZMODEM escapes all the network control characters used by the major
PSVANs, and has an option to escape all control characters.  If
"powercomm's" MEGAlink protocol is implemented according to its April 18
document, it is much less network friendly than ZMODEM.

GTTUTOR closes with a section on high speed (>2400 bps) modems.  It should
come as no surprise that Davis still hates ZMODEM, not bothering to set
DSZ and the modem to use the same flow control method.  Remember, this is
the same ZMODEM protocol that is too slow for slow modems, or so we were
told.

You'd think that a tutorial on data communications might have mentioned
there are two methods of flow control.  A tutorial might have mentioned
what this means in practical terms.  For example, hardware flow control
locks up communications unless the cabling is exactly correct (which it
usually isn't).  That's why Pro-YAM, ZCOMM, DSZ, most networks and modems
default to software flow control.  But for this test, nobody bothered to
use the defaults.

Here is an updated version of the speeds using 9600 bps transmission, with
the ZMODEM test using TrailBlazer modems with a 9600 bps interface speed
(better results are obtained at 19200 bps).  The ZMODEM results show a
473104 byte ASCII file transferred over a phone line to an IBM PC with an
XT class hard disk.

		WXmodem   60.4 % efficiency  580 cps
		SEAlink   75.6 %             725 cps
		Ymodem    77.6 %             744 cps
		MegaLink  98.5 %             945 cps
		************************************
		Zmodem    98.8 %             948 cps


Contrary to GTTUTOR's earlier claims of ZMODEM lethargy, DSZ on an XT, let
alone an AT, is fast enough to overdrive a high speed modem when flow
control is mismatched.  DSZ, ZCOMM, Pro-YAM and PowerCom default to
XON/XOFF flow control, as do TELEBIT TrailBlazer and many other buffered
modems.  They work properly, even when using a 19200 bps interface speed
and a 300 bps modem connection.  ZMODEM programs have been used with
TrailBlazer, Fastcomm, MNP, Data Race, and other buffered modems.  In
fact, Pro-YAM's experience with high speed modems is so extensive that
Pro-YAM includes special code to work around a subtle firmware bug in some
of the modems.


                        MEGAlink

MEGAlink is claimed to be a fast, inexpensive, and reliable file transfer
protocol.

The MEGAlink description identifies ZMODEM as the ideal protocol, fast and
reliable (it is), but expensive (i.e., non trivial) to implement.  (ZMODEM
protocol software is available in PUBLIC DOMAIN C source code.) Since most
of the problems in porting ZMODEM to a new system arise from the
concurrency of data transmission and compiler bugs affecting the CRC
calculations, MEGAlink offers no advantage here unless one's only compiler
is Turbo Pascal.  Now that Turbo C can be bought for less than $60.00,
what's the big deal already?

MEGAlink claims to use the Jennings Telink header block format.  The
header block described actually resembles the SEAlink header block, which
is different from and incompatible with the Telink header.

The developer(s) of MEGAlink did not read the ZMODEM protocol description
carefully, or they would not have repeated so many of the design errors of
previous protocols that were identified in the ZMODEM document.

In addition to repeating many of the mistakes that were identified and
avoided in the design of ZMODEM, MEGAlink's author(s) make a number of
false statements about ZMODEM.

MEGAlink offers no advantages over the well designed ZMODEM protocol
except as a vehicle to hype the "powercomm" program.

Before filling up disk quotas and phone lines with bleeding about the
"MEGAlink" protocol, MEGAlink's authors should have taken the time to
understand the workings of ZMODEM.  They could have implemented a useful,
user friendly, robust, efficient, well thought out protocol instead of
MEGAlink.

A careful reading of the ZMODEM description would also have resulted in
correct spelling of names and a realization that the recently released
shareware program should not infringe on Polytron INC's "PowerCom"
trademark.

If you come across these files, pass them on to your communications guru
friends for some good chuckles.  The Pascal dialect CRC calculations are
priceless.  But please don't give these cleverly disguised sales pitches to
the incognoscenti without a ton of salt.

Chuck Forsberg WA7KGX Author of Pro-YAM communications Tools for PCDOS and Unix
...!tektronix!reed!omen!caf Omen Technology Inc "The High Reliability Software"
  17505-V Northwest Sauvie Island Road Portland OR 97231  Voice: 503-621-3406
TeleGodzilla BBS: 621-3746 2400/1200  CIS:70007,2304  Genie:CAF  Source:TCE022
  omen Any ACU 1200 1-503-621-3746 se:--se: link ord: Giznoid in:--in: uucp
  omen!/usr/spool/uucppublic/FILES lists all uucp-able files, updated hourly