[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [hybi] Multiplexing extension spec draft 02



On Mon, Feb 6, 2012 at 4:28 AM, Arman Djusupov <arman at noemax.com> 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

Note Well: Messages sent to this mailing list are the opinions of the senders and do not imply endorsement by the IETF.