Home > Articles > Home & Office Computing > Mac OS X

Voulez-Vous un Rendezvous? The Simple Guide to Apple Networking

  • Print
  • + Share This
Voulez-vous une Rendezvous? No, it isn't a hot date; it's the way Apple allows an ad-hoc network to be created without requiring the user to make any system setup changes. Larry Loeb gives the details about how Rendezvous pulls this off.
Like this article? We recommend

Like this article? We recommend

Rendezvous is the name for the method that Apple uses to implement zero-configuration, IP-based network services. It has three basic parts: one for publishing the IP-based service, one for discovering it, and the last for actually using it. As the label zero-configuration implies, the user should be able to do all three of the above steps without having to reconfigure the network's settings to do so.


Although what follows is based on OS X, there is also a version of Rendezvous available for Windows.

The first part of the method is called publication of the service. An application or device must register the service for publication with a multicast DNS (Dynamic Name Server) responder, either through a high-level API or by communicating directly with the responder (mDNSResponder in Mac OS X v10.2 and later). Apple says that a future release of Mac OS X may support storing records on conventional DNS servers as well, using Dynamic DNS Update. You have to use IPv4 addressing (not the newer IPv6 method) when communicating with any Rendezvous-aware hardware in the current version of Rendezvous. Hosts using IPv6 are recognized, however.

When a service is registered, three related DNS records are created: a service (SRV) record, a pointer (PTR) record, and a TXT record. This TXT record might contain no data or it might have the additional data needed to resolve or use the service.

The SRV record maps the name of the service to the information needed by a client to actually use the service. Clients then store just the service name in a persistent manner, performing the DNS query to obtain the host name (and port number) when it's time to connect. This means that clients can access the service even if its port number, IP address, or host name changes—as long as the service name remains the same.

The PTR record contains just one piece of information: the name of the service (which is the same as the name of the SRV record). PTR maps types of services to all the specific devices offering that service.

A TXT record has the same name as the corresponding SRV record and can contain a small amount of additional information about the service instance—typically no more than 100–200 bytes at most. This allows the running of multiple services on the same port at the same IP address, such as multiple print queues on the same printer server.

Discovering Services

This part of Rendezvous uses the DNS records registered during service publication to find all named instances of a particular type of service. To do this, an application performs a query for PTR records matching a service type. Most programmers do this query through a higher-level API. The multicast DNS responders running on each device return PTR records with service instance names.

Although one needs to be able to discover services when a new device has been added to the network, it's not an operation that happens often. In this discovery phase, an application does not need to know the specifics (also called the socket information) of where a discovered device can be found on the network. It needs to know that kind of stuff only when it's going to actually use the service for something.

  • + Share This
  • 🔖 Save To Your Account