[Libwebsockets] Deflate Frame Extension Question
andy at warmcat.com
Wed Feb 13 23:24:30 CET 2013
I guess so... however that while loop behavior with many reallocs per frame for payload data is objectionable, I have my eye on removing the looping for a different scheme.
It's probably better to work with the latest release fwiw, it's certainly easier to take care of bugs there.
Larry Hayes <lhayesg at gmail.com> wrote:
>Thanks for the time looking into it.
>I tried v1.1 this morning and it works.
>I am assuming this is a v1.0 issue.
>I do not see LWS_MAX_ZLIB_CONN_BUFFER defined in 1.0.
>I did notice in v1.0 there is no while loop around the inflate as there
>On Tue, Feb 12, 2013 at 9:42 PM, "Andy Green (林安廸)"
><andy at warmcat.com>wrote:
>> 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-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
>>> is 4097. I see this gets compressed to 206 bytes.
>>> Which the server receives, 206 bytes, but it inflates to 4096 bytes
>>> user data.
>> For the reception / inflate side, the MAX_USER_RX_BUFFER (this got
>> after 1.0, you can set it per-protocol in the protocol struct now)
>> only applies to the compressed frame content.
>> So your compressed payload of 206 is well below the default limit of
>> The inflated data gets its own malloc'd buffer with a different max
>> restriction, LWS_MAX_ZLIB_CONN_BUFFER, 64KBytes by default. So
>> problem dealing with 4097 bytes of data there either.
>> That inflated buffer and the length are passed directly then to the
>> callback untouched.
>> I also studied the client send side and couldn't see how that could
>> wrong either.
>> libwebsockets_remaining_**packet_payload tells me no more bytes. But
>>> missing 1 byte of data.
>> That's telling you about the compressed data in the actual frame...
>> indeed the receiving peer had gotten all 206 bytes of that.
>> deflate-frame extension should only deliver atomic frames, so there
>> 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,
>> 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
>> find any trouble on HEAD receiving a 4097 byte packet at the server
>> deflate-frame, when the max normal frame size was set to 4096.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Libwebsockets