Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Extensions API doesn't allow for selective compression #2

Open
glasser opened this issue Jan 5, 2015 · 2 comments
Open

Extensions API doesn't allow for selective compression #2

glasser opened this issue Jan 5, 2015 · 2 comments

Comments

@glasser
Copy link

glasser commented Jan 5, 2015

The permessage-deflate spec is designed to allow senders to choose not to compress all messages (eg, messages that already contain compressed binary data), but the extensions API doesn't allow senders to make this choice.

(My personal needs don't require this, but it does seems like something that users might care about.)
@glasser glasser mentioned this issue Jan 6, 2015
Closed
glasser added a commit to meteor/meteor that referenced this issue Jan 6, 2015
@glasser
Use per-message websocket compression
3cb4828 
By default, we attempt to use this for every websocket message on both
client and server.

On the server, we provide the SERVER_WEBSOCKET_COMPRESSION environment
variable to control compression. If $SERVER_WEBSOCKET_COMPRESSION is
set, then it must be valid JSON. If it represents a falsey value, then
we do not use permessage-deflate at all; otherwise, the JSON value is
used as an argument to deflate's configure method; see
https://github.com/faye/permessage-deflate-node/blob/master/README.md

We do not provide a way to use it only on some messages. The underlying
spec allows this but permessage-deflate does not; see
faye/permessage-deflate-node#2

We do not provide a mechanism to control compression parameters on the
client side.  The assumption is that the common reason to care about
compression parameters is to control server per-connection memory
usage. (The noContextTakeover configuration parameter should save some
memory and still allow for some compression, for example.)

Addresses #3007 (which will not be fixed until this change is deployed
on the package server as well).
glasser added a commit to meteor/meteor that referenced this issue Jan 6, 2015
@glasser
Use per-message websocket compression
b3b355a 
By default, we attempt to use this for every websocket message on both
client and server.

On the server, we provide the SERVER_WEBSOCKET_COMPRESSION environment
variable to control compression. If $SERVER_WEBSOCKET_COMPRESSION is
set, then it must be valid JSON. If it represents a falsey value, then
we do not use permessage-deflate at all; otherwise, the JSON value is
used as an argument to deflate's configure method; see
https://github.com/faye/permessage-deflate-node/blob/master/README.md

We do not provide a way to use it only on some messages. The underlying
spec allows this but permessage-deflate does not; see
faye/permessage-deflate-node#2

We do not provide a mechanism to control compression parameters on the
client side.  The assumption is that the common reason to care about
compression parameters is to control server per-connection memory
usage. (The noContextTakeover configuration parameter should save some
memory and still allow for some compression, for example.)

Addresses #3007 (which will not be fixed until this change is deployed
on the package server as well).
glasser added a commit to meteor/meteor that referenced this issue Jan 7, 2015
@glasser
Use per-message websocket compression
9c4c981 
By default, we attempt to use this for every websocket message on both
client and server.

On the server, we provide the SERVER_WEBSOCKET_COMPRESSION environment
variable to control compression. If $SERVER_WEBSOCKET_COMPRESSION is
set, then it must be valid JSON. If it represents a falsey value, then
we do not use permessage-deflate at all; otherwise, the JSON value is
used as an argument to deflate's configure method; see
https://github.com/faye/permessage-deflate-node/blob/master/README.md

We do not provide a way to use it only on some messages. The underlying
spec allows this but permessage-deflate does not; see
faye/permessage-deflate-node#2

We do not provide a mechanism to control compression parameters on the
client side.  The assumption is that the common reason to care about
compression parameters is to control server per-connection memory
usage. (The noContextTakeover configuration parameter should save some
memory and still allow for some compression, for example.)

Addresses #3007 (which will not be fixed until this change is deployed
on the package server as well).
glasser added a commit to meteor/meteor that referenced this issue Jan 8, 2015
@glasser
Use per-message websocket compression
67bea9c 
By default, we attempt to use this for every websocket message on both
client and server.

