Path: utzoo!attcan!lsuc!eci386!clewis
From: clewis@eci386.uucp (Chris Lewis)
Newsgroups: comp.dcom.modems
Subject: Re: MNP vs. uucp 'g' - my solution
Message-ID: <1989Sep27.211826.17398@eci386.uucp>
Date: 27 Sep 89 21:18:26 GMT
References: <125285@sun.Eng.Sun.COM>
Reply-To: clewis@eci386.UUCP (Chris Lewis)
Organization: R. H. Lathwell Associates: Elegant Communications, Inc.
Lines: 39

In article <125285@sun.Eng.Sun.COM> shannon%datsun@Sun.COM (Bill Shannon) writes:
>As "everyone knows", MNP and uucp's 'g' protocol just don't get along.
>So, I decided there must be a better way.  What does MNP give you?
>MNP 5 gives you reliable data transfer (at least from modem to modem
>if not from program to program) and data compression....

>So, what I ended up doing is writing a new uucp protocol based on
>the 'g' protocol but including automatic compression of the data.
>I call the new protocol 'c'.

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).  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.).

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.

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.
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.
-- 
He's a consultant:             | Chris Lewis, Elegant Communications Inc.
Lend him your watch            | UUCP {uunet!attcan,utzoo}!lsuc!eci386!clewis
and he'll tell you the time.   | Moderator of the Ferret mailing list.
   Don Munroe, Cosmic Commander|