Compression Support?

[Demostrike]

This is not so much of a bug and more a request/question.

Is there planned support for the websocket extension on per-message deflate compression? It's in the current socket.io JS library now, and I've personally seen some good reductions in traffic based on it.

Thanks

[akuznetsov-gridgain]

We also interested in compression. JS client has Socket#compress(v:Boolean):Socket How about JavaClient?

[chrstnwhlrt]

I'm interested in compression in android as well, the js doc says:

Socket#compress(v:Boolean):Socket Sets a modifier for a subsequent event emission that the event data will only be compressed if the value is true. Defaults to true when you don't call the method.

The compression on js is event activated by default. Should'nt be to hard to implement for the java client or am I missing something?

[efkan]

+1 for compression support in Java

[nva]

I also need this feature!

[jongha]

+1 plz.

[djlitvak]

+1

[efkan]

It seems a bit difficult to adding compress feature to this repo.

Because we need a solution that must be also touched to engine.io-client-java and the solution must perform compressing and decompressing process unlike JavaScript library of Socket.io.

If I'm right, Socket.io libraries at JS side just check and set 'Content-Encoding': 'gzip' and 'Accept-Encoding': 'gzip, deflate' headers.

And browsers unzip the zipped data automatically.

In fact I've intended to try to do these works but I could not find answers of my some questions.

Now, I think to make gzip operations manually at every socket request. So, zip the data firstly then send the data over the socket connection. And then unzip the compressed data on the server side. And of course make vice versa too..

[efkan]

And I guess, if the header which I mentioned above have been added on Transport event in Java side, Node.js server decompress and compress data automatically. Then you needs to compress and decompress data only on Java side. But I would not implement it with this way because of it prevents the readability of the app.

[nkzawa]

As a solution, we can replace okhttp with nv-websocket-client but I'm still not sure if it's better. I rather hope the compression is supported by okhttp.

This is awesome PR about that: https://github.com/socketio/engine.io-client-java/pull/59

[b95505017]

Track in https://github.com/square/okhttp/issues/1733

[b95505017]

I would recommend that we should stick with okhttp. there are lots of benefits we could borrow from okhttp in the future, not only websocket stuff.

[akuznetsov-gridgain]

Hi,

As we have #59 and #85 Could we have a kind of reference implementation of Call.Factory and WebSocket.Factory but based on nv-websocket-client? It could be a placed in separate sub project for example?

[nkzawa]

@akuznetsov-gridgain that seems awesome idea.

[akuznetsov-gridgain]

@nkzawa, Could you implement this? I can try to contribute, but I need a kind of initial guide lines where to start (some draft description). Where to inject and what interfaces / classes to implement.

[mjansing]

+1 for compression support.

[mjansing]

@nkzawa: Is there a plan to support compression in the future?

[pranishres]

Hello has this compression feature been added?

[mjansing]

Any updates on this issue?

[darrachequesne]

Update:

The OkHttp WebSocket now supports permessage-deflate compression: https://square.github.io/okhttp/changelogs/changelog_4x/#version-450-rc1

We will upgrade to OkHttp 4.x in next major version, but until then you can provide a 4.x client (which is API compatible):

IO.Options options = new IO.Options();

OkHttpClient client = new OkHttpClient.Builder()
        .readTimeout(1, TimeUnit.MINUTES)
        .build();

options.callFactory = (Call.Factory) client;
options.webSocketFactory = (WebSocket.Factory) client;

Socket socket = IO.socket(URI.create("http://localhost:3000"), options);