Luigi Pinca

And here we are again with that arrogant attitude. The point is that it's not ws fault. Any Node.js app/library that uses the asynchronous zlib deflate methods is potentially affected...

Issue should stay open, and I already said thank you for your suggestion, not sure what else should I do haha. Please explain me exactly what is ws doing wrong...

@luislobo according to the above comments, yes that's right.

Node.js does not have an official API to use inflate/deflate streams synchronously. We can't use https://nodejs.org/api/zlib.html#zlib_zlib_deflaterawsync_buffer_options as that does not work as intended for fragmented messages of if context takeover...

Yes, but where is the code that produced those results? How many deflate instances were used (we have one per socket)? How long is the event loop blocked when doing...

> 2KB: sync version takes 0.3ms and async version 3ms @rahbari can you please share your code? I did a dummy and irrelevant quick test and this is what I...

@piranna please read the full comment. That creates a new instance for each buffer, see https://github.com/nodejs/node/blob/5d210d4ac938a16d132a1433857927c5c58a8954/lib/zlib.js#L692-L706. We can't use that for fragmented messages or if context takeover is enabled.

It is done at the frame/fragment level, yes.

The option to enable compression based on the message byte size is available since version 2.0.0, see https://github.com/websockets/ws/blob/1e78aba9b9b29407517ec7ba1da97427c1678e5c/doc/ws.md#new-websocketserveroptions-callback > `threshold` {Number} Payloads smaller than this will not be compressed. Defaults...

I noticed that there is [`Zlib.prototype._processChunk()`](https://github.com/nodejs/node/blob/e10290cc67edd5118d4d72efa5336dc2ba652d05/lib/zlib.js#L451-L457). The API is "private" and undocumented but it seems to work and it is used in user land so it will probably not go...