[Libwebsockets] Deflate Frame Extension Question
"Andy Green (林安廸)"
andy at warmcat.com
Wed Feb 13 04:42:04 CET 2013
On 13/02/13 05:32, the mail apparently from Larry Hayes included:
> I am using v1.0 of the library.
> Configure Options: --disable-static --enable-shared --enable-openssl
> --enable-libcrypto --with-client-cert-dir=xxxx
> This is a NON-SSL web socket connection.
> I create both the Client and Server to support the
> My question is should deflate-frame extension support more than the
> MAX_USER_RX_BUFFER size of data?
> For Example:
> Client calls libwebsocket_write with a buffer of 4119, of that UserData
> is 4097. I see this gets compressed to 206 bytes.
> Which the server receives, 206 bytes, but it inflates to 4096 bytes of
> user data.
For the reception / inflate side, the MAX_USER_RX_BUFFER (this got
removed after 1.0, you can set it per-protocol in the protocol struct
now) limit only applies to the compressed frame content.
So your compressed payload of 206 is well below the default limit of 4096.
The inflated data gets its own malloc'd buffer with a different max size
restriction, LWS_MAX_ZLIB_CONN_BUFFER, 64KBytes by default. So there's
no problem dealing with 4097 bytes of data there either.
That inflated buffer and the length are passed directly then to the user
I also studied the client send side and couldn't see how that could go
> libwebsockets_remaining_packet_payload tells me no more bytes. But I am
> missing 1 byte of data.
That's telling you about the compressed data in the actual frame... and
indeed the receiving peer had gotten all 206 bytes of that.
deflate-frame extension should only deliver atomic frames, so there
should never be any left over, so 0 is correct from that POV too.
> The strange thing, if the server goes to close the connection, the
> client will write 2 more bytes before the CALLBACK_CLOSED is called.
> Anybody have an idea what is going on here?
Those 2 bytes sound like the 2-byte reason code in the CLOSE frame, if
that's the case they're not related to your main problem.
I attach a test patch I used to try to reproduce the problem, I did not
find any trouble on HEAD receiving a 4097 byte packet at the server
through deflate-frame, when the max normal frame size was set to 4096.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 12741 bytes
Desc: not available
More information about the Libwebsockets