I don't know about you, but in my experience, modem compression (and
similar schemes) typically does a fairly poor job.
There's a fairly simple reason. This type of compression must keep
latencies from growing too much. This *really* hurts compression.
actually my experience is just the opposite ... modem compression
(usually based on LZW) does a reasonably good job ... not as good
as gzip or bz2 but close enough. and yes, one difference between
the effectiveness of these algorithms is the amount of latency/
lookahead that is needed. LZW is amazingly good for an algorithm
needing only a fixed amount of memory and one octet lookahead.
but for me the disappointing thing about modems is that they add far
more latency than you would expect given their speed. I don't think
this is the fault of the compression so much as the error correction
(I suspect that many modems rely on error correction to compensate
for marginal analog circuitry)
you'll get more connection time savings from pipelining smtp than you
will from compressing the data.
That's only true if the time is dominated by RCPT TO: handling, that is,
you're sending many small mails. When you're sending a few large mails,
pipelining is completely irrelevant, and compression is very important,
because you spend most of the time in the DATA phase anyway.
right. but even these days most messages are small. and I was assuming
that this traffic was already going over compressing modems, which would
save almost as much bandwidth as compressing smtp data.
Keith