Re: [hybi] Multiplexing extension spec draft 02

[John Tamplin <[e-mail]>]

On Mon, Feb 6, 2012 at 4:28 AM, Arman Djusupov <[e-mail]> wrote:

> “Any compression extensions negotiated apply only to the channel they are
> negotiated on -- therefore, any compression extension in the initial
> handshake applies only to logical channel 1.  If WebSocket payload data is
> masked by a per-frame key, such masking is applied to frames for each
> logical channel separately.”
>
> **
>
> ** **
>
> Providing the ability to specify a compression extension per sub-channel
> greatly increases the complexity of the implementation. I believe it would
> be simpler if the compressed logical channels were grouped in a compressed
> connection, while the logical channels that do not need compression were
> grouped in a separate non-compressed connection. Maintaining a DEFLATE
> window per sub-channel is very expensive, doing so could eliminate all the
> benefits of multiplexing.
>
> **
>
> But if you believe that there is a strong use case for per channel
> compression, then we could support both options (common compression and per
> channel) by having logical channel 1 perform its own handshake rather than
> using the initial handshake for it.
>
The rationale was that an intermediate MUX would otherwise have to
decompress inbound channels and recompress the combined channel, which
seems a waste.  I agree that in the browser case, where the individual
channels never exist separately, it would be better to do compression only
on the physical channel.

So, it seems like we need to have options for either behavior.

-- 
John A. Tamplin
Software Engineer (GWT), Google