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

Alan Conway aconway at redhat.com
Thu Dec 1 20:27:59 CET 2016


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 :)

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.





More information about the Libwebsockets mailing list