<< Previous Message Main Index Next Message >>
<< Previous Message in Thread This Month Next Message in Thread >>
Date   : Thu, 08 Aug 1985 13:21:16 EDT
From   : Steve Noland <NOLAND@USC-ISI.ARPA>
Subject: Protocol Wars

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)
<< Previous Message Main Index Next Message >>
<< Previous Message in Thread This Month Next Message in Thread >>