I would like to work on IPP and IPP-everywhere support for Haiku, and I stumbled upon the absence of zeroconf/bonjour support in Haiku.
I’ve seen efforts to port mDNSresponder or avahi to Haiku, but I feel like proper support for Zeroconf in Haiku would require a new Haiku API providing the required features in a “haiku way”. For instance on Linux Avahi has a DBus interface so one can find services or hosts, and configuration files to expose new services (or the avahi-client library).
I feel like the philosophy of Haiku would be to have its own daemon, or a port of an existing daemon obviously, along with a proper Haiku API for the aforementioned features.
How wrong am I in this thinking?
If nobody started looking into it, I would love spending some time implementing this in the future, maybe extending the network kit… (and a ‘Haiku API design guide’ would be handy, but well, I guess by studying the Be Book I can get a grasp of this)
As mentioned in one of the comments on the thread @marcoapc linked… There is some previous work by a GSoC student, but it was never integrated into Haiku, and left as a set of patches here.
Thank you for the information, I found this thread but I was not sure about the status of all this work.
Was there any ‘decision’ taken regarding the location of the mdns daemon? Should it be a separate daemon running, or should it be a thread in the net_server team?
What I did with mDNSResponer [*] (and the bits with Jie Ma’s diffs) was to scratch my own itch, so to speak, and just from a “noisy end-user” basically (I don’t have the correct skills to really contribute much in terms of design, or much code, really ).
Hopefully some of the actual devs will chime in.
[*] PS: reminds me that I should revisit that recipe, as I remember having some un-submitted clean ups for it in a partition somewhere around here.
I wanted to have this as part of net_server, but if this is hard to integrate a seperate service is probably okay too. You should check out what makes sense for that. : )
My guess would be that integrating it in net_server may make it easier to have getaddrinfo and related functions resolve names usind mDNS in addition to DNS. But that’,s just a guess and could be wrong. The next person who attempts to make this work will have to find out and make a decision on what’s better or simpler
As mDNSResponder works well for my use case, I was planing to integrate it into the Network preflet.
Something like the SSHD server wouldn’t be so hard (IIRC, my mDNSd already runs from a “service file” similar to the SSHD one).
Ideally, said integration should allow to publish/unpublish custom zeroconf services. Shouldn’t be too hard at all for someone with a bit better focusing skills than mine.
“the other side of the coin”… being able to resolve address would be still missing, of course. But that’s a task for smarter folks than myself .
Maybe that’s a viable approach at least at first? integrate mDNSResponder into Network preflets until something better gets written, while focusing new development on the “resolve this local address for me please” side of things?
The name resolution issue is more interesting, and I really would appreciate an input on this before spending more time in the wrong direction.
The dynamic module support in netresolv is not enabled right now. I do not know if its something that was missed or something done on purpose.
One way would be to enable this support, fix what will need to be fixed in libnetwork so that the files and dns nss plugins are properly installed, and all should be good (I’ve started this, and it seems now I have to fix the mdns nss plugin).
Another way would be to integrate mdns support directly in netresolv without going through the nss plugins.
I see benefits and drawbacks in both cases, and this could end up being a philosophical question. What would the Haiku way Be? Are such dlopen()-ed plugins fine with the Haiku way of life? Most systems use them, but it’s not free, where does Haiku draw the line between «what everybody does» and «keep being the fastest OS on limited systems»?
There is nothing wrong with modules, they are fine to be used. However from an architecture standpoint to me it seems to make most sense to shortcircuit .local in the net_server directly. Maybe there are good reasons to go through nss however : )
One consideration for dns in general for haiku would be future automatic dmssec validation.
There is no call to net_server when resolving hostnames, libnetwork.so has the whole resolution logic embedded. A shortcut can still be made within libnetwork.so, but since there already is the nss logic, I feel the shortcut would be tricky and far from future-proof compared to the simple “fix NSS support” solution.
I think ultimately basic DNS resolution should always go through net_server. This would allow us to implement a resolver cache, too. But indeed that’s more involved than the other fixes discussed here. I’ve had it on my TODO list for a while, maybe I’ll get to it sooner rather than later, if nobody else does…
Incremental improvement beats stagnation. if NSS module is faster… to implement, not much sense on waiting for a perfect solution always in the future.
Man power is limited. Let’s have useful things soon(er), and better solutions when possible? (as long as the imperfect solution doesn’t incur in too big maintenance costs).
Yes, I think the general approach in Haiku is to get things working first, and optimize later. With a focus on writing readable code as a way to limit problems with not writing enough documentation.
So, if we can simply plug this into the existing name resolution architecture, let’s do that first, and if later we find that we’re not happy with it, we can always change it.
).