SUBJECT : YMODEM.DOC BUGS FROM : IRV HOFF W6FFC DATE : 15 OCT 85 Chuck Forsberg has updated his YMODEM.DOC file and re-released it with a 10/10/85 date. In general this is an excellent document, well-thought out, professionally prepared and amply notated. It contains information not previously collected in the same file, and will be useful for anybody wanting to understand more about the original Christensen protocol, the addition of CRC for greater accuracy in detecting errors. It carefully spells out the enhancements made by Chuck Forsberg himself (and others) to make the protocol more useful in today's fast-moving computer field. There are some errors that he overlooked during proof-reading which should be corrected. It will only take a moment to use the editor to make the changes noted below: ------------------ 1) TEXT: References to the MODEM or MODEM7 protocol have been changed to XMODEM to accommodate the vernacular. In Australia, it is properly called the Christensen Portocol. FIX: Obviously this is a typo. Humorous as it is, the last word should be changed from "Portocol" to "Protocol". ------------------ 2) TEXT: Watch for an article describing the YMODEM protocol in a more coherent fashion later this year. The article will include some interesting history on the development of microcomputer file transfers. FIX: This is probably more misleading than inaccurate. Ward Christensen was planning to write an article earlier in 1985 for publication in Byte magazine in late 1985. He said as recently as 14 October that he not even started writing the article as yet. With 4-6 month lead time (submission to publication) typical with such magazines, do not look for the article until mid 1986. It is possible Chuck Forsberg has already submitted an article to some magazine himself, and was referring to that. Since he had anticipated Ward's article would be soon, that seems unlikely. ------------------ 3) TEXT Figure 5. Header Information used by YMODEM Implementations _____________________________________________________________________ | Program | Batch | Length | Date | Mode | S/N | 1k-Blk | g-Option | |___________|_______|________|______|______|_____|________|__________| |Unix rb/sb | yes | yes | yes | yes | no | yes | sb only | |___________|_______|________|______|______|_____|________|__________| |VMS rb/sb | yes | yes | no | no | no | yes | no | |___________|_______|________|______|______|_____|________|__________| |Pro-YAM | yes | yes | yes | no | yes | yes | yes | |___________|_______|________|______|______|_____|________|__________| |CP/M YAM | yes | no | no | no | no | yes | no | |___________|_______|________|______|______|_____|________|__________| |KMD/IMP | yes | no | no | no | no | yes | no | |___________|_______|________|______|______|_____|________|__________| |MEX | no | no | no | no | no | yes | no | |___________|_______|________|______|______|_____|________|__________| FIX: There are three types of file lengths that could be used: 1. Total character count (used by PRO-YAM) 2. 'k' length (such as 32k) 3. Record count (used by KMD/IMP and CP/M in general) While KMD/IMP use record count, this is still a file length attribute and should be included in the table under Figure 5, perhaps with an asterisk. Else it appears those programs do not offer file length, which is false and misleading. | | |___________|_______|________|______|______|_____|________|__________| |KMD/IMP | yes | yes* | no | no | no | yes | no | |___________|_______|________|______|______|_____|________|__________| |MEX | yes# | no | no | no | no | yes | no | |___________|_______|________|______|______|_____|________|__________| | | It is also inaccurate to say that MEX does not offer batch mode, as it has MODEM7 batch. (IMP has MODEM7 batch as well as YMODEM batch. ------------------ 4) TEXT: 4.1 IMP/KMD Record Count Due to programming constraints, these programs do not send the file length as described above. Instead, they send (and look for) the CP/M re- record count stored in the last two bytes of the header packet. The least significant bits are stored in the penultimate byte. KMD and IMP use the record count to allow the receiving program to display the file size and estimated transmission time; the file length is determined by the actual number of records sent. 5. g Option File Transmission FIX: Note the addition of the asterisk at the first of the line explaining the "yes*" added to Table 5. This should clar- ify the table appropriately and accurately: 4.1 IMP/KMD Record Count ---> *Due to programming constraints, these programs ~ ~ ~ estimated transmission time; the file length is ---> shown by both record count and length in 'k'. ------------------ 5) TEXT: 3.3 1024 Byte Packet Option The choice to use 1024 byte packets is expressed to the sending program on its command line or selection menu. Programs using the Hoff protocol use a two character sequence emitted by the receiver (CK) to automatically trigger the use of 1024 byte packets as an alternative to specifying :1: this option on this command line. Although :2: this two character sequence works well on :3: single process micros in direct communication, :4: timesharing systems and packet switched networks :5: can separate the successive characters by sev- :6: === eral seconds, rendering this method unreliable. An STX (02) replaces the SOH (01) at the begin- ning of the transmitted block to notify the receiver of the longer packet length. The transmitted packet contains 1024 bytes of data. The receiver should be able to accept any mix- ture of 128 and 1024 byte packets. The packet number is incremented by one for each packet regardless of the packet length. FIX: The argument expressed in the second paragraph, ending with the line marked "===" is so misleading as to border on deliberate misrepresentation. 1st) Few networks would allow 1024 character blocks in the first place. Even Kermit with its adjustable packet length is limited to 96 characters maximum. 2nd) - ONLY those two characters are sent, each few seconds until recognized. The chances of any network system splitting the only two characters they have even seen for several seconds approaches the improbable. (The CK is repeated at periodic intervals, similar to how the C is repeated by the XMODEM protocol until finally recognized. At this time both systems revert to normal ACK-NAK and no more C or CK are ever sent until the next file transfer is commenced. To say this is "unreliable" is almost like saying the sun might not come up the next day - always possible, perhaps.) 3rd) - even if this possibility existed, the WORST that could happen would be the following file would be sent as 128 character packets instead of 1024. This is not a horrendous failure of the system as Mr. Forsberg seems to envision. 4th) - even if the two characters "CK" should become separated, using Mr. Forsberg's logic, if the 'C' were missed, the 'K' is more than adequate, by itself, to trigger the automatic 1k packets being sent. (IMP, KMD and XMODEM (since XMODEM 112) do not even need the "C" to send 1k packets and it could be dropped entirely, other than Mr. Forsberg's YAM or PRO-YAM system would then be unable to transfer any files at all. Hence the "CK" method was adopted to be universally acceptable. Mr. Forsberg has apparently chosen to conveniently forget this feature, since his system for YAM or PRO-YAM can not use automatic 1k protocol in their present form.) IMP, KMD and all XMODEM* programs since XMDM112 have the automatic 1k protocol. All three do accept Mr. Forsberg's manual "SK" or "-k" that was developed in 1981 and is re- quired by any YAM or PRO-YAM program. (* denotes the XMODEM program, originally written by Keith Petersen, based on the MODEM2 program by Ward Christensen.) (If he were to talk with any IMP or KMD user, he would hasten to develop this automatic 1k protocol in his own programs, assuming he is trying to offer features his customers would find especially useful - for example, 1k protocol saves about 8-9% file transfer time at 1200 bps and about 14-15% at 2400 bps. With 9600 bps modems likely available by Xmas 1985 for normal long distance use, these figures would jump rapidly.) NOTE: I would suggest the last six lines marked with :1:, :2:, :3:, etc, be erased, starting at the end of line marked :1: - this would adequately handle the situation and make any further discussion unnecessary. ------------------ SUMMARY: Mr. Forsberg has done an outstanding job in compiling data on the original Christensen protocol. He has solicited comments from those directly involved in the development and explanation of the Christensen protocol. There are some additional phrases he could well include, or modify, as pointed out above, to make his reporting more factual and accurate. While there may be other areas in which I could suggest some modest changes, and may be other typographical errors of minimal impact, I chose to only mention those above, with which I am personally more closely involved. Mr. Christensen has mentioned publicly on many occasions, he cannot see any reason to need to type "SK" to get the 1k packet mode, and feels (as do I and many others) this should be fully automatic and totally transparent to the user. Mr. Forsberg has so far never adopted or even sympathized with this point - likely since all of his programs would need to be updated in that event and his customers (PRO-YAM is a commercial program for IBM MS-DOS users) re-educated to some extent. (They could continue using "SK" as it would would then be superfluous in any case and give similar results.) Mr. Forsberg's programs all still require "RC" to receive in CRC, else they use checksum. Mr. Christensen has said he would like to see modem programs stop using checksum and rely on CRC with automatic 1k protocol. The automatic default to CRC has been done all MODEM7, MDM7, MEX, COMM7, SMODEM and IMP modem programs since 1981. (They do all offer checksum after making an optional selection but default to CRC, unlike the YAM programs supported by Mr. Forsberg which all apparently default to the checksum mode.) - Irv Hoff Los Altos Hills, CA (415) 948-2166 - voice DL 0 - CP/M-80 :