[Libwebsockets] POST messages callbacks
andy at warmcat.com
Tue Mar 9 09:23:27 CET 2021
On 3/9/21 8:02 AM, mbargauan at comm5g.com wrote:
> 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
> 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