I’ve finished of several quite large subsystems in mdnsd, including the cache and the record database (which is used for self-claimed records). This means that it’s able to receive and cache records, and able to read self-claimed records off a configuration file and add them to its database.

The configuration file is quite simple, while still being flexible enough to allow more advanced configurations, it’s however a bit different from a regular DNS configuration as the namespace in mDNS is quite flat.
This is a sample that claims a A record, AAAA record and PTR records for each address;

# A zone is only a way to avoid duplicate typing,
# one could have skipped it and simply
# used $(hostname).local. as the rrset.
zone "local." {
# A rrset holds a name and one or more resources, a
# resource type can hold multiple data sets
rrset "$(hostname)" {
alt = "$(hostname)-$(ifname)";
# This is a resource for the IN type A with the data set to $(ifaddrs4)
res A { data = "$(ifaddrs4)"; }
res AAAA { data = "$(ifaddrs6)"; }
}
}
rrset "$(ifaddrs4)" {
res PTR { data = "$(hostname).local."; }
}
rrset "$(ifaddrs6)" {
res PTR { data = "$(hostname).local."; }
}

(It’s supposed to be white spaces in there but they seem to disappear)

This also demonstrates the quite nifty variable systems that is in place. A variable will be expanded to one or more lines of data, this data is context aware, which means that putting $(ifaddr4) as a rrset name will result in a in-addr.arpa-domain while setting $(ifaddr4) as a resource data on a IN resource will encode it into a regular (binary) ip-address.
On our imaginary host foobar with the interface foo0, which has two ipv4 addresses (10.0.0.1, 10.0.0.2) and one ipv6 address (fe80::20a:5eff:fe5c:f5d7), the above configuration would result in the following;

foobar.local. IN A 10.0.0.1
foobar.local. IN A 10.0.0.2
foobar.local. IN AAAA fe80::20a:5eff:fe5c:f5d7
1.0.0.10.in-addr.arpa. IN PTR foobar.local.
2.0.0.10.in-addr.arpa. IN PTR foobar.local.
7.d.5.f.0.0.0.0.0.0.0.0.0.0.0.0.0.2.0.a.5.e.f.f.f.e.5.c.f.5.d.7.ip6.arpa. IN PTR foobar.local.

The records will automatically adjust to any changes to the interface configuration.

Any settings that should only be set on a specific interface can be wrapped inside a interface “foo0″ {} statement.
Note how one configuration line expands into several real records.

Next up will be some sort of output queue and routines to send responses (packet construction routines are already in place in the low-level stack).

I’ve been toying and experimenting with different data structures to represent the domain name cache in mdnsd.

These are the structures I’ve seriously considered

• Radix tree/trie – It’s attractive to do lookup in O(k), but with a key length of 255 bytes (utf8) the tree would be huge, 2040 bits. Not sure it would be effective even with all the compression techniques in the book.
• Splay tree (self-balancing binary tree), scales well but key comparisons must be strcmp().
• Hash table, well obviously fast but there could be scaling problems as collisions become lager.
• “Chained” hash table – Use the fact that domain names are separated in labels (label1.label2.tld) and use one hash table on each level.

Very early on I also considered skip lists, but a test showed that it didn’t beat the splay tree, so it got ditched. Radix tree were also ditched as I believe it will be quite hard to make it effective for such large keys.

I measured the performance of the three remaining structures using 1000000 random domain names, the numbers are an average of 10 runs. Code compiled with -O2, tests performed on a Pentium M 1.7Ghz. “add” refers to the time it took to insert 1000000 entries, and “find” refers to the time it took to find those 1000000 entries.

• Splay tree (sys/tree.h), add 4.90300 seconds, find 3.3907 seconds
• “Chained” hash table, add 7.62640 seconds, find 1.38780 seconds
• Hash table, add 2.19680 seconds, find 1.04970 seconds

The reason the chained hash table has such a bad add time is mainly because of malloc() call overhead in the hash table initiation for each level, there is code to reduce malloc overhead (pre-allocating a large chunk and splitting it) but it’s not enough. The hash table is self-growing and will double in size when any bucket hits a threshold number of collisions, experiments showed that up to about 10 collisions per bucket was reasonable. The tests above that included a hash table had a maximum hash table size of 131072 buckets, obviously by increasing the max size (trading memory for speed) you get better performance.

My initial doubts that a hash table would scale bad were not true, 1000000 entries is A LOT more than what the mdnsd responder will ever cache in practice, and because it’s self-growing it won’t waste a lot of memory. I guess I’ll use a hash table then.

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.

There are some initial information about the project on the FreeBSD wiki, I’ll try to keep it updated as time goes. The main priority is to get the responder running and to create a clean client API.

I already have some code, I just need to get the hang of perforce so I can submit it