[Libwebsockets] LWS usage in multi-process scenario

Xi Chen leon6827chix at gmail.com
Tue Dec 4 05:59:58 CET 2018


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...

Hope it is bit clearer

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


More information about the Libwebsockets mailing list