[Libwebsockets] deflate/inflate streams
"Andy Green (林安廸)"
andy at warmcat.com
Thu Jan 31 01:03:01 CET 2013
On 31/01/13 07:45, the mail apparently from Jandhyala, Anu included:
> I picked up the support */libwebsockets-1.0-chrome25-firefox17/*
> version of libwebsockets today. First of all, it is fantastic, thank you
> – I did not need to define my own extension callback-hacks for
> webkit-deflate-frame (in the earlier version this hack failed for
> receive, but worked for sending).
> This current version works seamlessly with firefox, IOS and chrome. I
> have ran it in the debugger to review the data prior to deflate/inflate.
> It shows ~50% reduction in message bytes. Tomorrow I will stress test
> for latencies.
> But we think the compression time is so small, we will only benefit (our
> base message are in XML!!)
> Kudos, Andy Green!
Thanks... it's also due to other contributors too ^^
If you are interested in latency tracking, we have been stressing it
with ab for http "from outside", Edwin van den Oetelaar found it was
necessary to improve servicing pending connections at the listen socket
if some connections were not to get very long latencies, which was done
after the 1.0 release. (I will make an soname bump and 1.1 release
For websocket protocol latencies, I added yesterday a patch that can
watch any interesting syscalls and confirm we don't block there
For normal connections I think it's OK and we shouldn't block, but SSL
requires more care which should also have been done now.
Otherwise I didn't make any "ab"-style latency testing "from outside"
using websocket protocol yet. Any results will be interesting.
If you have a lot of activity in and out, there were also fixes after
1.0 in the rx flow control api side. If clients are too slow taking
what you need to give them, a backpressure mechanism is needed to
indicate this to the data source that it must slow down or stall
sending. The lws_mirror protocol in the test server in HEAD shows how
to do that properly now.
There's also a lot of improvements around easy daemonization support and
extra configure options to restrict the build to server or client only.
For those reasons it might be worth trying the HEAD version of the
More information about the Libwebsockets