shapeshifter.se

Yep, mdnsd speaks now, actually it has been able to do that for a couple of weeks but I just got probing and announcing working as I wanted it to.

I ended up rewriting most of the record database and I think I’ve ironed out most bugs now, and it now follows the variable system (which in turn follows the system state). Here is a sample mdnsd.conf that creates a resource with the name “hostname”.local (where hostname is the actual hostname of the machine), in case this name is already in use, it fall backs to “hostname-ifname”.local. To this rrset it will claim/announce A records for all IPv4 addresses configured on this interface, it also claims/announces AAAA records for all configured IPv6 addresses. It also announces matching PTR records for each A/AAAA record, this introduced a new feature that allows the resource data of a record to be a “pointer” to an existing rrset name. This allows the PTR records to follow whatever name that’s configured on the A/AAAA records.

I also rewrote most of the packet construction. Previously I wrote the raw packets directly when a rrset/qset was added, this however led to problems with the DNS name compression code when records where added “out-of-order”. Therefore, instead of writing the raw packets directly, I introduced an abstract type struct mdns_{rrset,qset} {} which holds the resource data for a record. Basically one acquires a rrset/qset object, fills it with the resource data and adds it to the packet, but instead of writing it to the packet buffer it’s simply added to a list. The raw packets is created from this list first when mdns_pkgchain_finalize() is called, this also has the neat side effect that packet construction becomes quite light weight (and thus, should speed up parsing of received packets as response construction becomes lighter) and the last heavy weight finalize step is moved into the output queue (which will run in a separate thread).

To avoid large malloc()/free() overhead when acquiring rrset/qset objects I also added an “object allocator” which allocates various types of fixed sized objects that the daemon requires, when an used object is released back to the allocator it does not immediately free the used memory, instead it simply puts it on a free list for further use, memory is reclaimed when an object hasn’t been used for a certain amount of time.

There is even more technical mumbo-jumbo (an multicast output aggregation queue, probing/announcing restarts on affected records when system state changes, etc) but let’s see mdnsd in action instead. The daemon is running with the sample configuration file, my FreeBSD machine hostname is “nexus”, let’s demonstrate it with a ping from a Mac OS X machine.

Welcome to Darwin!shiva:~ fli$ ping nexus.local.PING nexus.local (192.168.1.100): 56 data bytes64 bytes from 192.168.1.100: icmp_seq=0 ttl=64 time=0.285 ms

And, what did mdnsd say

mdnsd: pkgprocess: Packet received peer=192.168.1.98, port=51909, if=em0mdnsd: pkgprocess: type=query, questions=1, answers=0, authority=0mdnsd: process_query: question for nexus.local., type=1, unicast=0, legacy=1mdnsd: process_query: Found nexus.local. in database, responding

and the tcpdump output

12:23:44.049848 IP (tos 0x0, ttl   1, id 16358, offset 0, flags [none],  proto: UDP (17), length: 57)  192.168.1.98.50636 > 224.0.0.251.5353:  38575+ A? nexus.local. (29)12:23:44.050858 IP (tos 0x0, ttl 255, id 59663, offset 0, flags [none],   proto: UDP (17), length: 73) 192.168.1.100.5353 > 192.168.1.98.50636:   38575*- 1/0/0 nexus.local. A 192.168.1.100 (45)12:23:44.051052  IP (tos 0x0, ttl 255, id 59664, offset 0, flags [none],  proto: UDP (17), length: 67) 192.168.1.100.5353 > 224.0.0.251.5353:  0*- [0q] 1/0/0 nexus.local. A 192.168.1.100 (39)

There is two responses, one unicast and one multicast, the unicast response was sent because the client needed it and the multicast response was sent because it was “long” time since we last multicasted this record.

What’s very funny is that Mac OS X doesn’t seem to have integrated their resolver library with their responder, and thus does not benefit from opportunistic caching when simply resolving names, they even do legacy type queries (the term used in the specs). The machine runs Mac OS X 10.4.9.

Darwin shiva.int.shapeshifter.se 8.9.0 Darwin Kernel Version 8.9.0:Thu Feb 22 20:54:07 PST 2007;root:xnu-792.17.14~1/RELEASE_PPC Power Macintosh powerpc

I could continue and show some neat tcpdumps from the probe/announce steps, but that would probably only get boring, so let’s call it a post shall we. Now I’m going to continue with the last large piece of the puzzle which is the local client side that actually enables applications to use the daemon.

This entry was posted on Monday, July 16th, 2007 at 12:36 pm 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.