Preface
Two laptop computers sit less than two feet away from each other. They are so close they are nearly touching—and yet, until recently, as far as network communication is concerned, they may as well have been a thousand miles apart. Surely, communicating with a computer in the same room shouldn’t have to be as hard as communicating with one on the other side of the planet? Our modern l6aptop computers bristle with an astounding array of communications technologies—Ethernet, 802.11 wireless, FireWire, USB, Infrared, Bluetooth, and so on—yet to move a file between two computers two feet apart, 99% of computer users still use physical media. They copy the file onto a floppy disk, burn the file onto a CD, or copy the file onto a USB flash-memory drive. For the 1% who do manage to move the file using networking, most do so by emailing it from one computer to another, which sometimes entails the file traveling to another continent and back, just to move two feet. To do that, the file has to traverse the slow connection to the global Internet and back, at a speed typically a thousand times slower than local Ethernet. Furthermore, a vast infrastructure of services—DHCP, DNS, IP routers, SMTP relays, email servers, etc.—all have to be working perfectly for the transfer via email to succeed. If the DSL line is down, why should that stop two computers sitting next to each other from communicating?
For computer novices, the situation is puzzling and frustrating. If you can see both computers, why can’t the computers see each other? There are many ways of physically connecting two devices, but each way often requires its own custom software to do anything useful. If you have two computers with FireWire (also known as IEEE 1394), you can connect them with a FireWire cable, but...do you have any software for transferring files via FireWire? Do you know how to use it? You could connect two computers using the right kind of USB cable, but...would that do anything useful? You could aim the computer’s infrared windows at each other, but...do you have any software for transferring files via infrared?
When we communicate across the planet, we use TCP/IP, and we don’t care whether the physical connection is Ethernet or 802.11, DSL or cable modem, or a combination of those and other technologies. Could that give us the inspiration for solving the local communication problem? If we use TCP/IP, then it doesn’t matter what the physical connection is, as long as it can carry IP packets.
The missing link here is that while TCP/IP is certainly powerful enough to solve the local communication problem, historically it was not easy enough to use, leading to the proliferation of different physical interfaces mentioned above. It was almost as if computer designers thought that if only we had enough different kinds of hardware, the problem would be solved. What we really needed were not more different kinds of hardware, but better software.
Zero Configuration Networking, or, as Apple calls it, “Bonjour,” is that better software.
Zeroconf is the little missing link that makes TCP/IP on the local network as easy as USB. When you plug a Zeroconf camera into your Ethernet hub, it just shows up, as if by magic, in your Zeroconf web browser. It doesn’t matter whether you have a working DHCP server. It doesn’t matter whether you have a working DNS server. It doesn’t matter whether you have a working connection to the Internet. Zeroconf works anyway, even when some or all of that infrastructure is not working. One of the benefits of FireWire and USB is that they can supply power over the cable, but with the advent of the IEEE 802.3af (“Power over Ethernet”) standard, modern Ethernet hubs can do that too. A Zeroconf IP camera is as easy to use as a USB camera, except that because it uses IP, it’s not tied to one particular physical connection technology. You can be sitting on the sofa with your laptop computer using 802.11 wireless, and the same Zeroconf Ethernet camera shows up in the same web browser, because even though they use different physical technologies, they speak the common language of IP. The web browser doesn’t care what physical link-layer connection your computer is using. As long as it carries IP packets, it works.
Finding a TCP/IP printer on the local network is now as easy as using a directly attached USB printer. On Mac OS X, you just look in the print dialog and see a list of available network printers. Using Apple’s “Bonjour for Windows,” you just run the Printer Setup Wizard, and it shows you the same list of available network printers. If you visit a friend’s house, one of your company’s other office locations, or a hotel’s business center, you don’t need to ask for help finding the printer anymore. Just look in the print dialog, and there it is.
Returning to our file-transfer example, now that we know we have a working IP network, no matter what, we have a wealth of IP-based choices. Even the venerable old 1970’s File Transfer Protocol (FTP) can benefit from Zeroconf. On Mac OS X, the built-in FTP server already advertises its presence using Zeroconf, and every third-party Mac OS X FTP client now uses Zeroconf to browse for FTP servers, so connecting to an FTP server is now as easy as running your preferred FTP client and picking the desired server from the Zeroconf list.
Other kinds of data sharing are easily facilitated using Zeroconf. If you want to let other machines and devices in your house play music from your computer, iTunes can advertise your music collection using Zeroconf. iPhoto can advertise selected photo albums using Zeroconf so that LCD picture frames hanging on your walls can display them. iChat can advertise your presence on the local network using Zeroconf, and—while we’re talking about file transfer—dropping a file onto a Bonjour iChat window is a more direct way of getting a file to someone than emailing it via the public Internet. Finally, if you’re collaborating on a document with someone, a multiuser document editor such as SubEthaEdit (which allows multiple people to simultaneously edit a file) is a much more direct way to collaborate than transferring the file back and forth all the time.
All of these data-sharing applications were, in principle, possible before Zeroconf. However, the difficulty of making them work meant that, in practice, people were going to resort to the good old floppy disk. Furthermore, software like SubEthaEdit simply didn’t get written back then, even though, in theory, there’s no reason it couldn’t have been. Local TCP/IP networking was like a complicated machine with no oil. All the right pieces were there, and it looked like it should work, but it took so much effort to get the wheels to turn that almost no one bothered. For communication on the worldwide Internet—for the Web and for email—the pain of TCP/IP was clearly worth it, but for local-area communication people gravitated toward other solutions that offered the promise of better ease of use.
Zeroconf is not some huge, complicated piece of software. It’s a small collection of simple ideas that act like the missing lubricant for the TCP/IP machine. Now that people see how easily the wheels turn, they suddenly begin to see all the useful applications of TCP/IP for short-distance communication around the home, around the office, and even around the desktop. TCP/IP is not just for the Internet any more.
Having transformed local-area TCP/IP networking, people realized that Zeroconf’s DNS-based Service Discovery mechanisms could be taken back and applied to the wide-area Internet too. Being able to simply browse to find the list of printers on the local network was so useful that people wondered why they couldn’t browse to find printers at a specified remote location too, and Wide-Area DNS Service Discovery was born. When staying in a hotel, Zeroconf allows you to see printers being offered by that hotel on its local network, and, with Wide-Area DNS Service Discovery, you can also see printers at your home or office, should you wish to print on one of those instead.
This book provides an in-depth look at the components of Zeroconf technology and a survey of the programming APIs that will allow you to Zeroconf-enable your product.
Audience for This Book
This book is written for curious users, for software developers, and for hardware developers. Many of the screenshots show images taken from Mac OS X, but that’s primarily a reflection of the fact that both the authors primarily use Mac OS X. Don’t be misled into thinking this a Macintosh programming book. The concepts and programming examples given in this book are almost exclusively cross-platform. The Zeroconf Multicast DNS daemon and APIs are available on Mac OS X, Windows, Linux, Solaris, FreeBSD, etc. The dns-sd command-line tool is available on all those platforms, as are the dns_sd.h C programming API, the Java™ API, and the other interfaces for languages like Ruby and Python. Just one chapter, Chapter 9, covers APIs that are specific to Mac OS X.
For curious users who want to understand the technology used by iChat, iTunes, iPhoto, network printing, SubEthaEdit, and countless other applications, this book explains the Zeroconf technology.
For software developers making networking applications, this book explains how you can, with very little effort, make your software a lot easier to use. Going beyond that, this newfound ease-of-use means that previously infeasible software products now become viable. Imagine iChat’s local Bonjour Window if you had to type in the IP address of each peer you wanted to chat with. It would be pointless. No one would do it, and there would have been no point even having that feature in the first place. Compare that with iChat as it is today, where it automatically discovers all the local peers on the network and displays them in a list. Now it suddenly becomes a lot more interesting, and that feature becomes worth implementing.
For hardware developers currently making IP-based hardware devices, the message is very similar. This book explains how you can, with very little effort, make your devices a lot easier to use. This translates into thinner manuals, lower support costs, and lower return rates. Those effects, in turn, mean that products that previously would not have been economically viable, because of support costs and product returns, can now be profitable. It was not so long ago that a networked printer cost over $1,000. This was not because an Ethernet chip and some IP software cost that much more than a USB chip. No, it was because of the higher support costs and return rates for these products. Zeroconf cuts those support costs and return rates, and, these days, Zeroconf-enabled Ethernet printers are available for about $100. In many cases, what Zeroconf offers is plain and simple: enhanced functionality. When devices on a network can automatically communicate, advertise, and discover services for themselves, things become possible that simply wouldn’t happen if humans had to configure everything manually. Sharing idle CPU cycles on the network has long been a popular idea, yet still, as a percentage of all computer users, very few people make the effort to find out how to make that work. If, instead, all the user had to do was just click a checkbox saying “Share my idle CPU cycles,” and Zeroconf automatically did the rest, then CPU sharing could become commonplace instead of remaining a rare novelty.
For hardware developers currently making nonnetworked hardware devices, this book explains how you can add the benefits of TCP/IP networking to your products without having to sacrifice ease of use. The marketplace today is full of computer peripherals that connect through serial, USB, FireWire, or similar technologies, but all of these technologies require the device to be tethered to some host computer. Devices that connect via Ethernet or 802.11 wireless interfaces can be accessed by any computer anywhere in the house, but the pain associated with TCP/IP has always been a strong disincentive. By removing that pain, Zeroconf means it’s now practical for many of these serial, USB, and FireWire products to migrate to Ethernet or 802.11 wireless interfaces instead.
The Zeroconf Technology
At a technical level, Zeroconf is a combination of three technologies. What’s more important though is that at a user-experience level, Zeroconf is about making products that “just work.” Setting up a network device should be as easy as setting up a new table lamp—you plug it in, you turn it on, and it works. It’s important to keep that top-level requirement in mind. At the end of the day, the technologies are the means to the end, not the end in itself. While proper implementation of the specifications is important, that alone is not enough—a worthwhile Zeroconf product is one that embodies the spirit of Zeroconf, not just the letter of the specifications. With that said, our goal can’t be achieved without the right technologies. For years, people wished that computers and network devices were easier to use, but wishing it were so did not make it so. Zeroconf is, therefore, about two things: it’s about the top-level goal—making products that are truly easy to use—and it’s also about the supporting technologies that make that possible. The three technologies that make Zeroconf work are link-local addressing, Multicast DNS, and DNS Service Discovery.
Link-local addressing is described in Chapter 2. To do any IP networking, a computer needs an IP address, and most computers today normally get one using DHCP. DHCP is a perfectly good protocol, and link-local addressing is not competing with that. Link-local addressing is better viewed as a safety net. When DHCP fails or is not available, link-local addressing lets a computer make up an address for itself, so that it can at least communicate on the local link, even if wider communication is not possible. In the case of devices with no screen or keyboard that are configured solely over the network, this is especially important. If they were to get into a state where they lost all ability to communicate, even on the local network, then there would be no way to communicate with the device to fix the misconfiguration that’s causing the problem.
Multicast DNS is described in Chapter 3. Ensuring that every computer and network device always has a usable IP address, no matter what, is a good first step, but that alone is not sufficient to provide a good networking experience. Human users want to refer to computers and devices using names, not numeric addresses. On the Internet today, devices are named using the Domain Name System (DNS). DNS is a wonderful system and works really well. Multicast DNS is not competing with that. Like link-local addressing, Multicast DNS is a safety net, so that when conventional DNS servers are unavailable, unreachable, misconfigured, or otherwise broken, computers and devices can still refer to each other by name in a way that’s not dependent on the correct operation of outside infrastructure.
DNS Service Discovery is described in Chapter 4. The two technologies mentioned above get us a lot—now we can refer to a device by name and communicate with it, even when the rest of the network is broken—but we want more. Back in the 1980s and 1990s, in the days of AppleTalk, using an AppleTalk network printer didn’t entail having to ask someone the name of the printer, remember it, and then type it in correctly without making a mistake. No, those old enough to remember AppleTalk will remember that you just looked in the Printer Chooser window, saw a list of informative names, and clicked on the one you wanted to use. We want the same thing on today’s IP-based networks. DNS Service Discovery provides that capability. Because it’s built on top of DNS, it works not only with our new Multicast DNS (for discovering local services) but also with good old-fashioned, wide-area Unicast DNS (for discovering remote services). Using DNS Service Discovery, the printing software on your computer can conceptually ask the network questions like the following: “I know how to generate PostScript and print it over the network using the LPR protocol. Who out there is willing and able to accept that?” Each printer on the network that is able to accept print jobs via the LPR protocol metaphorically raises its hand and says its name, and that list of names is then presented on the screen for the user to choose from.
Chapter 4 introduces the concepts of DNS Service Discovery and focuses on how it applies to discovering services on the local link using Multicast DNS. Chapter 5 then shows what’s involved in extending it to the wide-area Internet, using Unicast DNS. There are two facets to this: outward looking and inward looking. The outward-looking aspect is that when you’re away from home or the office (e.g., sitting in a coffeehouse with your laptop computer), you can still discover services at your home or the office. The inward-looking aspect is being able to run services on your own computer and advertise them so they are discoverable and usable by others. For example, you may want to let work colleagues many miles away view and contribute to a document you’re editing; you may want to let family members in distant cities view your shared photo albums; or you may want, yourself, to be able to access files on your home computer while you’re at work.
Those three technologies are the foundation that Zeroconf provides. What Zeroconf offers you, as a software writer or hardware designer, is:
The assurance that your software or hardware will always have functional IP networking, no excuses
The ability to discover what services other devices on the network are offering
The ability to advertise the services your device offers to the network
Zeroconf doesn’t dictate how you should write your software or design your protocol. Zeroconf doesn’t dictate whether your protocol should be message- or RPC-oriented, or whether it should be binary, text, XML, or something else. Because it is agnostic to protocol design details, Zeroconf provides a foundation that any IP-based protocol can use, from protocols as ancient as FTP and Telnet to future protocols and products not yet imagined. If you have an existing product that uses TCP/IP, then adding Zeroconf to it is a trivial programming task that gives a huge improvement in usability and reliability. More than once, companies have added Zeroconf to their products with as little as one day’s work by one engineer.
Once you understand the ins and outs of the Zeroconf technology, you are going to want to know how to use it for yourself and how to add it to the software or hardware that you make.
The Zeroconf DNS Service Discovery APIs
Unless you’re an operating system vendor or a hardware maker, the first two layers of Zeroconf technology—link-local addressing and Multicast DNS—should be provided for you by operating system components or add-ins. On Mac OS X, they are built-in. On Windows XP, they are provided by Apple’s “Bonjour for Windows.” On Linux and other Unix platforms, this functionality is available using Apple’s Darwin code or a variety of other implementations and is already included in some newer Linux distributions.
Understanding how link-local addressing and Multicast DNS work is valuable background information, but when it comes to actual programming, most programmers will interact with Zeroconf through the DNS Service Discovery APIs in their chosen language.
Chapter 6 introduces the dns-sd command-line tool that lets you experiment with Zeroconf service advertising and discovery before you actually write your first line of Zeroconf code.
Chapter 7 introduces the C API for advertising and browsing for services. The same C API exists on Mac OS X, Windows, Linux, and all the supported Unix platforms. In Apple’s implementation, all the other APIs are layered on top of the C API. In much the same way as Java sockets on most platforms are implemented by making use of the kernel’s native sockets support, Java’s DNS-SD API is built on top of the common C API that exists on all supported platforms.
Chapter 8 explains the Java API, which lets you write portable cross-platform programs that will run on any supported platform that has Java and Zeroconf installed.
Chapter 9 describes two of the Bonjour APIs that are specific to Mac OS X: CFNetServices and Cocoa’s NSNetServices.
Chapter 10 rounds out the review of APIs, outlining the Zeroconf support appearing in some unexpected languages like Ruby and Python. In fact, the Python support for Zeroconf was built using a technology called Simplified Wrapper and Interface Generator (SWIG, http://www.swig.org/), so that single piece of work means Zeroconf service discovery is now accessible from a wide variety of well-known and lesser-known programming languages, including Tcl, Perl, Scheme, PHP, Objective Caml, Pike, C#, Allegro Common Lisp, and Modula-3.
Conventions Used in This Book
The following typographical conventions are used in this book:
- Plain text
Indicates menu titles, menu options, menu buttons, and keyboard accelerators (such as Alt and Ctrl).
- Italic
Indicates new terms, URLs, email addresses, filenames, file extensions, pathnames, directories, and Unix utilities.
-
Constant width Indicates commands, options, switches, variables, attributes, keys, functions, types, classes, namespaces, methods, modules, properties, parameters, values, objects, events, event handlers, XML tags, HTML tags, macros, the contents of files, or the output from commands.
-
Constant width bold Shows commands or other text that should be typed literally by the user.
-
Constant width italic Shows text that should be replaced with user-supplied values.
Using Code Examples
This book is here to help you get your job done. In general, you may use the code in this book in your programs and documentation. You do not need to contact us for permission unless you’re reproducing a significant portion of the code. For example, writing a program that uses several chunks of code from this book does not require permission. Selling or distributing a CD-ROM of examples from O’Reilly books does require permission. Answering a question by citing this book and quoting example code does not require permission. Incorporating a significant amount of example code from this book into your product’s documentation does require permission.
We appreciate, but do not require, attribution. An attribution usually includes the title, author, publisher, and ISBN. For example: "Zero Configuration Networking: The Definitive Guide, by Stuart Cheshire and Daniel H. Steinberg. Copyright 2006 O’Reilly Media, Inc., 0-596-10100-7.”
If you feel your use of code examples falls outside fair use or the permission given above, feel free to contact us at [email protected].
Comments and Questions
Please address comments and questions concerning this book to the publisher:
| O’Reilly Media, Inc. |
| 1005 Gravenstein Highway North |
| Sebastopol, CA 95472 |
| (800) 998-9938 (in the United States or Canada) |
| (707) 829-0515 (international or local) |
| (707) 829-0104 (fax) |
We have a web page for this book, where we list errata, examples, and any additional information. You can access this page at:
| http://www.oreilly.com/catalog/bonjour |
To comment or ask technical questions about this book, send email to:
| [email protected] |
For more information about our books, conferences, Resource Centers, and the O’Reilly Network, see our web site at:
| http://www.oreilly.com |
Safari Enabled
When you see a Safari® Enabled icon on the cover of your favorite technology book, that means the book is available online through the O’Reilly Network Safari Bookshelf.
Safari offers a solution that’s better than e-books. It’s a virtual library that lets you easily search thousands of top tech books, cut and paste code samples, download chapters, and find quick answers when you need the most accurate, current information. Try it for free at http://safari.oreilly.com.
Acknowledgments
Stuart Cheshire
My thanks go to Dan, my able coauthor, without whom this book would not exist. Thanks also to Mike Loukides, our editor, for striking the right balance between patience and impatience, without which this book would never have been finished. Thanks especially to Tim O’Reilly, who saw the promise of Bonjour/Zeroconf (or Rendezvous, as it was then) from the very start and persuaded me to publish an O’Reilly book on the subject.
Thanks to all the people who, through their own initiative, enthusiasm, and efforts, helped make Bonjour a success. Thanks to Kiren Sekar, for his work on the conformance test, the C API, and wide-area Bonjour; to Marc Krochmal, for immeasurable contributions in countless areas; to Craig Keithley, for his tireless evangelism efforts; and to Angie Sticher, Vincent Lubet, and Howard Miller, for their organizational contributions. Thanks to Josh Graessley and Dieter Siegmund, for providing the necessary kernel support, including IPv4 link-local addressing; to Quinn, for the initial Linux support; to Roger Pantos, for the mdnsd daemon for Linux and for the Java APIs; to Bob Bradley and Scott Herscher, for Bonjour for Windows; to Rich Kilmer, for the Ruby APIs; to Thomas Uram, for the SWIG interface definition file; and to Erik Guttman and Bernard Aboba, my coauthors on RFC 3927, the IPv4 link-local addressing specification.
Thanks for their various contributions are also owed to: Mike Bell, Richard Blanchard, Leigh Blankenship, Rob Braun, Joyce Chow, Mike Culbert, Paul Danbold, Moe Gharahgouzloo, David Harrington, Dave Heller, James Higa, Arthur van Hoff, Joe Holt, Jordan Hubbard, Brian James, Deep Jawa, Bryan Johns, Rod Lopez, Jim Lovell, Kevin Marks, Rob Newberry, Juliette Noh, Chris Parker, Eric Peyton, Jeff Robbin, David (“Lefty”) Schlesinger, Bud Tribble, Andrew White, James Woodyatt, and Jeremy Wyld.
Thanks to my wife, Pavni, and daughter, Ishani, for their patience while I worked on the book.
Thanks to Lewin, Marta, Ed, and the rest of the staff of the Progresso coffeeshop on Portobello Road, for my twice-daily cappuccinos while I worked on the book.
Thanks also to Simon Patience, Bertrand Serlet, and the rest of my Apple management and colleagues, for giving me this opportunity.
Daniel H. Steinberg
My biggest thanks go to Stuart Cheshire for creating such a nice piece of technology and for coauthoring this book. I remember seeing the demo of Bonjour (then under a different name) at Apple’s Worldwide Developers Conference. It was immediately compelling. Bonjour was one of those ideas that was both obvious and groundbreaking. The underlying ideas were solid and the implementation was impressive. In addition to his contributions as an engineer, he is a careful author who explains precisely what he means to say in an easily understood manner.
Thanks also to Apple employees: Marc Krochmal, for answering all of my questions and for providing code samples that illuminated the corners of the technology; Roger Pantos, for his work with the Java API and his cheerful answers to questions; Bob Bradley, for his help with the examples for the Windows event loop; and David Gleason, for being such a helpful member of the Apple Developer Connection.
As always, many thanks to my wife, Kim. No book project would be possible without her help and support. My daughters, Maggie Rose and Elena, tested the software examples in this book and showed that Bonjour can be intuitive to a six- and an eight-year-old. As we were preparing to write this book, I was hired by O’Reilly Media to launch the http://java.net web site. Thanks to the great team on the O’Reilly side for making that site, and our http://onjava.com and http://dev2dev.com sites, so successful. In particular, thank you Sarah Kim, Tony Stubblebine, David Lents, Jon Mountjoy, Derrick Story, Miky Vacik, and Greg Dickerson. Bruce Stewart is the best boss I’ve ever had. I wish I’d learned earlier in my career the importance of having such a great manager. I have also worked closely with his boss, Nancy Abila, and appreciate how she also makes it possible for me to do my best work.
Chris Adamson and I have worked together on the O’Reilly Java web sites during the entire writing of this book. He has written two books during that time and has supported me during the writing of this book. Finally, thank you to Mike Loukides, who edited this book with the right amount of pushing and encouragement.