On Thu, 2002-03-14 at 13:35, Bruce Momjian wrote: > Greg Copeland wrote: > > Checking application/pgp-signature: FAILURE > -- Start of PGP signed section. > > Well, it occurred to me that if a large result set were to be identified > > before transport between a client and server, a significant amount of > > bandwidth may be saved by using a moderate level of compression. > > Especially with something like result sets, which I tend to believe may > > lend it self well toward compression. > > > > Unlike FTP which may be transferring (and often is) previously > > compressed data, raw result sets being transfered between the server and > > a remote client, IMOHO, would tend to compress rather well as I doubt > > much of it would be true random data. > > > > I should have said compressing the HTTP protocol, not FTP. > > > This may be of value for users with low bandwidth connectivity to their > > servers or where bandwidth may already be at a premium. > > But don't slow links do the compression themselves, like PPP over a > modem?
Yes and no. Modem compression doesn't understand the nature of the data that is actually flowing through it. As a result, a modem is going to speed an equal amount of time trying to compress the PPP/IP/NETBEUI protocols as it does trying to compress the data contained within those protocol envelopes. Furthermore, modems tend to have a very limited amount of time to even attempt to compress, combined with the fact that they have very limited buffer space, usually limits its ability to provide effective compression. Because of these issues, it not uncommon for a modem to actually yield a larger compressed block than was the input. I'd also like to point out that there are also other low speed connections available which are in use which do not make use of modems as well as modems which do not support compression (long haul modems for example). As for your specific example of HTTP versus FTP, I would also like to point out that it is becoming more and more common for gzip'd data to be transported within the HTTP protocol whereby each end is explicitly aware of the compression taking place on the link with knowledge of what to do with it. Also, believe it or not, one of the common uses of SSH is to provide session compression. It is not unheard of for people to disable the encryption to simply use it for a compression tunnel which also provides for modest session obscurantism. Greg
signature.asc
Description: This is a digitally signed message part
