Chapter 10. Ruby, Python, and Other Languages

The preceding chapters covered the DNS Service Discovery programming APIs developed primarily by Apple's engineers, which include both cross-platform and Mac-specific APIs. The cross-platform C and Java APIs are available on Macintosh, Microsoft Windows, Linux, FreeBSD, Solaris, and other Unix variants. The Mac-specific Core Foundation API and Cocoa API are available for programmers writing software designed solely for Mac OS X.

Those are just the tip of the iceberg. There exist a range of open source projects (e.g., ones that implement higher-level DNS Service Discovery API layers built on top of the C DNSServiceDiscovery API foundation provided by Apple), some of which complement Apple's work, and some of which overlap or even compete with it. This is made possible by the careful separation of the background daemon and the client library in Apple's own implementation of Multicast DNS and DNS Service Discovery.

The first component is a background daemon, which runs in its own address space and implements all the protocol logic, timing, packet sending and reception, record caching, and similar functionality. The second component is the client library, which client applications link with, in the application's address space, in order to communicate with the background daemon. Apple's background daemon is licensed under the Apple Public Source License 2.0, an FSF-approved open source license. Apple's client library is licensed under an even more liberal three-clause BSD-style license, which allows it to be used in just about anything, from the most secretive proprietary products to the most resolutely open projects using open source licenses such as the GNU Public License (GPL).

This separation into two components offers benefits both technical and legal. The technical benefit is that all the client programs on a machine get the efficiency benefit of sharing a common protocol engine and a common record cache. Also, if a client advertising a service crashes, the daemon detects that and sends the goodbye packet to de-register the advertised service. From a legal standpoint, this separation allows greater freedom for everyone involved. The background daemon is separated from its programming interface, so other independent implementations of the background daemonwith different characteristics and licensing termsare possible. Meanwhile, the client library, the interface a client program uses to communicate with the daemon, doesn't have to change. Commercial software vendors can link with Apple's client library without the fear of "tainting" sometimes associated with linking GPL libraries, and, at the same time, authors working on GPL programs can also safely link with Apple's client library without fear that they might be violating the strict terms of the GPL.

Similarly, programmers can create their own layers built on top of the C client API, with the freedom to license them as they choose, while users are free to mix and match components as best meets their needs. The key to this flexibility is that as long as all the client layers build on top of the common C APIwith its BSD-style licensethen all a programmer needs to do to create an alternative daemon implementation is to create a background daemon offering that standard C API, and all of the higher-level client programs and API layers can work with it without change.

In this chapter, we cover two of those higher-level third-party DNS Service Discovery API layers built on top of the C DNSServiceDiscovery API foundation. The first is a language binding for the Ruby programming language. The second is a more general-purpose interface specification written for the Simplified Wrapper and Interface Generator (SWIG), which is used to generate interfaces automatically for a range of languages. That range of languages includes Java and Ruby, which might make you wonder why there are also specific APIs for those languages. The answer is that SWIG does a fairly mechanical translation of the C interface into other languages, yielding an interface with the same basic operating model. For example, just as calls in the C interface hand you back a file descriptor, which you add to your event loop, the SWIG-derived interfaces do the same. In contrast, the specific APIs for Java and Ruby both take advantage of those languages' inherent multithreading support to provide callbacks that are invoked automagically on some other thread. We explore the SWIG interfaces from the perspective of the Python programming language, which doesn't have its own handcrafted API at this time.

Finally, this chapter wraps up with a brief mention of the mDNSEmbeddedAPI.h interface, used by hardware devices that don't really need the benefits of an independent mdnsd background process and instead use a monolithic piece of software dedicated to advertising the services of that device, using the core Multicast DNS functions directly.