[Libwebsockets] LWS usage in multi-process scenario
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.
> > 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?
> > 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
> > >
> > > 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. If it's http, then you should look at the unix socket
> > 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
> > handled by proxying to the local unix domain socket that gitohashi is
> > listening on. It opens a client connection to the proxy address
> > 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
> > passes back any inbound traffic from the client connection. When the
> > onward connection closes, the inbound stream is closed.
> > Docs here:
> > 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
> > domain socket support.
> > -Andy
> >  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...
More information about the Libwebsockets