[Libwebsockets] Deflate Frame Extension Question

Larry Hayes lhayesg at gmail.com
Wed Feb 13 18:57:40 CET 2013


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/20130213/2f54a7af/attachment-0001.html>


More information about the Libwebsockets mailing list