Section 1.2. Replacing the AppleTalk Name Binding Protocol


1.2. Replacing the AppleTalk Name Binding Protocol

At the end of any software engineering effort, the developers have a deep understanding of the problem they were solving. Imagine how much better the finished product would be if they had time to start over with the benefit of the experience they have gained. The DNS Service Discovery (DNS-SD) layer of Zeroconf builds on years of experience with AppleTalk and its Name Binding Protocol (NBP) and improves on the earlier technology while building an all-IP solution.

Why IP?

Over the last 30 years, many protocols have competed in both the wide-area networking (WAN) and local-area networking (LAN) arenas. In the WAN arena, it is clear that IP won, and even in the LAN arena, IP is rapidly gaining ground. When people have networks within their homes today, using Ethernet or IEEE 802.11 wireless, it is generally IP that they use most over those networks, rather than other protocols like AppleTalk or NetBEUI. The last remaining place where non-IP protocols still thrive is in short-distance links tethered close to the computer, but even these are showing signs of migrating to IP. USB, FireWire, and Bluetooth all now have ways to carry standard IP packets in addition to their own various task-specific protocols. To illustrate with just one example, when using the native file copying protocols, copying files between two computers using Bluetooth uses different software and a different user interface than copying over FireWire, which is different than copying over USB, and so on. In contrast, when using IP over those same physical links, any given software application (e.g., FTP) works exactly the same way, regardless of whether the underlying hardware is USB, FireWire, Bluetooth, Ethernet, 802.11, or something else.

What made USB and FireWire attractive compared to IP for short-distance communication is that they are relatively easy to use and hassle-free. With Zeroconf bringing the same convenience and ease of use to IP, one of the last remaining objections to using IP for short-distance communication, as well as wide-area communication, has been eliminated.


AppleTalk NBP communicated the available services in a way that was logically consistent with an end user's perspective. Additionally, NBP allowed users to perform an action using a connected device without needing to know the device's address and without needing to become their own network administrator. Although DNS-SD is not simply a rewrite of AppleTalk NBP, there are many things that NBP got right, and DNS-SD brings those properties to IP networking.

1.2.1. Name Services, Not Hardware

In AppleTalk NBP, the primary named entity is not a piece of hardware or even a piece of software but a logical service with which you can communicate using a particular specified protocol. There is little benefit for the average user in being able to locate and connect to a device if she cannot communicate with it. The implication is that it is most useful to name entities with which you can communicate. DNS-SD maintains the same philosophy, naming logical services as the primary entity on the network. Continuing this philosophy further, it is important not only what the service does, in a human sense, but what network protocol it uses to do it, since there's no use discovering it if your client can't talk to it. For example, when you use a web browser to view a web site with the URL www.example.com, you generally do not know or care much which particular device is answering your request. What you care about is that it speaks Hypertext Transfer Protocol (HTTP), and that the content it sends you is something your web browser knows how to decode and display, typically Hyper Text Markup Language (HTML), and that the content relates to the example.com domain.

Suppose you are interested in locating web sites hosted on your local network. Suppose you could find the IP addresses of all nearby machines. Then what? You could try to contact them with your web browser using the well-known port 80. But it is certainly possible for a single device to host more than one web site, listening on different ports. What you really want is a different sort of browser that could locate all local services that offer HTML over HTTP. Zeroconf's DNS-SD allows these services to advertise themselves as offering HTML over HTTP and provide their name, IP address, and port number.

Reaching a Device Versus Using It

In the early days of computers, files saved from one word processor couldn't be read by another. Merely having access to the file was not enoughto properly interpret it, the software had to also understand the language used to encode all of its formatting and other information. Similarly, merely being able to create a TCP connection to a device is not sufficient to use it. The client and the service need to speak the same language (i.e., network protocol) to communicate usefully.


Historically, Internet protocols have assumed so-called "well-known" port numbers. When you look up the address of www.example.com, the Domain Name System tells your computer the IP address of the machine to contact but not the TCP port number. The historical solution to this problem is that your web browser assumes that the desired web server must be listening on TCP port 80. If it's not (e.g., because two web server processes are running on the same machine and they can't both use the same TCP port), then blindly assuming TCP port 80 won't work. You have to manually override the default port, as in http://www.example.com:1234. While that may superficially seem to work, it has problems. Once you've published that URL, if you change the port number the server is listening on, the URL will stop working. It's fragile, like publishing a URL with a fixed dotted-decimal IP address embedded in it instead of a DNS name.

Another problem with "well-known" port numbers is that if every new protocol gets its own reserved number, we're in danger of running out. You can see the currently assigned port numbers at http://www.iana.org/assignments/port-numbers. Thousands are already reserved for applications you will probably never run on your computer.

