5 Sep
2011
5 Sep
'11
2:47 p.m.
On Mon, Sep 05, 2011 at 08:07:55AM -0400, Paul Davis wrote:
<thijsvanseveren(a)gmail.com> wrote:
Read: the remote jackd needs to be informed and then trigger a
session-save on its side.
Seems doable. A typical case for out-of-band communication (given that
netjack has such an OOB channel).
hi all
are there any plans to extend jack_session support so that it can save a
session that spans over 2 (or more) PC's that are connected via the 'net'
backend ?
no, because it uses the existing communications channel(s) to talk to
clients, and this does not go over a network. JACK Session saves the
state of the clients of the server; processes running on other systems
are *not* clients of the JACK server. it would be the responsibility of the net backend to
somehow gather
and store the state that is needed to restore things. that would be
hard, since it has no way to instantiate processes on a remote machine
(which could be running an arbitrary OS).
I once was an OpenMPI programmer, and launching processes on a remote
host is crucial to MPI environments. They have a complex I/O forwarding
system, combined with something called process launching system. Several
"plugins" provided different methods of launching processes, think of
ssh or a cluster scheduler like Sun Gridengine.
While I think that implementing all this would be way too complicated,
one could come up with a simple extension to the net backend:
We could agree that, for transparent restore on networks, it must be
possible to ssh to the remote host. In fact, launching jackd there could
also be coupled to this idea. Then, the remote net backend takes a single
argument for the session to be loaded, and that's it.
State remains local to the remote machine.
Actively launching the remote jackds might also simplify the entire
invocation process. Just name a few hosts on the command line and off
you go. Like this:
jackd -d future-net -hosts box1,box2,box3
This would spawn remote jackds on box1, box2 and box3 and then wait for
the user to start clients. Which, by the way, could also be done
remotely.
Note that the entire idea is completely orthogonal to jackd, so one
could come up with a tool that uses ssh to launch stuff on different
nodes and triggers the session-save/session-restores on all nodes.
Ladish jumps to my mind: "launch remote jackd" and "launch remote jack
client". Ok, it's sort of "sessions over sessions", but recursive
concepts have always been around. ;)
Just my €0.02