[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:
> Hello,
>
> 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 
shortly).

For websocket protocol latencies, I added yesterday a patch that can 
watch any interesting syscalls and confirm we don't block there

http://git.libwebsockets.org/cgi-bin/cgit/libwebsockets/commit/?id=d636e35c2bc6a443ee27142f01f24a80a235dce8

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 
library.

-Andy





More information about the Libwebsockets mailing list