[Libwebsockets] FYI: qpid-dispatch project now has websocket integration using libwebsockets

Andy Green andy at warmcat.com
Thu Dec 1 00:42:11 CET 2016

On December 1, 2016 7:26:20 AM GMT+08:00, Alan Conway <aconway at redhat.com> wrote:
>Tunneling AMQP over WebSockets, initially so that a JavaScript
>management client can connect directly to a qpid dispatch router
>instead of via a websocket proxy. I plan to serve the javascript client
>direct from the router also using libwebsocket's HTTP support. 
>If you're interested in the code it is here:


>I am still having some trouble with closing down connections. When the
>server side detects an AMQP close, I am not sure how to tell
>libwebsockets about it. I'm returning -1 from the callbacks whenever

If you have the wsi, you can also set a timeout of -1 on it.  Next time the timeouts are checked (should be ~1Hz), it will start the close on it synchronously without needing a network event involved.

>there is a sign that things are closing, but there seems to be a long,
>unpredictable delay before LWS delivers a CLOSED event, during which

ws has a controlled close concept where there is a ws handshake optionally expected containing reason codes.  It's optional though, since randomly hanging up is always legit, so it's protected by a timeout.

>there is nothing for my poller to poll - it starts getting constant HUP
>events, but if I take the FD out of the loop, LWS never gets to the
>CLOSED event.

When lws does the poll() wait he sees that directly and force-closes it.

However the post-close hs timeout should be live on that wsi.  If you're following the poll() type model, you should call the service api at 1Hz with NULL wsi, to allow it to do timeout processing even if idle for network events.  Otherwise timeouts won't be respected.  (lws libuv model support spawns its own 1Hz timer for that by itself).

If that's not it can you post some verbose lws logging around this close action?


>Libwebsockets mailing list
>Libwebsockets at ml.libwebsockets.org

More information about the Libwebsockets mailing list