[Libwebsockets] LWS usage in multi-process scenario

Xi Chen leon6827chix at gmail.com
Tue Dec 4 03:27:27 CET 2018


Sorry I might not present it clearly.

First, my use case is on client side rather than server side.

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.

On Mon, Dec 3, 2018 at 6:03 PM Andy Green <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 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 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
> > https://libwebsockets.org/mailman/listinfo/libwebsockets
> >
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://libwebsockets.org/pipermail/libwebsockets/attachments/20181203/77324457/attachment.html>

More information about the Libwebsockets mailing list