[Libwebsockets] Zlib and binary data

"Andy Green (林安廸)" andy at warmcat.com
Fri Jan 18 06:16:17 CET 2013


On 18/01/13 13:05, the mail apparently from Gregory Junker included:
> (resending to cc the list as well)
>
>
> On Thu, Jan 17, 2013 at 8:51 PM, Gregory Junker <ggjunker at gmail.com
> <mailto:ggjunker at gmail.com>> wrote:
>
>     Hi Andy
>
>      From JavaScript, I don't -- the clients send requests to the server
>     in text form, which parses them and responds with either text or
>     binary data, depending on the type of data requested. So this would
>     be originating on the server and failing when going to the client.
>
>     It may help that the server (when I turn on all logging options)
>     says (right before it disconnects the client)
>
>     [1358484560:3958] DEBUG: deflate-frame ext TX did realloc to 4096
>     [1358484560:3958] DEBUG: deflate-frame ext TX did realloc to 4096
>     [1358484560:3965] DEBUG: deflate-frame ext TX did realloc to 4096
>     [1358484560:3973] DEBUG: deflate-frame ext TX did realloc to 4096
>     [1358484560:3988] HEADER: zlib out buffer tried to exceed max
>     allowed of 65536

Ah right... there has to be a limit somewhere otherwise this code will 
exhaust the server memory; a client can send it compressed states that 
blow up into 4G of 0x00 or whatever and kill your server.

You can configure this limit from ./configure, eg

./configure CFLAGS="-DLWS_MAX_ZLIB_CONN_BUFFER=262144"

but since you're running the server you will need a policy about what's 
the biggest thing you can legitimately be sent for decode in one chunk.

-Andy

>     [1358484560:4003] PARSER: written 43398 bytes to client
>     [1358484560:4012] DEBUG: libwebsocket_close_and_free_
>     session: just_kill_connection
>     [1358484560:4012] INFO: remove_wsi_socket_from_fds: wsi=0x12f1af0,
>     sock=7, fds pos=3
>     [1358484560:4012] DEBUG: calling back CLOSED
>
>     and on the client, it says
>
>     [1358484560:4009] ERR: zlib error inflate -3: invalid stored block
>     lengths
>     [1358484560:4009] HEADER: Extension 'deflate-frame' failed to handle
>     payload!
>     [1358484560:4009] DEBUG: libwebsocket_close_and_free_
>     session: just_kill_connection
>     [1358484560:4009] INFO: remove_wsi_socket_from_fds: wsi=0x140aba0,
>     sock=5, fds pos=1
>     [1358484560:4009] DEBUG: calling back CLOSED
>     [1358484560:4011] HEADER: zlibs destructed
>
>
>
>     Greg
>
>
>
>     On Thu, Jan 17, 2013 at 7:17 PM, "Andy Green (林安廸)"
>     <andy at warmcat.com <mailto:andy at warmcat.com>> wrote:
>
>         On 18/01/13 11:14, the mail apparently from Gregory Junker included:
>
>             Hi
>
>             There may be an issue with compressing binary data in the
>             current HEAD.
>             Both my JS (Chrome 19) and LWS client complain that they
>             cannot inflate
>             the data. This worked fine in the current tarball
>             (v1.0-chrome25-firefox17). I'll dig in and see what I can
>             find but
>             wondered if anyone else had problems with this?
>
>
>         The test apps only get TEXT frames coming, so actually this
>         doesn't get tested.
>
>         Can you let me know how you generate binary frames in the
>         Javascript? I'll adapt the test stuff to cover it so I won't
>         miss breaking it.
>
>         -Andy
>
>
>




More information about the Libwebsockets mailing list