1 Mar
2005
1 Mar
'05
4:32 p.m.
On Tue, Mar 01, 2005 at 02:58:08 +0000, Martin Habets wrote:
Yes, rendezvous is the general purpose answer to the problem. It will get
more used over time, and it is exactly that which may pose a problem.
But what happens when someone turns on the rendezvous-enabled washing
machine during your recording session? Or consider the M$ Windows machine
that publishes, retracts and queries like crazy. You'd have to create
a subnet for your audio studio to artificially limit the scope of
rendezvous.
Not at all, theres a protocol prefix for OSC, which washing machines are
unlikly to speak :) so washing machines will be ignored by OSC things.
Also, there is a field that you can use to descriminate between OSC
services that use particular schema.
I was thinking along the same lines here. But the point is that if you
use rendezvous only for daemon discovery, then the overhead costs more than
the benefit you gain (remember every application would need it).
No, the benefit is that the application can send to one or more
destinations without the author explicitly coding some discovery stuff,
and be changable dynamically. Thats not possible without
1) some discovery
2) a service (in the looses sense) that tells you where to send things
I thought so to, but Dave has some counter examples.
On Tue, Mar 01, 2005 at 01:27:38PM -0500, Dave
Robillard wrote:
I dont think thier actually the same, they just overlap to some extent.
Both of these things are needed, but one is allready defined (zeroconf+the
OSC specific stuff), and one needs some thinking.
Dave is trying to solve exactly the case where you *do* want to manually
connect applications. He has examples.
So basically my goals are to make OSC using liblo
as nice as audio using
jack, as far as "ports" and "connections" (in jack-ese) go, with as
little burden on clients as possible, and allowing user patching, etc.
It seems our goals are the same, although user patching should not be
needed IMO. To me this seems like a lot of overhead for a
relatively small gain.
OTOH it seems like a very flexible and future-proof solution.
It is overhead at connection establishment time - irrelevant to actual
performance. Rendezvous is the way to do these things, no question. It
will only get even more popular over time. At the moment rendezvous is a very open/liberal
system. I'm all for that
off course, but with growing popularity I think it will gain some security
features. That could be bad news for folks who just want to get together
and jam.
I really dont think so. It doesnt make sense to add seurity to redevous
itsself, if you want secure, discoverable services then use IPSec. Its a
different layer.
An alternate way I've been considering is an
OSC-based service
discovery daemon. It would accept OSC messages to register and discover
services. The advantage of this is that it only uses 1 small daemon,
but more importantly that applications do not need to use any additional
libraries besides the OSC one (<insert liblo plug here> :). So far I
can see 6 input messages for such a daemon, with 4 response messages.
The disadvantage is that the daemon would still need an arbitrary port
number, and all applications would need to know it (at least for a while).
For intra-host discover the daemon could still interact with howl or
something like it if that is needed. But if this approach is successfull
we could request one dedicated port from IANA.
Question 2: Are there other better alternatives?
Question 3: Which alternative is better or do you prefer? (mDNS/OSC-daemon)
Actually, the solution myself and Steve Harris came to (on #lad) is a
combination of both. In order to accomplish user "patching" and relieve
the burden on clients, an OSC daemon will be required to maintain
information about what is patched to where, etc. However, rendezvous is
needed so things can discover each other (ie clients can discover the
patching daemon, and vice versa). The
"patching server" (called that from hereon for lack of a better
name) has simple commands like /set_destination
<url>, /remove_destination <url>, etc. You can imagine a GUI
jack-patch-bay like client for it.
I don't like the idea of yet-another-patch-bay for this. It just pushes
the problem out to the end users, most of which do not know (or want to)
what to connect where. Besides, the application developers know much better
which services their application want. For example, the sooperlooper GUI is only wants to
find sooperlooper
engines. It is not interested in whatever jack.osc offers.
Right, but thats not true in all cases.
For the record I will not add support (or accept patches) to liblo for any
discovery mechanism that does not use an existing standard. I know just
enough about the area to know that there are subleties of the problem that
I dont get, and there are plenty of known-good standards in this area, of
which redevouz/zeroconf is probably the most appropriate.
- Steve