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

Andy Green andy at warmcat.com
Thu Dec 1 20:47:56 CET 2016

On December 2, 2016 3:27:59 AM GMT+08:00, Alan Conway <aconway at redhat.com> wrote:
>On Thu, 2016-12-01 at 07:42 +0800, Andy Green wrote:
>> 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:
>> > 
>> > https://github.com/apache/qpid-dispatch/commit/a1a1268ffbd18eb5c460
>> > 5fe5
>> > e503d70efa7be689
>> Great.
>> > 
>> > 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?
>Everything works beautifully now, fixed some issues in my own code and
>added a lws_close_reason() before all my return -1. There is still a 2


>sec delay before CLOSED but that isn't a problem if it's expected
>behavior. Now to embed a http server :)

I really recommend using the "mount" support in v2.0+.  Basically you bind a directory to a 'mountpoint' in the url space, and lws takes care of all the serving without your having to provide any related callback handlers.  There's a test-server-v2.0.c that shows how to register a linked-list of mounts when creating a vhost.

>My code is working on versions since v1.7.5, however fedora 25 has
>packaged 2.1.0 so the plan is to get that packaged for RHEL so we're up
>with the latest.

Oh, that's nice, I updated to f25 here during the beta and didn't notice.


More information about the Libwebsockets mailing list