[Libwebsockets] External poll and listener usage
andy at warmcat.com
Thu Feb 9 18:21:57 CET 2017
On February 9, 2017 11:54:10 PM GMT+08:00, Vitaliy Aleksandrov <vitalik.voip at gmail.com> wrote:
>Hello, libwesockets community.
>I'm planning to use libwesockets to add WS support to an existing
>application with its existing event loop (poll) and listening socket.
>External poll integration looks quite simple and test server provided
>sources is a good example. As I've already mentioned my server accepts
>clients connections itself.
>*lws_adopt_socket()* does the job and lws successfully adopts provided
>Since I don't use lws internal listener I wanted to turn it off and
>two lws context options: CONTEXT_PORT_NO_LISTEN
>and CONTEXT_PORT_NO_LISTEN_SERVER (not in 2.1 stable).
>Documentation about mentioned options is not clear for me. I
>tried CONTEXT_PORT_NO_LISTEN_SERVER with the latest master branch
>and CONTEXT_PORT_NO_LISTEN with the 2.1 stable and in both cases my
>HTTP (not ws yet) server didn't start internal listener and took
>client's fd without any problems. So what is the real difference
>them for a WS server?
As you saw CONTEXT_PORT_NO_LISTEN used to be the only constant to kill listening, it also directly implied you want to kill listening because you are being a client.
With the adoption apis though, that implication about client mode for the context is no longer necessarily true. As in your case, you may have external listening and then an adoption step, you want to suppress internal listening for that reason and you are being a server.
So CONTEXT_PORT_NO_LISTEN was left alone for backwards compatibility, and CONTEXT_PORT_NO_LISTEN_SERVER added that shares the listen suppression, but does not trigger the other client-related changes. If you got to the point of adopting ssl-wrapped connections, you would trip over these client-related behaviour changes otherwise.
So CONTEXT_PORT_NO_LISTEN_SERVER is the one you want for your case.
More information about the Libwebsockets