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."
Following the link to the developer site we find that:
Rendezvous requires that devices implement three essential things. These devices must be able to
allocate IP addresses without a DHCP server
translate between names and IP addresses without a DNS server
locate or advertise services without using a directory server
ok...
to release more home electronics type products. After all why would they need Rendevous on non-mac platformsm, unless they were planning on selling a networking device that hooks up to the home network? (like, say, a digital video device or some other home theatre component)
------- Oh damn.... the Sigfile escaped... -Great OM
Rendezvous/ZeroConf is basically Appletalk for IP. While Appletalk had its shortcomings, it was awesome for setting up small networks. Just plug + play, no DNS/DHCP/etc BS to worry about. Appletalk's gone the way of the dodo, replaced by this (which works on an IP network).
"Rendezvous technology is now available on Windows 2000 and XP. This preview release includes full link-local support, allowing Windows machines to discover advertised HTTP and FTP servers using Internet Explorer"
Given that Apple today joined the announcement with Mozilla and Opera of open-standards for web plugins it surprises me that their product even suggests the use of Internet Explorer.
I freely admit to hoping, someday, for Safari on Windows and using Firefox until that day (And pls don't reply saying Safari is on Windows in iTunes.. iTMS on Windows doesn't use Webcore, more's the pity.)
I have been a user for about 10 years. This ends Feb 2014. The site's been ruined. I'm off. Dice, FU
A cursory examination of some of their documents seems to indicate the plan involves what they're calling DNS-SD (DNS-based service discovery) which is a way of encapsulating device id and configuration information within DNS records, and specifically making use of special conventions for TXT data.
If this is the case, it seems a pretty clever and resourceful approach.
Then again, this will make DNS servers the main entry point for discovering information about networks, especially information that might normally not be publicly available.
Personally, I like this approach because far less people have access to manage detailed DNS data and may actually be able to manage these things effectively, but there's also a ton of people out there who have insecure DNS information and adoption of this approach among those admins who haven't secured their networks might create an even bigger security problem.
This is a wonderful concept for small to medium sized networks but I can forsee that it will not scale well. If you read into the RFCs a bit it seems that the services location action and the ability to find things without a DNS server rely heavily on the use of DNS via multicast. This is a great idea in principle but the design of a large scale network with correct multicast switching is tough to do from scratch ... let alone reverse engineer your network with multiple flavors of switching gear (cisco, avaya, etc) to handle all the multicast traffic correctly. Sadly, I have to admit that centralized IP based active directory controlled "dynamic DNS" is about the only thing that I have seen that will scale well at the REALLY BIG network level. In addition, I see no mention of the protocol being able to traverse a router. WTF good is a /16 address space if it can't get across a router? Can someone say "DNS helper acl"?
Several times I've had the need to print something while in an unfamiliar network. It takes just a few seconds to find and send a job to a printer using Rendezvous. At first it seems ludicrously easy, like it won't actually work. But it does.
In a laptop-centric world, Rendezvous makes life a lot easier.
Read the EFF's Fair Use FAQ
And this from Apple's website:
NT Migration Tool Tiger Server makes it a snap to upgrade your aging Windows NT network to a Mac OS X server. The new NT Migration Tool automatically extracts all of your user and group account information from an existing Windows Primary Domain Controller and moves it into Open Directory. Tiger Server can then take over as your Primary Domain Controller for your Windows clients and even host your Windows users' home directories, group folders, roaming profiles and shared printers.
So they're making it easier for NT users to migrate their network over to Tiger when it is released. And now this Rendesvous news. Sounds like Apple is quite serious about wanting to be a player in the enterprise server market if you ask me.
"He uses statistics as a drunken man uses lampposts...for support rather than illumination." - Andrew Lang
The link is a very interesting article - more interesting than the initial story.
To me, it looks like the largest drawback to UPnP is that it defines too much and becomes inflexible. While the current implementation of Rendezvous is directed at home networks and networks without much infrastructure, I can't see why it couldn't scale out. If / when it scales out, it will intrude on more than just UPnP. It could also kick butt all over MS's UDDI for web services. Here's a scenario for which I could profitably use a more scalable Rendezvous type functionality, where neither UPnP or UDDI would work well:
A service gets a name, independent of the machine. Clients of all types find and connect to the service. For example, we've got a critical Job Status service, that collects information about myriad automated jobs so that the staff responsible for a set of jobs can quickly check if any of their jobs are misbehaving.
Say the computer running the Job Status service blows up and rolls over to a different device (or we painfully restore it on another device). Certain fancy expensive data base servers handle this rollover smoothly - but not my home grown application. I get it almost for free with Rendezvous (expect moving the service). Because the client connects to a service name, it finds the new service seamlessly. No configuration file push, no changing C-Names in the active directory (which requires arguing with about 4 departments in my company) . Just bring up the same service name on a new device.
Rendezvous could apply to any service - not just web services as with UDDI. Also unlike UDDI, there is no need for a single point of failure (the server with the UDDI directory). Unlike UPNP, I don't have to jump through hoops to describe my service, or attempt to conform it to an existing specification - and the current ones are really focussed on devices. I don't really care about describing my service in grand detail. I can assume an application designed to work with knows how it works.
The main thing missing from Rendezvous for this scenario is scalability. Rendezvous could solve this easily by stealing the controller model for UPnP. Put up 5 or 10 controllers on our 10,000 device network. Each client knows about a few of them. You can handle the load and don't have a single point of failure.
My motto: "A cat is no trade for integrity."
Yes, and at the risk of ruining a perfectly good karma, I will point out that after trying and failing for half an hour to print a web-based document from my Linux machine on my employer's network printers, I put my PowerBook on the net and started the print job in less than 30 seconds via Rendezvous discovery.
But the really cool thing is that the HP printers on the net show up in Safari's Bookmark bar Rendezvous menu, providing HTML interfaces for printer status and settings.
The part that is important is specifying the commands and data to/from devices.
Which already exists as other protocols. It's better to separate the device/application-specific stuff from the transport. We learned that lesson from IP.
We learned this lesson back with SCSI-1.
No, we didn't. Your example ignores the fact that protocols already exist to perform these functions. Why reengineer IPP when it already exists?
A lightweight approach is best, which is what Zeroconf provides.
I just purchased my first new Mac in 3 years [no, my 3year old DP800 is still more than powerful enough to be my main machine, it just wasn't portable *enough*]. I weighed many options and nearly went delerious trying to beat the Apple tax and all their silly pre-configured options. I seriously looked at one of those nice AMD64 laptops for a whole afternoon. But while I would have saved on the kit, I wouldn't be able to run an OS that somehow always manages to stay at or near the top of all the features with little to no hassle to set up and use. After the delerium abated, I settled on a stripped down 15" PBG4 1.33GHz tricked out with 3rd party RAM. I swear that the desire to lick my backlit keyboard in the dark still has not abated...
sigs are for fools and trolls. no signature is *always* appropriate. you should turn them off in your preferences.