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