Section 4.3. Knowing the Protocol

4.3. Knowing the Protocol

A visitor staying in Paris wants to know whether she should take her umbrella on her travels around the city. Standing in the hotel lobby in the morning, she sees a local newspaper, which has the day's weather forecast, but it is in French. She doesn't read French. Also in the hotel lobby is a copy of an English newspaper, which she can read, but the English newspaper doesn't include a weather forecast for Paris. This illustrates one of the challenges of network software. To be useful, a service has to (1) provide the conceptual service the client wants (e.g., a weather forecast) and (2) provide it using a language (protocol) the client can speak and understand (e.g., English). Because of this, a Zeroconf service type name conveys not just the "what" of a service but also the "how." For example, the Zeroconf service type _ipp encodes both the "what"printingand the "how" via Internet Printing Protocol.

When an IPP printing client browses for services of type _ipp, it is not looking for printers in a broad, fuzzy, not-very-precisely defined human sense. It is looking specifically for printers it can talk to. It is looking specifically for printers that implement IPP, the Internet Printing Protocol. There may be an old AppleTalk printer nearby, which may be a printer as far as human beings are concerned, but from the point of view of an IPP printing client that has no way to communicate with an AppleTalk printer, it may as well not exist. From the point of view of IPP printing client software, it's only useful to discover things that it can actually use. This is one of the reasons that proliferation of network protocols is a bad thing. While we may

Why All the Underscores?

DNS-SD service typesi.e., application protocol namesall begin with an underscore. There's no particular reason for this; it is simply a convention inherited from RFC 2782, "A DNS RR for specifying the location of services (DNS SRV)." The original motivation was to avoid accidental conflicts with existing DNS hostnames. Since DNS hostnames are not supposed to begin with an underscore, requiring all service names to begin with an underscore was seen as a way to prevent accidental overlap of the namespaces. It's not really necessary; it's one of those conventions where there's no particularly compelling reason for it, but there's also no particularly compelling reason to change it either.

embrace the richness of variety in human languages, the same is not so desirable in network protocols. When there are 10 different ways of doing basically the same thing, there's much opportunity for incompatibility. The server may offer the conceptual service that the client wants, but if they have no protocol in common that they both speak, it may as well not exist.

The converse is also true. Finding entities that implement a given protocol is only appropriate when the semantic service being offered is also appropriate. It is common to borrow an existing protocol and repurpose it for a new task. This is an entirely sensible and sound engineering practice, but that doesn't mean that the new protocol is providing the same semantic service as the old one, even if it uses the same message formats. For example, the local network music-playing protocol implemented by iTunes on Macintosh and Windows is built using HTTP GET commands. However, that does not mean that it is sensible or useful to try to access one of these music servers by connecting to it with a standard web browser. The data that is being fetched via those HTTP GET commands is compact binary machine-readable data, not HTML text that a normal web browser could interpret and display as a page on the screen. If iTunes were to advertise the _http service, that would cause iTunes servers to show up in conventional web browsers like Safari and Internet Explorer, which is of little use since an iTunes server offers no pages containing human-readable content. Similarly, if iTunes were to browse for _http service, it would find generic web servers, such as the embedded web servers in devices such as printers, which is of little use since printers generally don't have much music to offer. Consequently, the DNS-SD service advertised (and browsed for) by iTunes is the Digital Audio Access Protocol, or _daap, which conveys both the "what" of the service (a collection of music) and also the "how" (read using HTTP GET commands).