Re: [hybi] deflate-stream and masking

"Arman Djusupov" <> Mon, 20 June 2011 14:52 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id B08A311E808E for <>; Mon, 20 Jun 2011 07:52:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id eD7is4ASzg1d for <>; Mon, 20 Jun 2011 07:52:23 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id B6EF111E80BE for <>; Mon, 20 Jun 2011 07:52:23 -0700 (PDT)
Received: from ArmanLaptop by (IceWarp 9.4.1) with ASMTP (SSL) id DUU40622; Mon, 20 Jun 2011 17:52:22 +0300
From: "Arman Djusupov" <>
To: "'Bob Gezelter'" <>, <>
References: <>
In-Reply-To: <>
Date: Mon, 20 Jun 2011 17:51:17 +0300
Message-ID: <002a01cc2f59$878be970$96a3bc50$>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQKAhv+d7vI6B6bMaZMky64pplNS/pNdpCuA
Content-Language: en-us
Subject: Re: [hybi] deflate-stream and masking
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Server-Initiated HTTP <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 20 Jun 2011 14:52:28 -0000

I don't think we should take the "mux" extension into account when
discussing the deflate-stream extension. Compressing "mux" channels is a
special case that should be covered by the "mux" extension specification. 

Combining all multiplexed streams into a single deflate channel is a good
idea because it is actually very cheap memory wise, otherwise compressing
each sub-channel with a separate DEFLATE stream could end up being very
expensive memory wise. You can expect over 200KB of memory needed per each
sub-channel, this basically kills the whole purpose of sub-channels which
are actually supposed to decrease the load on the server side. Two-three
thousands of compressed sub-channels would be enough to put the server on
its knees.

I consider the deflate-stream extension just as basic transport compression
which is offered "out of the box" by a WebSocket implementation,
irrespective of whether it supports multiplexing or not. 

With best regards,

> -----Original Message-----
> From: [] On Behalf Of
> Bob Gezelter
> Sent: Monday, June 20, 2011 5:09 PM
> To:
> Subject: Re: [hybi] deflate-stream and masking
> As I have noted before, Greg's observation about the interaction of
> and compression is undoubtedly correct.
> To be effective, compression must be done when the steam of data is most
> strongly correlated. In short, this should be BEFORE multiplexing,
> and masking. Data on different multiplexed streams cannot be assumed to
> be correlated, and correlation is needed for effective compression.
> Encrypting or masking data to create randomness similarly negates the
> effectiveness of compression.
> When dealing with correlated data (e.g., the contents of a printable file,
> even a PostScript file), I have seen compression factors of 100:1. If the
> had first been encrypted, or randomly masked, the ratio would have been
> likely 2:1 (what is often achieved by disk or tape compression
facilities), or
> even less than 1:1 (worst case).
> Compression should be done within each sub-stream (assuming
> multiplexing, which is not in the current specification), and in any
> before encryption and masking.
> - Bob Gezelter,
> _______________________________________________
> hybi mailing list