Editor's note: In this first part of a short multi-part series, Mike Beam discusses some of the thinking behind Rendezvous (ZeroConf) and the hooks in Cocoa to implement its functionality into your application design. In next week's part two, he shows you how to build a simple chat program that attempts to provide functionality similar to iChat's Rendezvous chat feature.
As Cocoa developers, what do we need to know about Rendezvous? And how can we effectively use it in our applications? These are questions that I want to answer in today's column.
Rendezvous is so much bigger than many of us initially imagined. At least when I first heard about it, I wasn't as impressed as I am now. Apple is pushing this technology with everything they've got. They want -- indeed, they need -- developers on all platforms and manufacturers of all sorts of peripherals to look at Rendezvous and realize that this is something that will really make customers think "Wow, that is so cool." And it really is that cool.
As an example, consider what Derrick Story, the managing editor of our little corner of the Internet, has written about previously: how the folks in the O'Reilly offices have started using iChat as a tool for communicating with each other, quickly and efficiently. Communicating with one another with a chat program may not sound like much, as we can do that today without Rendezvous using any number of chat clients.
However, consider that iChat works simply by turning the power on. You don't need to set up IP addresses and host names, and there's no need to pass around your IM screename or collect those of your colleagues. It just works. You log into Rendezvous chat and immediately you see and are seen by everyone on the network running iChat.
Couple this with AirPort and the proliferation of laptops, and you get something really cool. Those of you who were at the Mac OS X conference got to see this in action on a large scale. Everyone had their laptops out, and you could simply open up iChat as described and see your buddy list instantly populated by all of these people around you and in other rooms. I haven't attended many tech conferences, but the impression I got from those who I talked to about it was that this sort of thing was unprecedented.
Not surprisingly, the idea of Rendezvous is as old as networking itself, and it has indeed existed in various forms over the years. AppleTalk is the most successful technology that provided a zero-configuration networking-like experience. But AppleTalk is built on proprietary technology, which must be supported by interested parties in addition to standard IP networking. And there were others, which never made a big splash. Basing ZeroConf on IP eliminates much of the work developers and peripheral manufacturers need to do to get it working with their product.
Rendezvous is platform-agnostic, which is a huge benefit to application developers like ourselves. Apple's open source implementation of Rendezvous is a relatively small collection of code, roughly 5000 lines of portable ANSI C. In this article, we're interested only in the Cocoa API to Rendezvous, but keep in mind while we work through this article that everything we do can be implemented on other platforms and made to interoperate with Cocoa implementations seamlessly.
In other words, I can publish a service using Cocoa's
NSNetService class, and pick up that service on a Windows or Linux machine with an application using the mDNS responder C API. This may seem obvious, but its important to realize that Rendezvous has no predisposition for Mac OS X; it doesn't care about your platform.
For us Cocoa developers, adding support for Rendezvous is a no-brainer. If your app gets put on the network, then it needs to advertise whatever it does using Rendezvous. Getting your app to work with Rendezvous is easy and painless. The Cocoa APIs for Rendezvous exist in the Foundation classes
NSNetServiceBrowser, and after spending a little time working with these classes, you will see how easy this stuff is. Before we get into the Cocoa, let's spend some more time discussing what was needed to make ZeroConf networking a reality.
Zero Configuration Networking
When we read up on the ZeroConf Web site, or almost anywhere else describing ZeroConf, we're presented with a set of problems that face users in their quest to connect computers to a network and have them communicate with each other usefully. When you want to do something on a network, the normal course of action is to somehow obtain an IP address for your computer. This is often accomplished by manually entering an IP address, which might be assigned to you at work by your systems administrator, or it might be one that you know will work on your home network. DHCP servers were designed to automatically hand out IP addresses to hosts, but you may not have one available, or the one you usually use may be down for the count.
Once you have an IP address and are connected to the network, users often have another problem: they have to keep track of, and remember, obscure numbers for the various hosts they use. People like to refer to things by name, not by numbers. So we assign to computers hostnames that we can type in to connect to them. But for this to work properly you need to either have a list of hosts and their addresses on your computer, so applications can translate between names and numbers -- because computers only like to work with numbers -- or you might have a domain name server somewhere on your network to do that job.
Raise your hand if you're running a DNS server on your home network. Not many people do. Moreover, even if you had a DNS server to translate hostnames into addresses, you may not have control over changing your hostname. People would rather be able to set their computer's name from their computer, and not have to track down the guy in charge to do it for them.
So you have a hostname, you're on the network, people know how to connect to you, you know how to connect to other people, and everyone is happy. Right? Well, you will want to make use of services that other people on the network are running from their computers, such as printing, file sharing, instant messaging, and so on, and people may want to make use of services you offer.
But to do that, you have to know about the existence of said services beforehand, along with the IP address of the host machine, or host name if they have one, and you have to communicate this information back and forth to people. Large, well-organized networks steer clear of this confusion by setting up directory servers that keep track of what services are offered where. For small, ad hoc networks though, you won't likely have a directory server.
ZeroConf tears down these barriers to networking for normal people by providing solutions the following three needs:
- A host should be able to obtain an IP address without a DHCP server.
- A host must be capable of translating between names and IP addresses without a DNS server.
- And finally, a host should be able to discover services on a network without a directory service server.
The Reader's Digest version of the above is that ZeroConf networking provides solutions to addressing, naming, and service discovery that conspire to make IP networking as easy-to-use as AppleTalk networking. We'll briefly address (pun intended) each of these areas in turn.
Pages: 1, 2