Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!cs.utexas.edu!execu!sequoia!texbell!texsun!newstop!sun!datsun!shannon
From: shannon%datsun@Sun.COM (Bill Shannon)
Newsgroups: comp.dcom.modems
Subject: Re: MNP vs. uucp 'g' - my solution
Message-ID: <126342@sun.Eng.Sun.COM>
Date: 14 Oct 89 07:25:09 GMT
References: <125285@sun.Eng.Sun.COM> <1989Sep27.211826.17398@eci386.uucp>
Sender: news@sun.Eng.Sun.COM
Lines: 47

In article <1989Sep27.211826.17398@eci386.uucp>, clewis@eci386.uucp (Chris Lewis) writes:
> From the point of view of processor performance, why didn't you simply 
> use (or implement) "f" protocol?  Then you could use MNP compression
> without using any host overhead, and not worry about end-to-end-to-end
> ACK delays?  Not to mention being able to talk to other "f" implementations
> (eg: stock 4.3 BSD UUCP).

I have 'f'.  the problem with 'f' is that it expands the data before
handing it to the modem to compress.  for simple text, 'f' is not too
bad.  with MNP 5 I was able to get about 1200 cps.  with binaries it's
much worse, getting about 700 cps.

> 			 Having checksumming ACK's is only of interest
> when the end-to-end link isn't error free, so if you do have error
> correction and reliable host-modem links (eg: working hardware flow
> control), why bother? (except of course for a single one at the end of
> each file, or perhaps every (baud-dependent) number of kilobytes/number
> of transmission seconds.).

the hardware flow control I have is uni-directional; the modem can tell me
when to stop but not vice versa.  even if it were bi-directional, I'm not
convinced there aren't other reasons that the kernel might drop data.
this might be rare, but is it rare enough that you want to trust your
files to it?

> T'would even work if you had to multi-hop thru X.25 lines (ie: telenet 
> supported dialup MNP modems).  And, of course, you could *greatly* speed 
> "f" up by eliminating the 7-bit bashing for binary files.

ah, but then it wouldn't be 'f', would it?

> I have a tendency to think that UUCP protocol should vary *only* to take into
> account transmission medium, not additional bells and whistles.  As another
> has pointed out, encryption/compression should really be another layer.

if uucp were a real networking system, I'd agree with you.  uucp is a hack,
long past its prime.  this additional hack may give it a little more life,
but rather than really making it better we should be building a replacement.

> Having uucico *automatically* invoke [en|de]cryption and/or [de]compression
> *prior* to sending or *post* receiving sounds like a better idea than
> yet another transport protocol.  A brute force mechanism would be for
> uucico to automatically compress anything going outwards, and detecting
> ".Z" suffixes and attempting to decompress on incoming.

this would cause it to uncompress things that started out compressed, probably
not what most people have in mind.