Xref: utzoo comp.sys.ibm.pc:25490 comp.dcom.modems:3486 comp.mail.uucp:2806
Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!ucbvax!agate!helios.ee.lbl.gov!ncis.llnl.gov!lll-winken!lll-lcc!pyramid!csg
From: csg@pyramid.pyramid.com (Carl S. Gutekunst)
Newsgroups: comp.sys.ibm.pc,comp.dcom.modems,comp.mail.uucp
Subject: Re: Major Modem Woe: THE 9600B modem no good for interactive use
Message-ID: <61122@pyramid.pyramid.com>
Date: 2 Mar 89 04:18:31 GMT
References: <60827@pyramid.pyramid.com> <13275@steinmetz.ge.com>
Organization: Pyramid Technology Corp., Mountain View, CA
Lines: 22

>In article <60827@pyramid.pyramid.com> csg@pyramid.UUCP (Carl S. Gutekunst) writes:
>The better solution for modems like the HST is a streaming protocol, like
>'f' but more robust and less overhead. I keep toying with this idea, as
>does Rick Adams, but we never get around to an implementation.

In article <13275@steinmetz.ge.com> davidsen@crdos1.UUCP (bill davidsen) writes:
>  One existing protocol which does very well at this is zmodem. Rather
>than invent a new protocol, perhaps this could be added.

This is exacly what Rick and I were originally planning. After some study of
the zmodem protocol, however, I've decided against it. The zmodem protocol
is strictly for practically error free channels like X.25; error recovery
is expensive. It also requires 8-bit transparency.

What I want -- and I have the groundwork of a design -- is a streaming
protocol that provides fairly cheap error correction, and is thus suitable
over a variety of media, including standard non-intelligent modems. The
protocol would also have to be extensible, so new features could be added
without breaking existing installations. One place it would not work is
really trashy dialup lines; but that's what we have 'g' protocol for. :-)

<csg>