Copression
It's a possible to compress traffic between server and client while server returns query result?
It's a very actually for dial-up users.
What is solution?
Stanislaw Tristan wrote:
It's a possible to compress traffic between server and client while server returns query result?
It's a very actually for dial-up users.
What is solution?
No, unless SSL compresses automatically.
--
Bruce Momjian | http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073
Bruce Momjian wrote:
Stanislaw Tristan wrote:
It's a possible to compress traffic between server and client while server returns query result?
There are a couple of solutions.
1. Mammoth PostgreSQL supports this for libpq, and jdbc based clients.
2. You can use a web services model that uses something like mod_deflate
3. You can use redirection with SSH
Sincerely,
Joshua D. Drake
It's a very actually for dial-up users.
What is solution?No, unless SSL compresses automatically.
--
Command Prompt, Inc., home of Mammoth PostgreSQL - S/ODBC and S/JDBC
Postgresql support, programming shared hosting and dedicated hosting.
+1-503-667-4564 - jd@commandprompt.com - http://www.commandprompt.com
PostgreSQL Replicator -- production quality replication for PostgreSQL
Stanislaw Tristan wrote:
It's a possible to compress traffic between server and client while server returns query result?
It's a very actually for dial-up users.
What is solution?
You could use an SSH tunnel with compression to achieve this.
-Neil
On Mon, 21 Mar 2005 02:50 pm, Bruce Momjian wrote:
Stanislaw Tristan wrote:
It's a possible to compress traffic between server and client while server returns query result?
It's a very actually for dial-up users.
What is solution?
There is always the possibility of using SSH to tunnel the connection. You get encryption and compression.
Bruce Momjian <pgman@candle.pha.pa.us> writes:
Bruce Momjian <pgman@candle.pha.pa.us> writes:
Stanislaw Tristan wrote:
It's a possible to compress traffic between server and client while server returns query result?
It's a very actually for dial-up users.
What is solution?No, unless SSL compresses automatically.
Without checking the source, I'll bet it does.
Any good encryption system should compress first.
--
greg
FWIW: If you use an stunnel or ssh connection of some sort, merely for
compression and not security, the ARCFOUR encryption algorithm appears
to have the lowest overhead & fastest throughput. Benchmarked it once
for exactly this purpose.
Show quoted text
It's a possible to compress traffic between server and client while server returns query result?
It's a very actually for dial-up users.
What is solution?No, unless SSL compresses automatically.
Without checking the source, I'll bet it does.
Any good encryption system should compress first.
On Mon, Mar 21, 2005 at 12:45:21PM -0500, Greg Stark wrote:
Bruce Momjian <pgman@candle.pha.pa.us> writes:
No, unless SSL compresses automatically.
Without checking the source, I'll bet it does.
Any good encryption system should compress first.
I just ran some tests and it doesn't look like OpenSSL does compression
by default, at least not with my setup (PostgreSQL 8.0.1, FreeBSD
4.11-STABLE, OpenSSL 0.9.7d from the FreeBSD source tree). Here's
what I did:
CREATE TABLE foo (t text);
INSERT INTO foo VALUES (repeat('x', 1000));
SELECT * FROM foo;
I'm assuming that the 1000 x's could be compressed to a much shorter
sequence. Here are tcpdumps of the SELECT over various connection
types:
Non-SSL PostgreSQL connection:
127.0.0.1.2521 > 127.0.0.1.5480: P 76:100(24) ack 262 win 57344
127.0.0.1.5480 > 127.0.0.1.2521: P 262:1318(1056) ack 100 win 57344
SSL PostgreSQL connection (cipher: DHE-RSA-AES256-SHA, bits: 256)
127.0.0.1.1459 > 127.0.0.1.5480: P 1372:1462(90) ack 2540 win 57344
127.0.0.1.5480 > 127.0.0.1.1459: P 2540:3670(1130) ack 1462 win 57344
Non-SSL PostgreSQL connection over uncompressed SSH tunnel:
127.0.0.1.3165 > 127.0.0.1.22: P 4480:4544(64) ack 5728 win 57344
127.0.0.1.22 > 127.0.0.1.3165: P 5728:6824(1096) ack 4544 win 57344
Non-SSL PostgreSQL connection over compressed SSH tunnel (compression
level 6):
127.0.0.1.3767 > 127.0.0.1.22: P 3632:3688(56) ack 5104 win 57344
127.0.0.1.22 > 127.0.0.1.3767: P 5104:5192(88) ack 3688 win 57344
Only the last case, a PostgreSQL connection over a compressed SSH
tunnel, showed any compression in the response.
It looks like OpenSSL supports compression but the application has
to enable it:
http://www.openssl.org/docs/ssl/SSL_COMP_add_compression_method.html
--
Michael Fuhr
http://www.fuhr.org/~mfuhr/
On 3/20/2005 10:50 PM, Bruce Momjian wrote:
Stanislaw Tristan wrote:
It's a possible to compress traffic between server and client while server returns query result?
It's a very actually for dial-up users.
What is solution?No, unless SSL compresses automatically.
You can use ssh port forwarding with compression. Works quite well.
Jan
--
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#================================================== JanWieck@Yahoo.com #