CODEWITHSUNDEEP
node.jswebsocketzlibpakopermessagedeflate
Anonymous
Anonymous

Reputation: 4632

The difference between node.js ws permessagedeflate zlib decompression and that of pako?

I have a node.js ws websocket that receives compressed data.

The docs are very shallow about the inflate mechanism but from reading through source files it is clearly in-built and should be activated automatically depending on the type of received data.

However, when attaching ws.on('message',function(data){}) event it returns a < Buffer >

Since I knew that those streams have been previously inflated with Pako, I have tried to installed it, and it actually worked using the following code:

pako.inflate(data, { to: 'string' })

From what I understand both modules use zlib decompression but ws module somehow misses it.

Could someone give a reasonable explanation or at least a hypothesis why?

Upvotes: 0

Views: 1774

Answers (1)

robertklep
robertklep

Reputation: 203359

What ws supports is a particular WebSocket extension called "permessage-deflate".

This extension is documented in RFC 7692, and because it's an extension to the protocol, it's something that the underlying WS protocol implementation (server and client) needs to support (there's a handshake procedure involved in which the client and the server try to determine if the other side supports it, and the sender sets a particular frame flag to notify the receiver that the frame was compressed).

Once it's activated, it's relatively transparent, and frame (de)compression is handled automatically by the protocol driver.

In your case, it sounds like there's an explicit compression/decompression stage added on top of WebSocket, where the sender explicitly compresses the data (not the WS frame itself) and the receiver needs to decompress it explicitly, which is basically what you have already found out: the received message is a (compressed) buffer, and you need to explicitly decompress it.

So it's not that ws has missed anything, it's just that the (de)compression is taking place in the layer above the raw WS frames (which, if the "permessage-deflate" extension would be active, could result in the data being compressed and decompressed twice: once by the user code, once by the protocol code).

Upvotes: 2

Related Questions