[Libwebsockets] POST messages callbacks

Andy Green andy at warmcat.com
Tue Mar 9 09:23:27 CET 2021

On 3/9/21 8:02 AM, mbargauan at comm5g.com wrote:
> Andy:
> thank you for valuable help, it works great, and solved the my problem.
> There is one question that is dividing in my team and where your opinion 
> could help:
> as we have 2 functional activities, one ingesting data from other 

It depends what it means "ingesting data", it's via a socket or 
something else?

> process and one websocket (deliver updated data and receiving commands 
> from web based gui), we have seen different ways to implement:
> one is by having one vhost on one port and a second on a different port,
> second is having 2 vhost on the same port,
> last is having different threads per functional activity.
> We are using 4 core processor, single ethernet port. What is your 
> suggestion on best approach?

Anything that uses a singlethreaded event loop will work cleaner and 
simpler if you don't have other threads.  You can literally just not 
have any locking in your code at all that way, since the event loop 
serializes everything.  So unless there is some timeconsuming compute to 
do that would block the event loop, you want to do everything 
asynchronously on the single event loop without additional threads.

You need a vhost per listening / serving socket, per set of server tls 
certificates / keys, or per explicit client validation CA if not using a 
central trust store.  Eg, libwebsockets.org and warmcat.com are served 
by lws from the same IP on port 443, but each has its own vhost, named 
"warmcat.com" and "libwebsockets.org", and the right certificate / key 
bound to it.  When clients connect to :443, their tls library uses SNI 
to pass along the hostnaame they want, so we can bind to the right vhost 
and see the correct certificates.

You can also share a listening port between vhosts without tls if you 
are using http / ws, it will use the Host: header from the client 
instead of SNI to bind to the right vhost.

It also depends what protocol "ingesting data" is using, you can use one 
vhost with one listening port if it's websockets... the clients can use 
the websocket subprotocol string to bind their connection to the lws 
protocol they want to use, all inside one vhost.  You also explicitly 
enable lws protocols on to specific vhosts, eg, so your ingress protocol 
is not selectable from the management ws vhost.

Depending again on what "ingesting data" means, you might not want to 
share one port even if you can though, because of security 
considerations of binding each vhost's listen socket to a specific 

Eg, if "ingesting data" is coming from the loopback interface, you can 
bind that vhost's listen socket specifically to lo so the listen port 
for that it is not accessible from the outside network, and only your 
management ws server is available from outside.  Similarly if the source 
is inside the same device, you can use a Unix Domain Socket to listen on 
that again isn't reachable from outside.


More information about the Libwebsockets mailing list