Slashdot Mirror
Apple Releases Rendezvous for Linux, Java, Windows
mblase writes "Apple released yesterday a developers preview of their Rendezvous technology for Windows, Linux, FreeBSD, Solaris and Java. Rendezvous is an open protocol which uses industry standard IP protocols to allow devices to automatically find each other without the need to enter IP addresses or configure DNS servers."
Reader xxdarkxxmatterxx adds a link to a story at Macworld about the release."
For anyone who is interested, Rendezvous is Apple's implementation of of ZeroConf
While Apple's Rendezvous overview gives some decent information, the ZeroConf site provides a lot of good technical resources.
Apple really needed ZeroConf as they transitioned to all-IP networking. Although OS X supports AppleTalk, the AppleTalk protocol has clearly seen it's day and the world is clearly moving to IP-only. Previously, when Macintosh machines were largely communicating via AppleTalk, all of the things that ZeroConf addresses were handled by the AppleTalk protocol suite (service discovery, address allocation, etc), and this ease of use that is signature to the Macintosh is important for Apple to maintain.
That said, Apple releasing this code is pretty significant, as aside from this project, there hasn't been much use of ZeroConf in the wild.
bash-3.00$ uname -a
SunOS panda 5.10 Generic sun4u sparc SUNW,Ultra-2
We've launched this only a few weeks ago: Pocketster. It contains an implementation of Rendezvous for the Pocket PC and it also gives you wireless filesharing capabilities (we have a new version coming out on July 6th). It's free, so give it a try if you want (that is if you have a Pocket PC). Also, you might want to check JmDNS (Java version of Rendezvous) and Howl for a Windows implementation. Razvan
Rendezvous is based on a few underlying services: Dynamic Configuration of IPv4 Link-Local Addresses, Multicast DNS, and DNS-based Service Discovery.
Dynamic Configuration of IPv4 Link-Local Addresses: In the absence of a DHCP server, the machine is able to configure itself with an IP address in a reserved range such that it doesn't clash with other IP addresses configured by other machines on the same network in a similar manner.
Multicast DNS: Multicast DNS Responder services on each machine respond to multicast queries for their DNS information.
DNS-based Service Discovery: Querying for the existence of services (HTTP, FTP, SSH, etc.) via DNS.
So, in a sense, "everything is a DNS/DHCP/Directory server" but only for the information and services provided by that particular machine.
UDP traffic is pretty lightweight. ZeroConf is basically just some ICMP traffic (when the nodes are assigning themselves addresses) and then DNS. Apple's implementation will aggressively cache query results, and the devices incremementally scale back their announcements.
Another nice feature is that nodes can cache the results of other nodes' queries. Since all of the DNS traffic is mulitcast on the local subnet, every node sees every query and every response. Apple's code expolits this to further reduce the need for duplicate queries. It's a pretty nice setup.
Rendevous is some what like making each computer a DNS/DHCP/Directory server, however that's not completely accurate.
It's not so much that it's not completely accurate as it is that it's completely wrong.
Rendezvous has nothing to do with DNS, DHCP, or directory services. It's a service discovery framework, and that's all. Here's how it works.
Let's say you've got some program, Foo.app, that has a feature for talking to other instances of Foo.app over the network. Doesn't matter what it is. It could be iTunes music sharing or iChat or distributed compilation or whatever you want.
Without Rendezvous, you'd have to tell your instance of Foo.app where to find other instances. That'd require some kind of setup and some kind of maintenance.
With Rendezvous, your instance of Foo.app sends out a single multicast message when it starts up. That message says that there's an instance of Foo.app available at our IP address. Other instances on the network receive that message and make a note of it. They maintain a list in memory of available services, all automatically, without your intervention.
Does this involve a lot of network traffic? Not really. It requires some, but not much. When an instance of Foo.app starts up, it (1) announces its own presence, and (2) sends out a multicast request for other instances, and the other instances reply. When Foo.app shuts down, it sends out an announcement of its own termination. That's it.
Does this involve terrible security risks? Not really. All Rendezvous does is publish the availability of services that are already running on the network. The responder daemon itself doesn't run with any privileges (on a Mac, it runs as the "nobody" user), and all Rendezvous requests are handled by that one daemon. If something magical happened and somebody was able to get mDNSResponder to run arbitrary code, there would have to be another exploitable security hole somewhere else on the system, because mDNSResponder doesn't have privilege to do anything.
A prime example of Rendevous is two Powerbooks in a cafe, both with Airport wireless. You can set up an Ad Hoc wireless network between these computers, and they will auto configure their IP's and other information so that they can talk to each other.
That's not Rendezvous. That's nothing more than self-assigned IP addresses. When your computer can't find a DHCP server, it self-assigns an address in the 169.254/16 network. Which means any two computers on the same network segment that have self-assigned IPs can talk to each other. This has been around since long before Rendezvous.
So Rendevous is not designed to replace DNS/DHCP, but merely to find a way for network configuration when there is no established network structure.
No, that's overstating it. The sole purpose of Rendezvous is service discovery. That's it. It's independent of network configuration. It works with or without DHCP, DNS, or any other network stuff. As long as you've got an IP address, Rendezvous does its thing.
This is really the beauty of it, because it can determine what configuration is necessary and do whatever needed to get the computers networked, all transparently!
No, no, NO! That's not Rendezvous, that's DHCP. Rendezvous is ONLY for service discovery. Rendezvous doesn't set your IP address or your routing table or your hostname resolution parameters. It doesn't do any of those things. All it does is facilitate service announcement and discovery for your applications.
I write in my journal
Microsoft has been in alpha now for a bit with a product called "Windows NCD Technology" (I'm a tester). This is Apple's shot across MS's bow.
From the alpha page, Windows Network Connected Device (NCD) Technology is a comprehensive set of Windows technologies that allow devices on a local network to discover, communicate with, and control each other.
ZeroConf means a visiting professor walks into a lab at a university and can automatically print. There's zero configuration.
It means an iTunes user can broadcast their library on the network and another iTunes user can pick it up with no problem. There's zero configuration.
It means I can open iChat, not go onto AOL's network, and see my coworkers down the hallway with zero configuration.
It means I can share a workgroup document we are editing in SubEthaEdit and easily invite coworkers on the LAN. There's zero configuration
And now it means that non-Mac users can start getting in on a lot of the same stuff.
- Allocate addresses without a DHCP server.
- Translate between names and IP addresses without a DNS server.
- Find services, like printers, without a directory server.
- Allocate IP Multicast addresses without a MADCAP server.
You are quite accurately describing point 3 whereas the parent was describing points 1,2 and 4. But ALL FOUR are rendezvous/zeroconf.