<div dir="ltr">Hi, trying to bottom-post:<br><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Mar 14, 2017 at 10:08 PM, Stefan Westerfeld <span dir="ltr"><<a href="mailto:stefan@space.twc.de" target="_blank">stefan@space.twc.de</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">   Hi!<br>
<span class="gmail-"><br>
On Fri, Mar 10, 2017 at 07:19:24PM +0100, David Robillard wrote:<br>
> On Wed, 2017-03-08 at 20:23 +0100, Robin Gareus wrote:<br>
> > On 03/08/2017 08:04 PM, David Robillard wrote:<br>
</span><span class="gmail-">> > I'd love to see an efficient IPC mechanism that works x-platform on<br>
> > all<br>
> > the platforms that LV2 works on.<br>
><br>
> Nobody ever got fired for using TCP sockets.<br>
<br>
</span>Yes, right. One could use a pipe() if the platform supports that and fall<br>
back to identical-API sockets.<br>
<span class="gmail-">><br>
> "Efficient", well, yeah.  No.  This is a fallback (or single-plugin<br>
> host) mechanism, not something ideal.  That said, it can easily be good<br>
> enough.  Hell, people do this for actual plugins and kinda sorta get<br>
> away with it, most UIs are waaaaaaaaaaaaayyyyyyyy less demanding.<br>
<br>
</span>We don't need hard-RT for UI anyway, so this should be fine.<br>
<span class="gmail-"><br></span></blockquote><div><br></div><div>I'm a programming beginner and also interested in learning about TCP. </div><div><br></div><div>I thought it's too slow/expensive for audio. But maybe it's nice for testing plugins, e.g. if a host doesn't provide a generic gui, or if the "generic logic" produces cumbersome results. Since it was brought up in this thread, I was wondering if anybody could outline in more detail how to do this properly? </div><div><br></div><div>I should say that I understand about 20% of what is being discussed here, so I appreciate references to tutorials or introductions (particularly using networking protocols).</div><div><br></div><div>I tried to get something working with as little effort as possible, probably very naively: </div><div><br></div><div>At UI instantiation I launch a TCP listener in a new thread (A) that listens on an OS-assigned port. When the connection is established, the stream is split into a "receiver" and a "sender". The "receiver", which in my case receives from a Web browser, is blocking, and so must be put into another thread (B), along with the LV2 write_function and the controller. The port_event() function is connected to the "sender" with a so-called "channel". Side note: A "channel" is a Rust thing that provides asynchronous communication between threads, surely there is something equivalent in C, but I don't know how to call it.</div><div><br></div><div>So in other words, there are two new threads for a single plugin instance, which is probably very bad. True?</div><div><br></div><div>Is a better way to do it, to let the ui be a client only, and connect to a standalone server? That wouldn't reduce the overall load, but the server could live on a different CPU core or even CPU?</div><div><br></div><div>When I brought up websockets in a previous thread (almost a year ago) Hanspeter pointed me to his Moony plugin. However, I could not find stuff related to websockets, tcp or the like.<br></div><div><br></div><div>Thanks, Stefan</div><div><br></div><div> </div></div><br></div></div>