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

Andy Green andy at warmcat.com
Fri Dec 2 04:45:41 CET 2016


Resend to the list due to mailman breakage (apologies if this ends up a
dupe)

On Fri, 2016-12-02 at 03:47 +0800, Andy Green wrote:
> 
> 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 re
> > > dhat
> > > .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/a1a1268ffbd18eb5
> > > > c460
> > > > 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
> 
> Super.
> 
> > 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.
> 
> -Andy



More information about the Libwebsockets mailing list