Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

zeroconf/avahi support #78

Open
radarsat1 opened this issue Apr 10, 2019 · 3 comments
Open

zeroconf/avahi support #78

radarsat1 opened this issue Apr 10, 2019 · 3 comments
Labels
wishlist items that are not just enhancements of existing API but completely new features

Comments

@radarsat1
Copy link
Owner

It should be a configuration option to allow discoverability over the zeroconf protocol as outlined in OSC 1.1 spec.

@radarsat1 radarsat1 added the wishlist items that are not just enhancements of existing API but completely new features label Apr 10, 2019
@7890
Copy link
Contributor

7890 commented Apr 11, 2019

A short notice, for proprietary discovery it's possible to use UDP broadcast on a (shared) port.
Sending in LAN to 255.255.255.255:1234 /hello/im/here/query/my/stuff
However this involves pre-agreed discovery port for announcements (and eventually as a query "channel") syntax and semantics for participants in such network. It could be done all with existing OSC infrastructure.

@showlabor
Copy link
Contributor

I don't necessarily think zeroconf (mDNS/DNS-SD) should be part of liblo. There already are libraries or APIs for system services for every platform to handle it. So we can just leave the discovery and announcement jobs to them.
For the proprietary discovery scheme 7890 mentioned: Behringer/Midas use it for example on their X32/M32 and XAir/MAir line of mixers. It's OK there because they do control the hardware and firmware on those mixers and thus can guarantee that the necessary port is available. On a general purpose computer this guarantee can usually not be given.

@radarsat1
Copy link
Owner Author

To be clear this idea just comes from having a recent look at the 1.1 spec, where I'd forgotten until now that this was "officially" proposed. I recall something about avahi and liblo from many years ago but I don't remember in one context, and I guess that code did not survive.

@7890 we do something similar on libmapper but using multicast. It works great actually.

@showlabor could be, i put this here for discussion. i haven't looked into how easy it is, at least i would keep it optionally compiled if anything. certainly not every OSC service wants to announce itself this way.

I'll put this on the shelf for now but leave it open for a while in case there are any more comments from the community..

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
wishlist items that are not just enhancements of existing API but completely new features
Projects
None yet
Development

No branches or pull requests

3 participants