[Libwebsockets] Deflate Frame Extension Question

Andy Green andy at warmcat.com
Wed Feb 13 23:24:30 CET 2013


Hi -

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.

-Andy

Larry Hayes <lhayesg at gmail.com> wrote:

>Andy,
>
>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
>is
>in v1.1
>
>Larry
>
>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-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
>>> libwebsocket_internal_**extensions.
>>>
>>> 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
>> callback untouched.
>>
>> I also studied the client send side and couldn't see how that could
>go
>> wrong either.
>>
>>
>>  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.
>>
>> -Andy
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://libwebsockets.org/pipermail/libwebsockets/attachments/20130214/549c92eb/attachment-0001.html>


More information about the Libwebsockets mailing list