The Idea Basket holds an interesting interview with Stuart Cheshire, Apple Computer employee and also Chairman of the IETF ZeroConf, regarding Rendezvous and more.
The Idea Basket holds an interesting interview with Stuart Cheshire, Apple Computer employee and also Chairman of the IETF ZeroConf, regarding Rendezvous and more.
Zeroconf has the potential to be an incredibly useful technology. Anyone know how it compares to Jini being worked on by Sun?
obviously he has not heard of Moxi, or XTV (shameless plug).
First we have one language to rule them all.
Now we have one network protocol (Powered Ethernet) to rule them all?
Part of the beauty of having separate systems is that it allows for many parallel paths of evolution.
Having one protocol force everything to fit into that system. As we know, doing isochronous streams on Ethernet is often a pain. That’s one reason we have MIDI and Firewire. High bandwidth time-sensitive audio devices, such as the MOTU 896, work very well on Firewire. And MIDI is known for good timing control.
Hard drives work very well on Firewire and USB2 but would could saturate a Gigabit (100MB/sec) Ethernet hub. Perhaps a large Gigabit Ethernet switch is the answer.
If we could also improve IP networking, then perhaps this idea of one network system to rule them all is visionary. It would certain simplify internetworking. And with enough bandwidth and low-enough latency, would be fabulous for remote control and KVM switching 😉
I am happy to see what Stuart is exploring. It will only give us more options, hopefully some of them better than the old options!
#m
Something I don’t understand about Apple’s Rendezvous is the use of DNS-SD (www.dns-sd.org). Older MacOS X versions already included SLP, which seems to be more powerful than DNS-SD (more complex queries, more information about the services). Why is DNS-SD used, and is it an additional service discovery mechanism or should it replace the use of SLP.
@Bascule:
It does not have much in common with Jini. Zeroconf is about a) finding a free IP address on a server-less network, b) announcing a name for the computer on a server-less network (via multicast DNS) and c) finding services (using DNS-SD). Discovering services is like “I need a postscript printer that uses LPR as protocol”, and then you get a few of IP addresses.
http://www.zeroconf.org/
[i]A final requirement is that the solutions in the four areas must coexist gracefully with larger configured networks. ZEROCONF protocols MUST NOT cause harm to the network when a ZEROCONF machine is plugged into a large network. </i?
If Zeroconf didn’t have this last requirement, it wouldn’t make sense. In an existing network environment, Zeroconf’s main value proposition is service discovery.
#m