[Libwebsockets] FYI: qpid-dispatch project now has websocket integration using libwebsockets
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:
>management client can connect directly to a qpid dispatch router
>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
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