On the server, we provide the SERVER_WEBSOCKET_COMPRESSION environment
variable to control compression. If $SERVER_WEBSOCKET_COMPRESSION is
set, then it must be valid JSON. If it represents a falsey value, then
we do not use permessage-deflate at all; otherwise, the JSON value is
used as an argument to deflate's configure method; see
https://github.com/faye/permessage-deflate-node/blob/master/README.md

We do not provide a way to use it only on some messages. The underlying
spec allows this but permessage-deflate does not; see
faye/permessage-deflate-node#2

We do not provide a mechanism to control compression parameters on the
client side.  The assumption is that the common reason to care about
compression parameters is to control server per-connection memory
usage. (The noContextTakeover configuration parameter should save some
memory and still allow for some compression, for example.)

Addresses #3007 (which will not be fixed until this change is deployed
on the package server as well).
glasser added a commit to meteor/meteor that referenced this issue Jan 8, 2015
@glasser
Use per-message websocket compression
523f0bd 
By default, we attempt to use this for every websocket message on both
client and server.

On the server, we provide the SERVER_WEBSOCKET_COMPRESSION environment
variable to control compression. If $SERVER_WEBSOCKET_COMPRESSION is
set, then it must be valid JSON. If it represents a falsey value, then
we do not use permessage-deflate at all; otherwise, the JSON value is
used as an argument to deflate's configure method; see
https://github.com/faye/permessage-deflate-node/blob/master/README.md

We do not provide a way to use it only on some messages. The underlying
spec allows this but permessage-deflate does not; see
faye/permessage-deflate-node#2

We do not provide a mechanism to control compression parameters on the
client side.  The assumption is that the common reason to care about
compression parameters is to control server per-connection memory
usage. (The noContextTakeover configuration parameter should save some
memory and still allow for some compression, for example.)

Addresses #3007 (which will not be fixed until this change is deployed
on the package server as well).
@jcoglan
Copy link
Collaborator

jcoglan commented Apr 3, 2015

I'm parking this for the moment since I have no idea what an API should look like. No API for this exists in the browser (as far as I know), although some browsers (Opera) do skip compression on small messages where compression would actually enlarge the payload. I'm not sure how they do that; you can't compress a message and then compare the size, because that alters the state of the DEFLATE context and you must transmit the compressed payload to the other peer so it can mirror those changes.

My main concern is about surfacing extension control parameters via send() without coupling anything from websocket-extensions upwards to the extensions. My article this week sheds light on how I designed this stack, and which kinds of couplings I don't want to introduce.

@jcoglan
Copy link
Collaborator

jcoglan commented Apr 3, 2015

I'm also not sure conceptually what should be parameterised per send() call. e.g. if a peer is using context takeover, can you tell it to start a new context on a particular message? Is that safe? Can you change the window size, or level, or strategy, per message?

glasser added a commit to meteor/meteor that referenced this issue Apr 10, 2015
@glasser
Use per-message websocket compression
6a22e37 
(This is the third attempt to enable this. I believe as of
permessage-deflate 0.1.3, it works properly.)

By default, we attempt to use this for every websocket message on both
client and server.

On the server, we provide the SERVER_WEBSOCKET_COMPRESSION environment
variable to control compression. If $SERVER_WEBSOCKET_COMPRESSION is
set, then it must be valid JSON. If it represents a falsey value, then
we do not use permessage-deflate at all; otherwise, the JSON value is
used as an argument to deflate's configure method; see
https://github.com/faye/permessage-deflate-node/blob/master/README.md

We do not provide a way to use it only on some messages. The underlying
spec allows this but permessage-deflate does not; see
faye/permessage-deflate-node#2

We do not provide a mechanism to control compression parameters on the
client side.  The assumption is that the common reason to care about
compression parameters is to control server per-connection memory
usage. (The noContextTakeover configuration parameter should save some
memory and still allow for some compression, for example.)

Addresses #3007 (which will not be fixed until this change is deployed
on the package server as well).
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@jcoglan @glasser