Zeroconf's DNS-SD solves this problem by using DNS "SRV" records, which tell the client the service's port number as well as its IP address, obviating the need for pre-allocated "well-known" port numbers. Any service can use any available port on your computer and advertise its port to prospective clients along with its IP address.

1.2.2. Late Binding

AppleTalk NBP has a mechanism for browsing the network for services, but, as its name emphasizes, it is primarily a Name Binding Protocol. Its primary function is binding human-meaningful names to computer-meaningful network addresses. A human user will use the browsing capabilities to locate a service initially, such as selecting a default printer, but every time the name service is used subsequently, the Name Binding Protocol is used to find out the current network address and port number for that service. This means that even if the printer address changes, clients will still be able to connect to it at the new address without disruption.

This late binding of a name to an address is an important feature of a technology intended to replace AppleTalk. If a service is available on a network that uses DHCP or link-local addressing, there is no guarantee that the device hosting the service will have a consistent IP address. When ports are allocated dynamically, there's no guarantee the service will always be running on the same port. Late binding ensures that the client attempts to connect to the current IP address and port number.

1.2.3. Finding Named Services

Service requests consist of asking for a service of a particular type in a particular domain. This builds on the AppleTalk convention of using names structured as Name: Type @ Zone. The Zone in AppleTalk NBP corresponded to some logical grouping based on location ("Third Floor") or organizational classification ("Sales"). The equivalent concept in DNS is a subdomain, such as sales.example.com or thirdfloor.example.com. These replacements for zones provide an independent namespace so that there is no confusion in printers with the same name that are located in different zones.

In AppleTalk NBP, the Type identified the protocol that the service speaks. So, for example, the NBP Service Type "LaserWriter" denotes a service that speaks PostScript over AppleTalk Printer Access Protocol over AppleTalk Transaction Protocol over AppleTalk Datagram Delivery Protocol. The equivalent DNS-SD service type might be _ipp._tcp, which indicates a printer that speaks the Internet Printer Protocol (IPP) over TCP over IP.

Built to Last

Application-layer protocols come and go. A service discovery protocol is a more foundational technology and cannot be built on a faddish technology. There are Zeroconf APIs for a wide range of languages to support programmers using everything from C, C++, Java, and C# to Perl, PHP, and Ruby. The Zeroconf daemon runs on Mac OS X, Linux, Windows, and various flavors of Unix. Zeroconf is agnostic to application protocol design; it can advertise any kind of application protocol, from ancient ones such as Telnet and FTP to future application protocols not yet imagined.


The Name portion should be a user-friendly name. With this approach, the names are both long and descriptive. The end user will be employing a browser of some sort to select named services from a list. As they will not have to type the service name every time they want to use a service, the names should not be cryptic for the sake of making them shorter. So, for example, there could be a service with the full name 3rd Floor Meeting Rooms._ipp_tcp.examples.com. Notice that the service name can contain spaces as well as dots, percent signs, and other symbols. The character set is also not restricted to US-ASCII; users are free to choose names using any legal Unicode characters.

Name Conflict Detection

Without a central network administrator, there is a possibility that two devices may want to use the same name. Because Zeroconf requires that the devices be self-configuring, the devices have to be able to sort out the conflict themselves. For example, you may buy two printers and connect them into the same network. They ship from the factory with the same name, "CompanyX Printer." When the second one is connected and a conflict is detected, the second one needs to choose another name, such as "CompanyX Printer (2)." If the human user prefers to have a more descriptive name, most printers provide a web-based interface or something similar that allows the user to enter a descriptive name of his choice to identify the printer. On devices such as laptop computers, which are designed for human interaction, a dialog is typically shown to inform the user if a name conflict occurs and to give him the opportunity to select a new name, if desired.


1.2.4. Ease of Use

When a device is first connected to a network, it must manually or automatically gather information about the local network. With mobile devices, this happens often enough that it is unreasonable to require that a human configure the device every time the device joins a new link. For example, where a site offers one or more DNS domains with services available for browsing, the device should be able to learn this from the network, rather than requiring it to be manually configured by the human user.

The list of services displayed in the browser should be dynamic. You have seen discovery mechanisms that use an icon or dialog to indicate that the list of services is being updated. After some unacceptably long delay, a static list of results is displayed. The only way to refresh this list is for the user to press a refresh button or for the client application to regularly poll for available services. In a Zeroconf-based service browser, less than a second elapses from the time that a user initiates browsing to when she is presented with a list of results. The browser will not burden the network with frequent polling for available services. The list will update to add or remove services based on announcements from the services, from non-renewed leases, and from multicast messages from other devices attempting to use a listed service.




Zero Configuration Networking. The Definitive Guide
Zero Configuration Networking: The Definitive Guide
ISBN: 0596101007
EAN: 2147483647
Year: 2004
Pages: 97

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net