Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!rutgers!dptg!att!chinet!les
From: les@chinet.chi.il.us (Leslie Mikesell)
Newsgroups: comp.dcom.modems
Subject: Re: MNP vs. uucp 'g' - my solution
Message-ID: <9694@chinet.chi.il.us>
Date: 28 Sep 89 17:00:41 GMT
References: <125285@sun.Eng.Sun.COM> <1989Sep27.211826.17398@eci386.uucp>
Reply-To: les@chinet.chi.il.us (Leslie Mikesell)
Organization: Chinet - Public Access Unix
Lines: 39

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?

I though someone had determined that at least on one machine the host
overhead of compression was less than the overhead of writing the
uncompressed data out the port.  This would depend on how much compression
you can achieve as well as the specific hardware, of course.  Anyone
have figures for different machines?

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

Is the source for 'T' available?

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

Sorry, but if I xfer compressed files, I'd prefer for them to stay that
way until I want them uncompressed.  A better way would be to add a
"data" type field to the packet header and do whatever is appropriate.
Perhaps when we get STREAMS tty's we can just push an appropriate
protocol on both ends of the link and let uucico use the 'e' protocol.
The advantage would be that *any* session could have compression/
error correction, not just a single program, and it could be done at
the point where it would help the most CPU-wise assuming it really is
cheaper to compress than to send out a port.

Les Mikesell