search

brutella / hc

hc is a lightweight framework to develop HomeKit accessories in Go.
Apache License 2.0
1.74k stars 189 forks source link

FR: Optional Avahi integration #123

Closed ivucica closed 5 years ago

ivucica commented 6 years ago

Hi,

did you consider optionally integrating with Avahi by talking to it using DBUS? Example

This would not only allow running more than one hc-using frontend per machine, but it also would allow running Avahi itself at the same time.

I see high value in having a standalone and integrated mDNS implementation, but having an option to register with a systemwide service would help a lot.

brutella commented 6 years ago

Would love to see a pull request to integrate Avahi. 🙂

timoschilling commented 6 years ago

You don't need to use Avahi to run more then one hc per device.

ivucica commented 6 years ago

@timoschilling Can you please clarify: how does that work?

Admittedly, I am unfamiliar with multicast addressing. Therefore, I've just tried to reproduce this by running nc -u -l 224.0.0.251 5353 (source) in two tmux tabs and thus observing mdns traffic on my network. As far as I can tell only one of the netcats is actually receiving the traffic.

Wouldn't Avahi swallow hc traffic? Wouldn't hc-1 swallow hc-2 traffic? Wouldn't hc swallow Avahi traffic? None of these scenarios is particularly appealing.

Optionally integrating with a system-wide mdns+dnssd daemon seems like a good (and, very importantly, clean) option for those that need it. What else would you do?

Sidenote: hc, in my case, would not running on a "device"; it would be running on a VM that hosts many other services (including things like netatalk) and it would expose many real and virtual devices that I already control through other means.

ivucica commented 6 years ago

@brutella I have some ideas and I'll see if I can get approval from work.

Some design thoughts for either myself or another contributor:

brutella commented 6 years ago

Wouldn't Avahi swallow hc traffic? Wouldn't hc-1 swallow hc-2 traffic? Wouldn't hc swallow Avahi traffic? None of these scenarios is particularly appealing.

No, multiple sockets can listen to the same address/port. A mdns responder should only responds with services and instances that it knows. If multiple responders are running on the same host, they will negotiate unique hostnames – this is why you will see hostname-1 and hostname-2 appear on the network.

ivucica commented 6 years ago

Thanks for the responses! This made me learn something new.

No, multiple sockets can listen to the same address/port.

Not the surprising part :-)

A mdns responder should only responds with services and instances that it knows.

Not the surprising part :-)

If multiple responders are running on the same host, they will negotiate unique hostnames – this is why you will see hostname-1 and hostname-2 appear on the network.

This is news, but also not surprising.

You were responding to this snippet of mine:

Wouldn't Avahi swallow hc traffic? Wouldn't hc-1 swallow hc-2 traffic? Wouldn't hc swallow Avahi traffic? None of these scenarios is particularly appealing.

The surprising part to me was that the kernel delivers the traffic to every listening socket rather to an arbitrary one. I seriously did not expect that; if it weren't doing that, there would be no traffic for the "wrong" process to ignore.

So I just put together a test program to validate what's going on, and thus learned how to do multicast in general, and in Go in particular.

Taking the multicast setup from github.com/brutella/dnssd (very informative!), including the JoinGroup (which was news to me), I learned my assumptions were wrong and now I am not actually sure what was happening with netcat in https://github.com/brutella/hc/issues/123#issuecomment-419728986.

As this was new to me, then yes, probably there is no conflict with Avahi or multiple hcs. Therefore integration with Avahi would (presumably) primarily benefit other software that communicates with Avahi over DBus.

As such, I expect I probably won't pursue this further myself :-)

brutella commented 5 years ago

Closed due to inactivity.