« Multicast DNS, Service Discovery, etc
Never let a tree do a hash table’s job »
May 09 2007

mDNS stack to the responder daemon

Posted by fli in FreeBSD, tags: ,

Last night (local time) I submitted my initial mDNS stack to p4, it forms the foundation of the responder daemon (mdnsd). The stack is more or less complete, but I’ll see how it works out once I integrate it with the rest of the application, there will probably be some more code re-factoring (and bug fixing).

The stack provides an abstract interface to the underlying sockets, it takes care of multicast group memberships, buffer management, packet creation and parsing. The interface is the same both for IPv4 and IPv6 which was one of the main requirements. As for DNS names the interface uses wide characters (wchar_t) only and properly encodes/decodes to UTF-8 (just as the specification says), this means that one should be able to use exotic characters natively (such as smörgåsbord.local) without punny-encoding. Oh, and it also does optimal dns name compression in the packets.

All my initial tests shows that the stack itself works well and it’s able to parse all packets my Mac OS X client is sending. I’ve also been running it together with network fuzzer (zzuf) while spewing packets on it, haven’t crashed this far (famous last words) :) . In addition to this I have a few static test cases I’m going to put it through, which it should support, at least in theory that is. I also plan to run it through gprof to see if there are any dead-obvious sections that could be optimized.

But, all in good time. Now I’m gonna disappear for a while and take care of some school stuff.

This entry was posted on Wednesday, May 9th, 2007 at 9:32 am and is filed under FreeBSD. You can follow any responses to this entry through the RSS 2.0 feed. You can skip to the end and leave a response. Pinging is currently not allowed.

7 Responses to “mDNS stack to the responder daemon”
  1. Bruce Walker says:
    May 9, 2007 at 3:42 pm

    Innocent question: since there are two complete implementations of Apple’s Bonjour on FreeBSD (mDNSresponder and Avahi), why expend all the effort to write another? I understand that adding GPL code (Avahi) to base FreeBSD is a problem. But what abour mDNSresponder? It seems that the only piece of the mDNSresponder code that’s missing is an IPv4 linklocal address assignment daemon, so why not concentrate on that?

    If the issue is with the APPL license, how is it a problem for inclusion in base FreeBSD code? Maybe there’s a discussion on that license and incompatibility with BSD licensing that I have missed. If there’s a pointer to that I’d really like to see it.

    Cheers!

  2. fli says:
    May 9, 2007 at 4:53 pm

    Avahi is a no-go as it’s GPL, however it’s also the only one of the two I would be comfortable using.
    There was a brief discussion about this on freebsd-net@ last August, if I remember correctly there were no final ruling regarding how APPL should be treated, only that “we’re mostly OK with it” which is a bit vague.
    There were also a (very, almost bikesheddy) lengthy discussion about responder features at the same time.

    I’ve considered mDNSresponder more than once, but every time I review the code I get that “No”-feeling in my stomach. I just don’t like it.

    As for link-local ipv4 I already do have a daemon for this, written ~10 months ago, however people seemed to want multi-home capabilities (ie. using 169.254/16 on several interfaces connected to separate networks) which would require some major kernel changes. I’ve discussed this briefly with bms@.

  3. Bruce Walker says:
    May 9, 2007 at 6:40 pm

    I understand then. I certainly know what you mean about the “insides” of mDNSresponder. I use it daily on FreeBSD (which is why I ask), but I treat it entirely as a Black Box. If I have to debug it at all I first run indent over it so I don’t go insane. Even then — well it’s awfully *suspect* stuff, I agree. ;-)

    (I submitted a couple of bugs and fixes to Apple on it in the past and they either fixed them or gratefully folded patches into their CVS, so this isn’t just theoretical-talk.)

    That said, I actually like the API for it. It inter-works perfectly with libevent and is easy to understand and use in event-driven code. That’s key, AFAIC.

    Well, carry on Fredrik! And Godspeed! I would really like to see a ZeroConf implementation in FreeBSD’s base install, and whatever way it gets there is OK by me. :-)

    Cheers!

  4. fli says:
    May 9, 2007 at 7:01 pm

    I have plans to make a compatible API, if you by API refer to the one provided by dns_sd.h.
    In fact, the ultimate goal is to have support both for the client API provided by Avahi and the API provided by mDNSresponder.

  5. Alexander Botero-Lowry says:
    May 10, 2007 at 3:00 am

    I see that you integrated an implementation of a doubly linked list and a hash table into your P4 tree. Have you looked at queue(3)? It provides macros for a number of data types like that which may be of use to you, and would possibly be more consistent with how those data types are used in other FreeBSD code.

  6. fli says:
    May 10, 2007 at 9:46 am

    Alexander Botero-Lowry

    Then you should also have noticed that the code in p4 is already changed to queue(3).

    I was already aware of queue(3) and I’ve used it number of times, it generated a real bikeshed of perforce-review@. My initial reasons were portability across BSDs as these lists touch almost every single file, however it turned out that sys/queue.h where quite on-par between the BSDs these days.

    All these discussions probably took more time than it took me to code that list (which I did a long time ago to another project).

  7. Alexander Botero-Lowry says:
    May 12, 2007 at 4:53 am

    Yeah, I saw you submitted the update but it was after I’d submitted my comment :/

    I understand a number of people even use it on other platforms since it works so nicely.

  8.  
Leave a Reply