28 Feb
2005
28 Feb
'05
5:35 p.m.
On Mon, Feb 28, 2005 at 09:09:49 +0000, Martin Habets wrote:
My impression is that more and more applications are
moving to
OSC for inter-process communication.
Question 1: Are most audio/midi applications converging on OSC?
Are there any moving away from it? Or are there other strong
contenters in this area?
AFAIK all linux audio/midi applications use an arbitrary UDP port
number, and rely on manual configuration of this for the server and
all clients.
With OSC popularity increasing this will pose a growing problem
for end users who have to configure the ports, and for developers
of client programs that want to interact with multiple servers.
The answer to this issue is service discovery, which was recently
discussed on the OSC_dev list [1]. That thread leads to a product
called howl [2], which is an open implementation of mDNS/redezvous/
zeroconf (take your pick). It provides 3 daemons (of which 2 should
be run) and some libraries.
Using this implementation all applications would (ideally) register
or discover services using the howl libraries. Apart from this, the
programs would communicate via OSC.
There is a proposed specification for discovery of OSC services that was
presented at hte OSC conference, I intend to support it in liblo at some
point in the future.
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.
IIUC Gnome allready requires libhowl and mDNSResponder, so its not as
burdonsome as it could be.
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.
That is not as appealing to me, as the service will only be discoverable
on the local machine, whereas MDNS works on local networks.
I did consider this solution when I started implementing liblo, but
rejected it as too OSC specific.
Dave Robillard (sp?) has an another OSC-based idea that covers some of hte
same ground, but I'l leave him to describe it.
- Steve