Re: [hybi] Multiplexing extension spec draft 02

["Arman Djusupov" <[e-mail]>]

Hello Takeshi,

 

"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.

 

With best regards,

Arman

 

 

From: [e-mail] [mailto:[e-mail]] On Behalf Of
Takeshi Yoshino
Sent: Friday, January 27, 2012 6:55 AM
To: [e-mail]
Subject: [hybi] Multiplexing extension spec draft 02

 

http://tools.ietf.org/html/draft-tamplin-hybi-google-mux-02

Diff http://tools.ietf.org/rfcdiff?url2=draft-tamplin-hybi-google-mux-02.txt


 

No semantic change.

 

- some typo fixes

- named "control channel" explicitly

- updated reference to point RFC

- added some vertical space for readability