Newsgroups: comp.protocols.tcp-ip
Path: utzoo!utgpu!cunews!hobbit.gandalf.ca!dcarr
From: dcarr@hobbit.gandalf.ca (Dave Carr)
Subject: Re: Message compression
Message-ID: <1991Apr5.142041.26772@hobbit.gandalf.ca>
Organization: Gandalf Data Ltd.
References: <9104031437.AA14650@saturn.acc.com> <SOLENSKY.91Apr4114120@animal.clearpoint.com> <1991Apr4.180239.12442@zoo.toronto.edu>
Distribution: na
Date: Fri, 5 Apr 1991 14:20:41 GMT
Lines: 33

In <1991Apr4.180239.12442@zoo.toronto.edu> henry@zoo.toronto.edu (Henry Spencer) writes:

>In article <SOLENSKY.91Apr4114120@animal.clearpoint.com> solensky@animal.clearpoint.com (Frank T. Solensky) writes:
>>One of the problems with a number of data compression algorithms
>>(eg: Lempel-Ziv encoding, the one used by the Unix 'compress' command)
>>is that they need to be able to look at the entire data stream before
>>being able to compress any part of it...

>Telebit would be very surprised to hear this; all their modems do
>Lempel-Ziv compression on the fly.  No, LZ does *not* need to look at
>the entire data stream before being able to compress any part of it.
>-- 
I agree with Henry.  LZW type algorithms can me made to adapt very quickly
by adjusting the number of characters learned after each match.  For example,
V.42 bis data compression has the number of characters learned as a settable
parameter (N8 I believe).

As for speed, LZW can be made very fast.  After all, it was designed with 
disk controller applications. 

The main problem with LZW is expanding uncompressable (or precompressed) data.
Again, this is addressed with V.42 bis (but not with standard LZW).

If the compressor can handle the uncompressable cases without expansion (or
minimize the expansion), then TCPIP compression is a winning solution.

Couple this with Van Jacobson's header compression, (or better the one which we 
will soon debut) and you can get substantial compression.  I won't quote 
compression rates and spoil the marketting peoples fun.

BTW Henry, does Telebit use LZW, LZSS, or LZH ?
 

