Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!ames!coherent!dplatt
From: dplatt@coherent.com (Dave Platt)
Newsgroups: comp.dcom.modems
Subject: Re: xyzmodem problems
Message-ID: <25165@coherent.com>
Date: 18 May 89 17:06:48 GMT
References: <24404@agate.BERKELEY.EDU> <1399@bucket.UUCP> <765@omen.UUCP> <24552@agate.BERKELEY.EDU>
Reply-To: dplatt@coherent.com (Dave Platt)
Distribution: usa
Organization: Coherent Thought Inc., Palo Alto CA
Lines: 61

In article <24552@agate.BERKELEY.EDU> Earl H. Kinmonth writes:
> By the way, am I "wrong" in thinking that the apparent assumption of a
> clear eight-bit path in the [xy]modem protocols represents {naive|
> brain-dead|criminally stupid} programming? Was there something
> different about the world when these protocols were written that a
> clear eight-bit path could be assumed? Maybe because I'm an historian
> and not a programmer, I would start from the assumption that any
> communications protocol ought to have as a fall back option nothing
> better than a BCD character set. (Anything less, and you may as well
> revert to carrier pigeons.)

Naive, perhaps;  brain-dead or criminally-stupid, no.

The XMODEM protocol was devised by a hobbyist, so that he and his
friends could reliably transfer data over low-speed modem lines between
their personal computers (this was back in the days when "PC" meant "a
computer that I assembled, personally").  The technology in use was
quite simple... Bell 103-protocol (300-baud) modems direct-dialed into
one another.  Networks (public or private), terminal concentrators,
gateways, modem-based flow control, and the sort were non-issues...
either they didn't exist at the time, or were absent in the environment
in which XMODEM was being developed and used.  The fundamental design of
the protocol was "Keep It Simple, Stupid!"

XMODEM has been implemented on _many_ systems, because it's a simple
protocol to code up and because the protocol description is in the
public domain.

The XMODEM protocol is certainly showing its age... it has been enhanced
to support larger packets (XMODEM-1k), file-description information
(YMODEM-Batch), windowing, and other goodies.  Its fundamental
orientation as an 8-bit protocol hasn't gone away, though.

Quite some time ago, folks who were living in a 7-bit environment
developed a protocol that could work reliably over data-links that were
limited to 7 bits and which were finicky about passing control
characters.  This protocol (Kermit) is still the protocol-of-choice for
transferring files in most PC-to-mainframe environments.

ZMODEM can, at least, deal with situations in which the reverse path
(receiver-to-transmitter) is not 8-bit-transparent... this covers a
large percentage of the download-lots-of-data-over-a-network situations.
This was the purpose for which it was engineered... it was designed to
permit people to download data, rapidly and effectively, over the sorts
of packet-switching nets that the people-who-paid-for-its-design were
running.  My impression is that there was less emphasis laid on its
ability to permit _uploading_ of data over these same networks;  I could
very well be wrong.  [Chuck... care to comment, if you're following this
thread?]

There are a number of proprietary protocols floating around that can
handle uploads and downloads over "unclean" and "untransparent"
datapaths.  Some of these are perhaps superior, in an engineering sense,
to the [XYZ]MODEM family and to Kermit.  However, because they're
proprietary, they have not been widely implemented and have never become
particularly popular.
-- 
Dave Platt    FIDONET:  Dave Platt on 1:204/444        VOICE: (415) 493-8805
  UUCP: ...!{ames,sun,uunet}!coherent!dplatt     DOMAIN: dplatt@coherent.com
  INTERNET:   coherent!dplatt@ames.arpa,  ...@uunet.uu.net 
  USNAIL: Coherent Thought Inc.  3350 West Bayshore #205  Palo Alto CA 94303