[Libwebsockets] LWS usage in multi-process scenario

Andy Green andy at warmcat.com
Tue Dec 4 04:25:27 CET 2018



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>> 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> 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> 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>
>      > https://libwebsockets.org/mailman/listinfo/libwebsockets
>      >
> 


More information about the Libwebsockets mailing list