[Libwebsockets] LWS usage in multi-process scenario

Andy Green andy at warmcat.com
Tue Dec 4 06:42:22 CET 2018



On 04/12/2018 12:59, Xi Chen wrote:
> The protocol is http traffic.
> 
> [apps + lws] runs on an embeded device (as http client), communicating 
> to a single cloud endpoint which then route to different services...

I guess it depends how strong the clients are, how much RAM etc.  If it 
can run the apps as separate processes, then I guess it's not so weak as 
RTOS / ESP32 or whatever.

If it's on client side, IIUI you basically want something to act as an 
"aggregator" or "concentrator" to gives the apps a single place to talk 
to the server where all the content is in one event loop in one process 
so it can be coordinated.

If lws can spawn / manage the apps, then it can hook their stdin / 
stdout like the cgi server stuff does.  Or, lws can open a listening 
unix skt on the client side, and when the apps want to send something 
they make client http connections to this local socket (no tls, since 
all on same machine).  When lws sees a local client connection, he makes 
an onward, proxied client connection to the cloud server...  after the 
first one, although the streams are logically separate these would share 
space on a single h2 link to the cloud.

This "http client aggregator" feature doesn't exist as a whole, but 
there are a lot of pieces for that already proved, eg raw-proxy role / 
protocol

https://libwebsockets.org/git/libwebsockets/tree/plugins/raw-proxy

knows how to do the management on the onward client connections and 
incoming connection lifecycle, and parts of the server proxy stuff know 
how to proxy h2 <-> h1, so the apps can just speak and understand h1 
like a cgi.

-Andy

> Hope it is bit clearer
> 
> On Mon, Dec 3, 2018 at 7:25 PM Andy Green <andy at warmcat.com 
> <mailto:andy at warmcat.com>> wrote:
> 
> 
> 
>     On 04/12/2018 10:27, Xi Chen wrote:
>      > Andy,
>      >
>      > Sorry I might not present it clearly.
>      >
>      > First, my use case is on client side rather than server side.
> 
>     Okay...
> 
>      > Second, I have one single cloud H2 endpoint for multiple
>     applications
>      > (clients), I would like all these applications (in its own
>     process, not
>      > thread) to talk to the same instance of LWS (running its own
>     process).
>      > Of course, cloud side has to demux properly. But Im more focus on
>      > applications-to-LWS part for now.
> 
>     I don't understand this description either.
> 
>     What protocol do the clients talk over h2?  http?  ws?
> 
>     This [lws + apps] client bundle runs on the cloud or remote users that
>     connect to the cloud?
> 
>     -Andy
> 
>      > On Mon, Dec 3, 2018 at 6:03 PM Andy Green <andy at warmcat.com
>     <mailto:andy at warmcat.com>
>      > <mailto:andy at warmcat.com <mailto:andy at warmcat.com>>> wrote:
>      >
>      >
>      >
>      >     On 04/12/2018 09:46, Xi Chen wrote:
>      >      > Andy,
>      >      >
>      >      > I have a special use case of LWS where multiple application
>      >     processes
>      >      > (not threads) share the same H2 connection:
>      >
>      >     Well, not directly...
>      >
>      >      > - LWS main thread running in one process
>      >      > - each app running in its own process (hence isolated
>     address space)
>      >      >
>      >      > Unlike multi-threading case where address spaces are
>     shared among
>      >      > threads hence callback function pointers are globally
>     known, it is a
>      >      > question how to perform callback in my case. Seems IPC
>     mechanism
>      >     has to
>      >      > be implemented anyhow.
>      >      >
>      >      > Is this recommended? Any other approach?
>      >
>      >     I would stop thinking about that setup as "multiple application
>      >     processes shar[ing] the same H2 connection"... that might be
>      >     technically
>      >     true but it implies things that don't directly lend themselves to
>      >     working across process boundaries.
>      >
>      >     Is the traffic ws or http?  If ws, there's no good way
>     implemented
>      >     atm[1].  If it's http, then you should look at the unix
>     socket proxying
>      >     stuff in 3.1 / master.
>      >
>      >     Gitohashi (https://warmcat.com/git/gitohashi) on
>     libwebsockets.org <http://libwebsockets.org>
>      >     <http://libwebsockets.org> works
>      >     this way... gitohashi is a separate process that happens to
>     have its
>      >     own
>      >     lws instance listening on a local unix socket.
>      >
>      >     The public lwsws on libwebsockets.org
>     <http://libwebsockets.org> <http://libwebsockets.org> is
>      >     configured to treat
>      > https://libwebsockets.org/git and anything down that url path as
>     being
>      >     handled by proxying to the local unix domain socket that
>     gitohashi is
>      >     listening on.  It opens a client connection to the proxy
>     address (which
>      >     may also be remote) and, translating h2 to h1 (ie, the other
>     server
>      >     only
>      >     sees h1 even if the actual connection is h2), forwards the
>     request and
>      >     passes back any inbound traffic from the client connection. 
>     When the
>      >     onward connection closes, the inbound stream is closed.
>      >
>      >     Docs here:
>      >
>      >
>     https://libwebsockets.org/git/libwebsockets/tree/READMEs/README.unix-domain-reverse-proxy.md
>      >
>      >     If it's actually ws probably the best solution is implement the
>      >     equivalent proxying support in lws.  If not, you're into
>     basically
>      >     making your own proxying either using SHM
>      > http://man7.org/linux/man-pages/man7/shm_overview.7.html, a fifo or
>      >     your
>      >     own unix sockets... and that's less flexible than IP proxying
>     with unix
>      >     domain socket support.
>      >
>      >     -Andy
>      >
>      >     [1] But you can send patches or pay me or someone else to do it.
>      >
>      >      > Thanks
>      >      >
>      >      > _______________________________________________
>      >      > Libwebsockets mailing list
>      >      > Libwebsockets at ml.libwebsockets.org
>     <mailto:Libwebsockets at ml.libwebsockets.org>
>      >     <mailto:Libwebsockets at ml.libwebsockets.org
>     <mailto:Libwebsockets at ml.libwebsockets.org>>
>      >      > https://libwebsockets.org/mailman/listinfo/libwebsockets
>      >      >
>      >
> 


More information about the Libwebsockets mailing list