[Libwebsockets] client protocol selection criteria discussion

Andy Green andy at warmcat.com
Mon Feb 10 01:44:22 CET 2020

On February 9, 2020 11:05:23 PM GMT, Olivier Langlois <olivier at olivierlanglois.net> wrote:
>I feel like I am currently in uncharted waters in my lws usage and I am
>discovering the limits of what is possible as I figure out how to
>accomplish my design goal.

Lws is predicated around a single threaded event loop.  Its only way to interoperate with other threads is lws_cancel_service().

That's a very simple proposition that goes a long way.  Lws doesn't claim anything to mislead you into thinking it's threadsafe and you can just call its apis from different threads - you can't.

>Here is some background to what I'm trying to accomplish:
>1. Have a client connect to 2 different services

It's fine.

>2. Because I don't want 1 service handling impacting the performance
>and responsiveness of the other service handling, having 2 service
>threads and have each connection binded to its own thread exclusively
>would be ideal

In the lws part, with only two or a dozen streams on a capable microcontroller, it doesn't typically introduce much real latency over what the network traffic itself caused.  If your user code is going to block for cpu or anything else, it's possible to handle all the io as lws wants, put it into shared objects in memory and signal another thread something came / call lws_cancel_service() to alert lws something to do from another thread.  If you don't really expect your user code to block, try it all in the one service thread first.(

That will all work fine if, eg, unknown to either of them your two client connections are h2 streams to the same endpoint sharing one network connection.

>3. The 2 service are 2 different protocols.

Doesn't make any difference.

>I have found that if a connection was created from a service thread, an
>initial binding was created between the thread and the connection
>(under which conditions could that binding be broken?).

No that's something different.  You almost always use exactly one service thread, that's why a max of 1 is the default.  In the case you're the server and want to serve huge numbers of connections, load-balancing across n event loops on n threads / cores lets you scale beyond what a single thread can do.  It's still a single-threaded event loop, you just have n of them and new connections bind to the most idle one.  It's not what you want.

>However, the only criteria lws use to determine the protocol to use is
>the Protocol header value found in the server reply. Therefore, I will

Yeah that is how ws works.

>be forced to use a single callback for my 2 protocols and do the
>dispatching myself from the callback.



>I am throwing this idea on the list for discussion. Would it be a good
>feature to make it possible to select the protocol based on the
>connection destination?
>ie: if you connect to protocolA server, use protocol A. if you connect
>to protocolB server, use protocol B.
>Something that I need to mention. It is that I am developing a WS
>client to use existing WS services. I suspect that I'm a rare breed as

Lots of people use lws with somebody else's apis.


>most lws users are probably developing servers to let web browsers use
>their services from a webpage.
>imo, that is an important detail to mention before someone suggest me
>to simply change my server to include the protocol name in the reply. I
>have no control on how the servers are behaving...
>Libwebsockets mailing list
>Libwebsockets at ml.libwebsockets.org

More information about the Libwebsockets mailing list