1.2. Replacing the AppleTalk Name Binding ProtocolAt 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.
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 HardwareIn 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.
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 BindingAppleTalk 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 ServicesService 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.
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.
1.2.4. Ease of UseWhen 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. |