Rendezvous, Microsoft And Apple

serendigital writes "MacCentral reports that a BusinessWeek article entitled: 'A Rendezvous with Redmond?' has -- with Rendezvous -- created an actual threat to Microsoft. As reported by MacCentral, it's interesting to note that BusinesWeek's 'Byte of the Apple' columnist Charles Haddad is on temporary leave and this article was written by a substitute columnist."

Comments

Re:Home usage only

[d3xt3r]

... but with all of these broadcast packets i would imagine it would saturate a low speed (read:wireless) network.

Although wireless networks offer slower bandwidth than their wired counterparts, they do offer one advantage over hard-connected ethernet: they don't suffer from the same saturation problems. While 100 demanding users could quickly saturate a shared 100 MB/S wire, the same users on wireless will not interfere with eachother. Wireless scales much better than you seem to think.

Secondly, a couple hunderd extra broadcast packets aren't going to saturate a 100 base-t network. A packet is tiny. If I do a tcpdump right now, you wouldn't believe the number of broadcast packets flying around here at this moment. My network connnection isn't being adversely affected.

Also, I'd really differ with you that Rendezvous isn't useful in a business setting. Obviously it's not going to replace DNS for the majority of services, but it could seriously simplfy things like, printing, scanning, and maybe even some file sharing. I don't doubt that this technology will find a great place in the home, but it certainly doesn't mean it's useless to businesses. It's worth noting though that Rendezvous is limited to the current machine's local subnet.

It scales much better than previous protocols.

[Paradox]

You'd be surprised how well this actually scales. That is one of the whole points. Rendezvous is a replacement to AppleTalk, and as such one of the major goals is not to saturate the network like other more chatty protocols.

For instance, each host implements an aggressive caching scheme so if one host asks for data, other hosts can learn from its request. There is also an exponentially rising delay between each request, the assumption being a host that has been around a long time will continue to be around a long time. Further, Rendezvous requests are not just like broadcast pings. They have a very well defined (and specific) domain standard in multicast DNS. You could ask only for http servers running over TCP, or only iPhoto sharing servers. This cuts down on the traffic.

Of course, the other problem is the dynamic IP address assignment. It chooses an IP out of a /16 subnet. In short, in order for there to be a high probability of collision there need to be more than 32768 hosts, and even then it'll converge quickly. The Zeroconf spec gives upper bounds on how many hosts should be in a zeroconf network.

The whole idea of this system is to allow small isolated subnets (like a wireless zone) to auto-configure. After the first 20,000 devices, sure you might see some degredation in performance. Of course, imagine an admintaking care of a 20,000 device subnet. They end up like a cross between Jerry Lewis and Christopher Lloyd. If you need more subnets then you link them via a configured host. A proxy-gateway with rendezvous, forwarding only things that matter for this subnet, would be a pretty cool app too.

Zeroconf, especially in the home or small office setting, is really, really useful.

Rendezvous is (or will be) an Internet Standard

[mbone]

Rendezvous is not just an Apple product - it is on the way to being an Internet standard, with an IETF working group and two Internet drafts in progress - one on Auto configuration of hosts and the other on the Dynamic configuration of IP Addresses.

At the ZeroConf WG meetings I have been to, Microsoft was very much present, so I assume that they are well aware of this technology.

Re:Nothing really new...

[Midnight Thunder]

Rendezvous seems to have a much greater chance of working. First, it is not language centric, as was JINI and secondly it is much easier to understand and implement. JINI tried to do too much and people just gave up trying to understand it.

If these Apple press release are anything to go by, then Rendezvous has already made huge headway:

• TiVo, Brother & Aspyr Announce Rendezvous Networked Products
• Developers Rapidly Adopt Apple's Rendezvous Networking Technology
• Epson, HP & Lexmark Support Apple's Rendezvous Technology

Although already posted in further down, here is Apple's page on Rendezvous. I want to see this technology work, because simplicity is what most people want. If its simple, then people just use the technology and don't notice its there - this is what future computing must strive to do.

Re:Home usage only

[Cajal]

A lot of the technology behind this seems very cool in nature, but just like AppleTalk (which had many similar zeroconf features) i can't imagine it will scale very well. Although this article would love you to think otherwise, I would imagine this whole thing would have more of an effect on the home market then on the buisiness market. I can see not wanting configure applications on small network, but with all of these broadcast packets i would imagine it would saturate a low speed (read:wireless) network.

Actually, ZeroConf contains many provisions for scalability:

• It is just using DNS packets, which have no connection overhead, and are small.
• It can pack multiple DNS queries or answer into a single packet, reducing protocol overhead.
• All DNS traffic is multicast. Other hosts on the network can see responses to your queries, and cache this information. They then suppress their own queries for similar services (i.e., if you just looked for IPP printers, and 5 min later someone else wants to, that person can just use the cached information from your query).
• Devices announce their presense when they join a network, but the frequency of these announcements is reduced exponentially, up the rate of about 1/hour.

• Apple has said that they designed ZeroConf to generate significantly less traffic than AppleTalk.