NOLAND@USC-ISI.ARPA (Steve Noland) (08/08/85)
In the interest of broadening the scope of this discussion, I am relaying the following discourse that was found today on the MBBS Central RCP/M. To: All who are interested From: David McCord, sysop, ZCPR3 BBS (415) 489 9005 Date: 4 Aug 85 Subj: yet another opinion It seems as though many sysops (you know who you are) have an ax to grind against Irv Hoff. The various recent notes I have seen on the sysop board and in other places air a trend I see as undesireable; belittling KMD because they want to grind their axes against Irv. I am not attempting to defend whetever real or percieved greivances they may have against Irv; but I must question their rationale in their criticisms of KMD and BYE500. One of the things that not many sysops know is that Irv did not implement the automatic selection of 1k or 128 byte packets purely on his own whim. He was asked to bring forth a xmodem-like program that had automatic selection of block size by the northern california sysop organization, PRACSA. The reason this sysops organization did this was mainly ease of use for non-technical users. And, we believed there was sufficient precedent in the automatic selection of CRC or checksum error checking modes to warrant automatic selection of block size. By "automatic", I mean the user need not use any extra command line parameters, i.e., simply use "XMODEM S" or "KMD S". I have seen folks questioning and ridiculing the extra "K" that KMD uses in the synchronization stage to accomplish the automatic selection of block size. However, their comments are never specific, usually something along the lines of "it sucks". Personally, I would like some specific information on why "it sucks", because I have yet to see any. In my opinion as a professional telecommunications engineer, I see nothing wrong with the extra character. The overhead involved is exactly one character time at whatever baud rate is being used, no matter how long the file to be transferred is. This is hardly inefficient or undesireable, since the result is a program that is easier to use. Because the PRACSA sysop organization asked Irv to develop what has resulted in KMD, most of us are using it. We will probably go on using it until we are shown solid reasons why we should not do so. I do not speak officially for PRACSA, as I am not an elected officer. However, I am quite willing to speak at the next PRACSA meeting on the disadvantages of KMD, should any be brought out. Perhaps the only valid criticism of KMD is it's name: it is not XMODEM. I do not have a problem with this personally, because if you are using ZCPR3 (as I am), it is quite easy to construct an ALIAS named XMODEM that passes it's parameters to KMD.COM. However, for non-Z3 systems, facilities such as SYNONYM could do this also. Yet, I do concede this as a valid "problem" of KMD. But this leads me to the reason that KMD was named differently than XMODEM. It is because KMD uses BYE500; XMODEM does not. Charges have been made that Irv is trying to "lock in" XMODEM to systems using BYE500. Wrong! Irv has "locked in" KMD to systems using BYE500, NOT XMODEM!!! Irv has not, to my knowledge, ever come out and said that everyone can get rid of XMODEM now that KMD is here. If someone wants to use XMODEM as a standalone program, fine. They have that choice. But for systems already using BYE, eliminating the redundancy of both the file transfer program and BYE both having the same routines makes sense. And, having used BYE500 and KMD on my BBS, I am quite pleased with the added functionality. I can use the BYE function keys when KMD is active, and I get a much more informative description of block errors during file transfer than I ever recieved using XMODEM. Also, it is quite easy to install. In summary, I think that the arguing that has been going on has not really been specific enough regarding why KMD may be an inferior choice; instead it has been oriented more toward "We don't like Irv, and we're gonna get him by trashing KMD and BYE500". The people who are doing this are doing everyone a disservice, because the pseudo-debating is not addressing the real issues involved. We could invest our time better by: - informing users as to the merits and demerits of the 1k block in various circumstances, - discussing if it is better or not better to have auto selection of 1k blocks (regardless of the technique used), - discussing if it is possible for any mini- or mainframe based multiuser system to cope with 1k blocks with any increase in throughput, etc. I plead with all involved to continue debating the issues involved, but to become oriented to facts and logic, instead of insinuation and emotion. Enough said! (for now...) ======================================== Regards, Steve Noland (NOLAND@USC-ISI) -------
caf@omen.UUCP (Chuck Forsberg WA7KGX) (08/13/85)
The main weakness in the Hoff protocol is the dependence on timing of the C-K sequence. If timesharing systems, error correcting modems, and/or packet switch networks are involved, two characrers sent back to back can arrive at the other end separated by several seconds, and vice versa. With the advent of PC-PURSUIT which allows virtually unlimited night calling within 12 cities local call areas for a $25/month flat fee, these considerations may be upon us sooner than we think. The YMODEM protocol, wherein the block size is specified to the sender (SK for 1k, S for 128) has been in use for several years on a multitude of micro, mini, and mainframe computers and does not have this weakness. Working between two sngle process micros, with standard modems and phone lines, the Hoff protocol works well enough for CP/M use. -- Chuck Forsberg WA7KGX ...!tektronix!reed!omen!caf CIS:70715,131 Omen Technology Inc 17505-V NW Sauvie Island Road Portland OR 97231 Voice: 503-621-3406 Modem: 503-621-3746 (Hit CR's for speed detect) Home of Professional-YAM, the most powerful COMM program for the IBM PC