informis
/
textfiles
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
textfiles/bbs/gttutor0.txt

531 lines
23 KiB
Plaintext
Raw Permalink Normal View History

Initial commit
2021-04-15 11:31:59 -07:00
*****************************************************************
Following is the text portion of a 'reply' to the series of
tutorials that I have constructed and made available to callers
of my BBS system on various subjects related to communications.
This 'reply' is from Chuck Forsberg, author of ZMODEM.
Throughout his original text (which is included in full) are
comments and clarifications by Paul Meiners and myself. All of
our comments are bracketed between /*...*/ symbols and have our
names attached to identify source. --James Davis
(713) 558-5015 Voice
(713) 497-2306 Data
*****************************************************************
/* So far as I know, there have been two fundamental errors in
the content of my tutorials: the first was that in an initial
version I indicated that SEAlink protocol used 32-bit CRC, it
does not. The second is that I inadvertantly confused SEAlink
and Zmodem when discussing the availability of network-friendly
implementation. I apologize for the inclusion of these errors.
In defense I can only say that the tutorials were constructed
'live' as the result of capturing my spontaneous responses to a
series of questions asked by my users, sometimes at 2:00 a.m. in
the morning. Finally, I have never claimed that Zmodem is
anything but an excellent example of contemporay protocols and am
dismayed at the crudeness of Mr. Forsberg's 'reply' and his
suggestion that I am 'brain damaged as a result of drug
intoxication' - a description that my attorney is now in
possession of. --James Davis
*/
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.
/*
Let's get it right, the name of the product is "GT PowerComm".
--Paul Meiners
*/
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.
/*
In actual fact, the purpose of the "tutor" files is not to sell
anything. The purpose is to try to give a frame of reference to
confused users. Something Mr. Forsburg has neglected to do.
--Paul Meiners
*/
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.
/*
Translation: Mr. Forsburg is proud of his product, with some reason.
However, he neglects the main point, the reliability of any protocol
is dependent on its implementation. CRC-16 is a very reliable error
detection device, when used properly. Our disk controllers use it
all the time!
--Paul Meiners
*/
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.
/*
In Mr. Forsburg's original Ymodem specifications, from which I wrote
the protocol drivers for "GT PowerComm", there is no reference to an
Xmodem-1k. In the original documentation, supplied by Mr. Forsburg,
the specification is given for two forms of Ymodem. A simple Xmodem
extension, which he now calls Xmodem-1k, and a batch version. In that
document both protocols are referred to as Ymodem.
--Paul Meiners
*/
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.
/*
Really. It sounds like Mr. Forsburg has not read his own documentation.
On page 7 of his 1985 description of Ymodem Batch, he gives a detailed
example of how to mix 1024 and 128 byte packets. This is just becoming
too silly. Does Mr. Forsburg expect this to be taken seriously?
One does not change the size of a packet that has not been Ack'ed. You
shift to smaller packets ONLY after all outstanding packets have finally
been Ack'ed. To suggest otherwise is too foolish for words.
The fact is well recognized in the field that smaller packets have a
better chance on noisy lines. This is not didactic, but empirical.
--Paul Meiners
*/
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.
/* Fact, in the first series of tests that we ran of Zmodem we
were disappointed in the performance we obtained. Having been
told to expect 99% transmission efficiencies and realizing about
90% during our tests I found it was slower than expected and
certainly slower than Ymodem which I described as the 'King of
performance'. The second tutorial was produced many weeks later
after we had been successful in some new tests (because we had
obtained a working and more efficient version of DSZ.EXE) and I
then pointed out that Zmodem was indeed very fast, though still
not as fast as Ymodem. --James Davis
*/
/*
Unfortunately, most of us do not have Telebit TrailBlazer's. The
simple fact is that Mr. Forsburg measures performance by the number
of bytes sent down the tube in a unit of time. This is very misleading.
The performance as measured in "GT PowerComm" is taken by dividing
the size of the file by the time of transmission. This takes into
account the cost of overhead. Like escaped control characters. Mr.
Forsburg would have us believe that escaped control characters have
no effect on performance. But I know better, because I pay the phone
bill.
--Paul Meiners
*/
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".
/*
Mr. Forsburg continues to display his misunderstanding. Zmodem transmits
bytes fast. There has never been a claim to the contrary. It merely
transmits files slowly. Any protocol that uses escaped characters,
transmits files more slowly than more optimized protocols. For example,
SEAlink has a better performance rating than Zmodem, because it escapes
no control characters at all.
--Paul Meiners
*/
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.
/*
Mr. Davis misunderstood. Which is forgivable considering the complexity
of Mr. Forsburg's documentation. Byzantine is too kind a characterization.
--Paul Meiners
*/
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.
/*
I restate, I would very much like to have Zmodem internal to GT, but
find I lack the required time to accomplish the task. Largely due to
the Byzantine nature of Mr. Forsburg's documentation. A fine protocol
that suffers from verbose documentation.
--Paul Meiners
*/
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.
/*
The name of the product is "GT PowerComm". It is not Mr. Davis'.
It is mine.
--Paul Meiners
*/
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.
/*
The new version of Opus, at this writing, is still in beta test.
It will support Zmodem, which is a much better protocol than SEAlink.
I am very happy to see this happen. Wish everyone supported Zmodem.
--Paul Meiners
*/
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.
/*
To be absolutely honest, DSZ gets changes so often that it is
impossible to keep up with it. There are many BBS's that run
DSZ and warn you to use "Ten Ctrl-X to cancel...". If this has
changed or was incorrect, I apologize.
--Paul Meiners
*/
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.
/*
This is such drivel. Zmodem is obviously network friendly. Where
did he get the idea that we claimed otherwise. This is beneath
comment.
--Paul Meiners
*/
/* As my opening comments pointed out, I inadvertantly described
SEAlink as being Network friendly and Zmodem as not being so.
Mr. Meiners has not made any such comments and apparantly has not
seen that particular tutorial. My error and I will correct it.
-- James Davis
*/
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.
/*
Where does he get the idea that Mr. Davis "hates Zmodem"? This could
not be further from the truth. Mr. Davis and I have the greatest
respect for Zmodem (although my respect for Mr. Forsburg is slipping
a little right now). I remember that Mr. Davis even talked me into
continuing support for Zmodem when I threatened to drop it due to
Mr. Forsburg's incessant releases of DSZ. He doesn't even have a
version number for DSZ, just uses the date for a version number!
Kind of makes life hard for developers trying to keep up with him.
Zmodem is a fine protocol. The premier protocol in the field today.
Nobody hates it. What a weird idea.
--Paul Meiners
*/
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.
/*
Note: If your cabling is not correct, you are sure to have lots and
lots of troubles. Beyond any simple problem with flow control. You
and all modem users better make sure that their cables and modems are
installed correctly. No end of problems will be the result otherwise.
Geez, I thought everyone knew that there is no substitute for proper
installation.
--Paul Meiners
*/
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
/* This additional 'test' is impossible! It is also
meaningless. Mr. Forsberg did not use the exact same hardware as
I did, did not have controlled environments on both ends as I
did, and WORST OF ALL he could not possibly have sent the same
file that I sent in each of the tests that I ran. For those that
read the tutorial you know that every file will have its own
unique performance with network friendly protocols because they
have variable numbers of bytes that may need to be escape coded.
Further, the file size affects how significantly overhead factors
into total transfer efficiency. Mr. Forsberg could just as
easily have said that Zmodem developed performance of 960 cps and
it would have been just as credible. Finally, he claims to have
sent an ASCII file of 473,104 bytes. I used an 800,000 byte
ARCed file in order to ELIMINATE the hardware compression
efficiency that intelligent modems are capable of providing. His
test may well have indicated that his modem is quite efficient,
but it says NOTHING about Zmodem relative to the other protocols.
--James Davis
*/
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.
/*
First, MegaLink supports both forms of flow control. Second, many
circumstances require BOTH forms of control to be used simultaneously.
MegaLink supports this as well. The whole issue of flow control is
a "red herring" on Mr. Forsburg's part. I am beginning not to take
this document seriously.
--Paul Meiners
*/
MEGAlink
MEGAlink is claimed to be a fast, inexpensive, and reliable file transfer
protocol.
/*
I have not claimed this. This was my goal. I let others describe
whether or not I have attained my goal. Being somewhat more modest
than Mr. Forsburg.
--Paul Meiners
*/
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?
/*
There are several "big deals". First, Mr. Forsburg does not deny that
Zmodem is non trivial to implement. That is indeed a "big deal", as
one the goals of most PD protocol designers, all the way back to Ward
Christiansen, is simplicity of design.
The second "big deal" is that the world does not begin and end with
C. There are quite a few other languages out there. It seems that
Mr. Forsburg is rather pompous, considering Zmodem written once and
for all, because it is coded in C.
--Paul Meiners
*/
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.
/*
MegaLink does use the Telink header block. As does SEAlink, by the
way. This is simply a misstatement of fact by Mr. Forsburg.
--Paul Meiners
*/
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.
/*
What Mr. Forsburg considers design errors, I prefer to call
simplifications.
--Paul Meiners
*/
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.
/*
That could be. The only thing I have ever said about Zmodem is
that it is a fine protocol and rather difficult to implement.
--Paul Meiners
*/
MEGAlink offers no advantages over the well designed ZMODEM protocol
except as a vehicle to hype the "powercomm" program.
/*
I gave Mr. Forsburg his due. But the fact remains that neither
Zmodem or MegaLink are easy to implement. Ask John Friel, author
of Qmodem. MegaLink offers a distinct advantage to the implementor.
It offers a structure based on packets. A structure that any author
who has done Xmodem, should feel comfortable with. Obviously, Mr.
Forsburg has different opinions. Zmodem's primary asset is DSZ. An
excellent implementation of a difficult protocol. Zmodem is made
more difficult by Mr. Forsburg's steadfast refusal to stop fiddling
with it. And by the fact that his documentation of it verbose, so
verbose that it is indeed very easy to miss the point.
--Paul Meiners
*/
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.
/*
Mr. Davis is not the author of "GT PowerComm", nor is he the
designer of MegaLink. I am.
--Paul Meiners
*/
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.
/*
"GT PowerComm" is not a "recently released shareware program". It
is currently in version 12.21. After nearly 3 years of development
and distribution. Where did he get his facts?
I am coming to the conclusion that Mr. Forsburg's opinions have litte
to do with reality as the rest of us know it.
--Paul Meiners
*/
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.
/*
The CRC calculator used in "GT PowerComm" are written in MASM, not
Turbo Pascal, as Mr. Forsburg indicates. Another final misstatement.
--Paul Meiners
*/
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
June 26, 1987
I have a very hard time taking this document seriously. I have gone thru it
and tried to make return comments by bracketing them with the C comment markers.
/* .... */ Anything between these marks are my comments, not Mr. Davis' or
Mr. Forsburg's. I consider this whole document rather a bad case of "sour
grapes" on Mr. Forsburg's part. And am quite surprised that he distributed
it publicly. But I consider it an opportunity. An opportunity to set the
record straight. Of course, it is indicative of the fact that we have come
to the "great ones" attention. A sign that we have arrived, so to speak.
Regards,
Paul Meiners
GT PowerComm Author (713) 772-2090 Data
MegaLink Designer (713) 778-9471 Voice
X-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-X
Another file downloaded from: NIRVANAnet(tm)
& the Temple of the Screaming Electron Jeff Hunter 510-935-5845
Rat Head Ratsnatcher 510-524-3649
Burn This Flag Zardoz 408-363-9766
realitycheck Poindexter Fortran 415-567-7043
Lies Unlimited Mick Freen 415-583-4102
Specializing in conversations, obscure information, high explosives,
arcane knowledge, political extremism, diversive sexuality,
insane speculation, and wild rumours. ALL-TEXT BBS SYSTEMS.
Full access for first-time callers. We don't want to know who you are,
where you live, or what your phone number is. We are not Big Brother.
"Raw Data for Raw Nerves"
X-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-X