Section 10.3. Embedded Responders

10.3. Embedded Responders

On most general-purpose computers, there may be several different services advertising their presence via DNS-SD and several different clients browsing or resolving. On such computers, it makes sense to have a single shared daemon that all the clients and servers talk to.

However, if you're making a very simple single-purpose hardware device, then another API choice is available. If your device offers one and only one service or a small known set of services, and it offers those services from the moment it's powered on and boots up to the moment it's powered down, then you can save a bit of memory by dispensing with the background daemon and just having a single monolithic process that advertises your service(s). To write such a monolithic DNS-SD advertising process, you use the source code from Apple's Darwin mDNSResponder project, adding some code of your own to advertise the appropriate service(s). That code of yours interfaces directly with the core Multicast DNS functions defined in the mDNSEmbeddedAPI.h file. The mDNSResponder project's mDNSPosix folder contains some example code showing how to do this. For example, Responder.c builds a binary called mDNSResponderPosix, a single monolithic process that advertises one or more services.

If you're building a hardware device with very limited memory, then one of the benefits of using the raw mDNSEmbeddedAPI.h API is that it's malloc-free. That means that there is never a case where the code can suffer intermittent failures because the mDNSCore implementation calls malloc( ), and sometimes malloc( ) returns NULL because memory is so limited that no more is available. Instead, all the memory needs are precisely known in advance, and for each mDNSCore call, the caller is responsible for passing in a pointer to the storage that will be used in the execution of that call, in the form of a C structure defining that required storage. That storage can be a global variable, a local stack variable, a member of another enclosing structure, or allocated any other way the caller chooses. It can even be allocated via malloc( ) if the caller wishes, but the important point is that the decision about how to allocate that memory is in the hands of the caller. Because of this, all the mDNSCore calls (when called with correct parameters) are guaranteed to succeed, with no errors like "out of memory," "no more resources," or something similar. In the simple case of a device advertising a few known services, the easiest thing to do is just to declare each advertised service structure as a global variable, and then you know with certainty that there can't be any runtime failures because of memory shortage. At compile time, you know whether it's going to work, because you either have enough space for your declared globals or you don't. There's no runtime uncertainty.

This malloc-free operation is ideal for devices that need to have precisely known fixed memory requirements, with absolutely no uncertainty or runtime variation, but that certainty comes at a cost of more difficult programming. Generally, if your device has enough memory and runs a conventional general-purpose operating system like Linux, then using the standard mdnsd background daemon is the best choice. However, if that choice doesn't fit your product, then embedding mDNSCore and calling it directly with your own code may be attractive. If you do choose that route, you won't be alone. Most of today's Zeroconf hardware devices, such as printers and network cameras, do exactly that.