Chapter 5. Service Discovery Beyond the Local Link

Zeroconf is designed to make it easy for you to discover services that are close to you. The word close can be ambiguous. You go to your neighborhood coffee shop and the people drinking their cappuccinos at the next table are physically close to you. You may be able to use a Zeroconf-enabled chat client, text editor, or audio application to interact with them, to collaborate on a document, or to listen to their music library. In the preceding three chapters, you have been introduced to the components of Zeroconf that are designed to allow you to painlessly discover and offer services to devices that are close to yourswhere close implies proximity in a network sense. Devices on the same link can use IP to communicate with one another and can present a list of available services in a user-friendly format.

As you drink your morning coffee, the person at the next table may be just a couple of feet away, but you may have never met them. They are not what you would describe as close in the sense of someone who is personally close, they just happen to be near you. There are many people who you might describe as being personally close: friends, family members, coworkers, and people you interact with on a regular basis.

If you are a Mac OS X user who uses iChat as your chat client, the differences in these two notions of close are reflected in the two windows you can use to find people to chat with. The Bonjour window shows you names of people on your local link who are available to chat. You may never have met these people and may not know their email addresses or chat usernames. If they have authorized the Bonjour connection, they just automatically appear in your Bonjour window. All that is required is that they have advertised a service of type _presence._tcp. Contrast this with your Buddy window. This only includes people who you have designated as buddies. These people may not be nearby, but they are people you are most interested in interacting with on a regular basis.

Chapter 4 described how DNS Service Discovery (DNS-SD) allows you to discover and to advertise services using PTR, SRV, and TXT records. In Chapter 4, we conveniently avoided the question of whether we were talking about Unicast or Multicast DNS. This was intentional, because it really doesn't matter. DNS-SD was created to work with both Unicast and Multicast DNS. Multicast DNS is perfect for small networks because of its zero-configuration nature. Instead of trying to predict where each query and announcement needs to go, it just sends them all to every peer on the network and lets the peers sort what they need. Clearly, this can't work on a global scale. If every machine on the Internet were busy sending packets that were replicated and delivered to every other machine on the Internet, every machine would be buried under an avalanche of unwanted traffic. Clearly, at a certain stage, we have to move out of the zero-configuration world and into the world of configuration and infrastructure. By building DNS-SD on top of Multicast DNS on the local network, that gives us a natural candidate for what configuration and infrastructure we should use when operating on larger networks: Unicast DNS. In most respects, the DNS-SD part of the protocol works just the same, regardless of whether it's running over Multicast DNS or Unicast DNS. The difference is that Multicast DNS is configuration-free and infrastructure-free, whereas Unicast DNS is more efficient on large networks but requires some configuration and infrastructure.

One configuration detail that needs to be worked out when using Unicast DNS is which domain(s) to use. When you browse on the local network, it's clear that the domain you want is local. When you browse on the global Internet, there are millions of domains to choose from. How does the computer know which to use? The answer to that question is Domain Enumeration , covered in this chapter. This chapter also covers how computers make service information available to other computers that may be thousands of miles away. It covers how computers get timely updates when that service information changes. Finally, whenever we talk about global networking in today's world, NAT (Network Address Translation) rears its ugly head. In the 1970s and 1980s, TCP/IP programmers never had to worry about NAT. Perhaps in the future, using IPv6, network programmers will again not have to worry about NAT. But, in today's world, NAT is a problem we can't ignore, and this chapter explains how wide-area service advertising deals with NAT.