***************************************************************** 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