Slashdot Mirror
Rendezvous Developer Stuart Cheshire Interviewed
overunderunderdone writes "Found this interview of Stuart Cheshire, the Apple employee who developed Rendezvous (a.k.a. Zeroconf) and co-chairs the ZEROCONF working group. He provides some interesting history behind Zeroconf. But I thought his ideas for the future of Rendezvous was more interesting. He envisions a single protocol for everything from the keyboard, hard disk, peripherals, to the net connection -- just one kind of socket in the back of your box."
Number 1: Bolo
Number 2: Apple Events (PPC) over TCP/IP.
I used to tell my parents that "of course you can set up the computer on your own". because everything on the back of the box was a different shape. and the mouse and keyboard (on their systems at lease) were color coded. so it's no biggie. you just keep plugging until it FITS. now, it'll be the opposite. of course you can set up the computer. because it doesn't matter where you put the plug. they're ALL right.
You see, without that little doohicky, the universe stops.
http://propheteer.org
Single protocol/plug is already here, yup.
All you need is Firewire & USB 2.0 (not 1.0) and you can hook up to everything.
Hey wait. That's not a single plug. That's 2 plugs.
... and in darkness bind them. Just wait until Microsoft adds their IP to the protocol and mangle it so that you have a MS universal protocol. All others pay royalties of course.
I am not very optimistic about universal protocols.
works fine for me. try it again? perhaps you're being filtered. THEY don't want you to know about it.
You see, without that little doohicky, the universe stops.
http://propheteer.org
I got that when I first clicked the link too. then I selected the location bar (with the link in it) and hit enter again. Loaded fine. maybe they're filtering by the http refer.
I think the only thing that's completely standardized across all computing platforms is the power cable. Can we just connect everything with power cables?
Bolo, hands down, rocked.
I remember playing Bolo in the University of Michigan's massive "fishbowl" computer lab around 1993. And I remember Bolo sent the entire support staff into a frenzy: everyone was playing it.
Of course, those were the days when the lab consisted of hundreds of PowerMac 6100's but only a handful of Windoze boxen.
Anyway, Stuart, if you're reading this: Bolo was (is?) a fantastically cool game. Many hours when I shoulda been working were spent tooling around in top-down tanks, pummelling pillboxes.
Slightly, off-topic, but I'm afraid there's a new generation of comp-sci students out there who missed out on the glory days of Bolo. (Of course, I get misty-eyed when I hear someone mention TRS-80s and Z80 assembly language, but that's another story -- and another era missed out by today's new generation of computer hot-shots. Not to mention the whole mid-80's coin-op video game revolution. To think, there's a whole bunch of folks who don't know what it's like stack a row of quarters on the top panel of a Pac Man or Donkey Kong stand-up game...)
The only important thing to know about Stuart Cheshire is that he created the the mindnumbingly addictive global internet phenomenom called Bolo.
It was the first big non-text game to be played over the internet and it was huge when I was at uni 1993-96.
He created it for his PhD and it's good to see he hasn't been idle since then!
Karma police, I've given all I can, it's not enough, I've given all I can, but we're still on the payroll.
In his keynote, Steve Jobs said that Rendezvous would be an open standard, and it might as well be -- it's just an extension of TCP/IP, basically.
----------
Cheese it! It's the FEDS!
As I read the article its claims it uses IPv6 as part of its makeup. They had to go back to work in IPv4.
Does IPv6 have wireless recognition? I think that's the big deal.
But I'm not network protocol expert, so explain it to me as you wold a mac user.
The new version are a little buggier and don't play quite as well as MacBolo, but larger games play much better. Check out the website.
Happy boloing!
While wireless Firwire is being worked on, Rendevous has it now, AFAIK.
The sad part is the possibilities will be limited by access rights. Imagine viewing a DVD in one room, going to the kitchen to make popcorn and having the TV there synch up to the one showing the DVD. Don't think Hollywood wants that.
You can make things fast, cheap, simple, easy to configure, secure, etc., but not all at the same time. That is the first lesson of engineering, and it applies to peripheral connections as much as it does to other engineering problems.
If you spend any time around UI designers, quite a few of them think this way. We work hard to try and simplify the onscreen User Interface so that it becomes transparent to day to day work, but you get behind your computer and there are so many cables, you can't see anything else.
Jef Raskin had a neat idea for a universal, hermaphroditic connector, where you don't even have male and female parts, you just slap two of the connectors together. It always fits, it always works. Neat.
There's an actual picture of what I'm talking about in his book. It's kind of hard to visualize until you see it.
In his keynote, Steve Jobs said that Rendezvous would be an open standard
s/would be/is/
Rendezvous is just Apple's marketing name for their Zeroconf implementation, just as FireWire is just their marketroid-friendly name for IEEE1394. What's in a name? Think different!
Lost: Sig, white with black letters. No collar. Reward if found!
And while the idea of having a ubiqitous protocol (sort of like the protocol equivalent of XML) would be beneficial in a lot of ways, it is somewhat naive, IMHO, to think that it could be achieved. New ideas come up all the time, and people have created new protocols, languages, and ways of exchanging those ideas simply because the idea does not fit within the scope of that which already exists.
It's called innovation. As long as people continue to innovate, new ways of implementing those ides (protocols) will need to be created.
I'm amazed by how many posts there are talking about single-protocol-this and single-protocol-that. My favorites are the ones talking about how having a single protocol leads to licensing fees and restrictions, and the one about how a single protocol is insecure.
Didn't you losers even read the article? Rendezvous is basically two things: self-assigned link-local IP addressing, and automatic service discovery. In other words, you computer can automatically assign a local IP address to itself, then discover services available on other computers via particular UDP packets. Get two computers in proximity to each other, and they'll be able to ``see'' each other's shared volumes. Get one computer connected (wirelessly or wired-ly) to a printer, and the computer will be able to ``see'' the printer.
If you ever used Mac OS n (n poof.
RTFA, indeed.
I got some strange error... But hit back arrow and the article came up..
here it is:
On Rendezvous, TiVo, and Parliamentary Titles
An Exclusive Interview with Stuart Cheshire
Wizard Without Portfolio at Apple Computer & Chairman of IETF ZEROCONF
Soon after publishing my article entitled Rendezvous: It's Like a Backstage Pass to the Future, an e-mail appeared in my Inbox from some guy named Stuart
who was very supportive and helped me gain further understanding of a few aspects of the Rendezvous technology. It wasn't until I got to the bottom of
his e-mail when I noticed his signature. Ha! No wonder he knew so much about Rendezvous - he was Chairman of the ZEROCONF Working Group and was
employed at Apple! After exchanging a couple of e-mails back and forth, I asked him if I could interview him during Macworld, and to my delight, he agreed.
Stuart has been involved in a slew of computer science projects for the past number of years. He recently completed his Ph.D. in Computer Science at
Stanford University, and holds B.A. and M.A. degrees from Sidney Sussex College in Cambridge, U.K. You can learn more about his background from his
Web site. One of his overriding goals is to make IP networking easier to manage and better suited for use with various kinds of computing devices, which is
why he has been so instrumental in getting IETF ZEROCONF off the ground.
Jared: Thanks very much for agreeing to this interview in spite of your busy schedule and travel arrangements. You're actually in Japan at the moment, correct?
Stuart: That's right. I'm in Japan for the week-long IETF (Internet Engineering Task Force) meeting. The IETF does most of its work via email, but three times a year we get together
for face-to-face discussion. Generally two out of three meetings are in the United States, but the Internet is a worldwide phenomenon, not just an American thing, so usually at least
one meeting a year is outside the USA.
At this minute I'm sitting in the IPv6 Working Group meeting with my PowerBook, answering your questions via AirPort.
Very cool! Now the ZEROCONF Working Group that is part of the IETF is responsible for developing and maintaining the open-standard Zeroconf networking protocols,
dubbed Rendezvous by Apple. Can you give us a brief overview of these protocols and the history behind them?
The initial seeds of Zeroconf started in a Macintosh network programmers' mailing list called net-thinkers, back in 1997 when I was still a PhD student at Stanford. We were
discussing the poor state of ease-of-use for IP networking, particularly the lack of any equivalent to the old AppleTalk Chooser for browsing for services. I proposed that part of the
solution might be simply to layer the existing AppleTalk Name Binding Protocol (NBP) over UDP Multicast.
At the Orlando IETF meeting in December 1998 I discussed this idea with other people, and the following suggestion was made: trying to introduce an AppleTalk protocol into the
IETF would not be easily accepted, but perhaps the existing IETF DNS packet format is semantically rich enough to hold exactly the same information as I proposed putting into an
NBP/IP packet. I agreed with this suggestion - there's no need to invent a new IETF packet format just for the sake of it, if there's an existing packet format that can do the job
perfectly well.
The IETF is generally populated by people who care very little for ease-of-use, but the Area Directors of the Internet Area were sufficiently far-sighted that they believed that
improving ease-of-use should be an important priority for the IETF, even though that was very much a minority view back than. Even today, it remains a something of a minority
view in the IETF. Most IETF people work for router vendors, ISPs, backbone providers, telephone companies, etc., and their focus is wide-area networking. If you work for a
company that makes routers, you've not going to be very excited about technology that lets computers communicate directly, without needing a router. If you work for a company
that sells a DHCP server, you've not going to be very excited about technology that lets computers communicate without needing a DHCP server. If you work for a company that
sells DNS servers, you've not going to be very excited about technology that lets computers communicate without needing a DNS server. I'm sure you get the point.
Despite this lack of general enthusiasm, the Area Directors went ahead and arranged a preliminary "Birds of a Feather" session (BOF) to discuss these issues, under the name
"Networking in the Small" (NITS). We had two NITS BOF meetings, in March and July of 1999. Peter Ford from Microsoft helped me co-chair those meetings, and we gathered
enough interest to warrant the formation of an official IETF Working Group, under the new name "Zero Configuration Networking", in September 1999. At that time, Erik Guttman
from Sun volunteered to co-chair the new Zeroconf working group with me, and he has been invaluable in helping keep the work on-track and moving forward for all this time.
The Zeroconf working group identified four requirements for "Zero Configuration Networking":
1. Devices need an IP address.
2. Users need to be able to refer to hosts by name, not by address.
3. Users need to be able to browse to find services on the network.
4. Future applications will need to be able to allocate multicast addresses.
IPv6 already has self-assigned link-local addresses, but IPv4 did not, so we produced a specification for how IPv4 devices can obtain self-assigned link-local addresses.
For name lookup, we have general agreement that DNS-format packets sent via IP Multicast are the right solution.
For browsing, I worked out how to do the thing that was suggested to me back in 1998, and wrote a draft called "Discovering Named Instances of Abstract Services using DNS"
(draft-cheshire-dnsext-nias-00.txt) which specifies how to do network browsing using just DNS-format query and response packets.
These specifications provide what we need to make dramatic ease-of-use improvements for local IP networking. However, these solutions do remain controversial with some IETF
participants. Although Apple is already shipping Rendezvous, we are continuing to work in the IETF Zeroconf Working Group to continue the ongoing development of these
protocols. Apple's intent is that as the protocol specifications continue to improve as a result of helpful intelligent discussion in the IETF community, we will be updating our
Rendezvous implementation to benefit from those improvements. This is a fairly normal state of affairs - most communications protocols continue to evolve and improve over time,
and good companies have an ongoing process of updating their implementations to benefit from those improvements.
Speaking of Apple, in addition to your role as Chairman for the ZEROCONF Working Group, you are also Wizard Without Portfolio at Apple Computer. I confess I have
no idea what that means, so what exactly is it that you do at Apple?
It is a pun on the British parliamentary title, "Minister Without Portfolio", which is like "Senator at Large" in the USA, meaning someone with general responsibilities, not restricted to
one particular area. For me, what it means is that I try to make sure I'm always looking at the big picture, not limiting my thinking to one particular narrow field.
Ah, I see. Steve Jobs at the Macworld keynote yesterday gave Rendezvous a significant spotlight during his Jaguar presentation. In particular, he demonstrated the
integration of Rendezvous into iChat, iTunes, and several network printers soon to be released by Epson, HP, and Lexmark. This definitely proves that Rendezvous is
just as useful for bringing plug-and-play, zero-configuration networking services to software and hardware devices as it is useful for networking computers
themselves. Can you elaborate further on what kind of functionality Rendezvous brings to software and hardware devices that simply hasn't been possible in the past?
I can't comment on specific Apple product plans, but I think you had some very interesting ideas in your "Backstage Pass to the Future" article. Rendezvous is not just about making
current networked devices easier to use. It is also about making it viable to put networking (i.e. Ethernet) on devices that today use USB or Firewire, and it is also about making it
viable to use networking in areas that you wouldn't have even considered before Rendezvous. Imagine a future world where you connect your television and amplifier and DVD player
with just a couple of Ethernet cables, instead of today's spaghetti mess of composite video, S-Video, component video, stereo audio, 5.1 Dolby, Toslink optical audio cables, etc.
One of my favorite examples that I've been giving since the early days of Zeroconf is this: I have friends who have bought a TiVo Personal Video Recorder, and then liked it so much
that they bought a second TiVo for the television in the bedroom. Now what is the problem? At night they turn on the bedroom television to watch a recorded episode of Seinfeld
before they go to sleep, but they can't because it is recorded on the other TiVo. Imagine if any TiVo in your house could automatically discover and play content recorded on any other
TiVo in your house. Sadly, I'm not aware of anyone from TiVo participating on the Zeroconf mailing list, so it may be a long time before we see anything like this, but I think you'll agree
this would be a very cool product.
So you would say Rendezvous delivers almost FireWire-like ease of use for networked devices?
I would go further than that. My long-term goal, from before I even started at Apple, is to eliminate the need for disparate incompatible technologies on your computer. Right now
your computer may have SCSI, Serial, IrDA, Bluetooth, USB, Firewire, Ethernet and AirPort, all communication technologies that each work a different way.
My hope is that in the future - distant future perhaps - your computer will only need one wired communication technology. It will provide power on the connector like USB and
FireWire, so it can power small peripheral devices. It will use IP packets like Ethernet, so it provides your wide-area communications for things like email and Web browsing, but it will
also use Zeroconf IP so that connecting local devices is as easy as USB or FireWire is today. People ask me if I'm seriously suggesting that your keyboard and mouse should use the
same connector as your Internet connection, and I am. There's no fundamental reason why a 10Mb/s Ethernet chip costs more than a USB chip. The problem is not cost, it is lack of
power on the Ethernet connector, and (until now) lack of autoconfiguration to make it work. I would much rather have a computer with a row of identical universal IP communications
ports, where I can connect anything I want to any port, instead of today's situation where the computer has a row of different sockets, each dedicated to its own specialized
function.
Well it sounds like you're working on some wonderful ideas and technologies there, and I'm very excited to see Apple adopting Rendezvous so readily for Jaguar. I'm
certain this will prove to be an important milestone in the evolution of networked computing. Stuart, thanks again for being here, and I wish you the best of luck in your
dual roles as ZEROCONF Chairman and Wizard Without Portfolio at Apple!
Thank you Jared.
IR is basically a serial port that uses IR instead of a wire to make the interconnect. Bluetooth uses 900Mhz to make the interconnect instead of LED's. USB is another serial protocol, just faster than RS-232. Same with firewire, just faster still. For the most part they are really just varied serial ports.
Ethernet(10BT,100BT,1000BT) is a bit different.
What we are seeing with firewire and USB is a progression of serial protocols towards an ethernet kinda environment, where there may be more than one device on the line at the same time and you can have little hubs/switches to coordinate the traffic.
I wouldn't really say that many of them are optimized for one thing or another. IR is just as limited as an RS-232 port, just made it easier on notebook designers to save space. USB was done since rs-232 had some serious speed limitations. Firewire for pretty much the same reason. Bluetooth - well...it was more of a way to elimnate wires...cool idea.
well 2/7 isnt bad is it?
I want 2D games back.
Sounds like it will muss up a clean running IP network like IPX did. If so, no thanks.
But nothing IPX can do is worse than someone with a lot of bandwidth and a duplicate IP address can do.
IPX without SAP/RIP spoofing was murder on really, really low-bandwidth WAN links or cheesy imitations thereof that used long-haul bridges.
But IPX (and Appletalk) had a lot of *good* things about them, too that take much more work and much more complexity to achieve in IP. Automatic client node addressing -- it just works in IPX, in IP it takes a whole infrastructure (DHCP server, integration with DNS, etc).
Service location -- it just worked with IPX SAP. SLP (at least the little exposure I had with it and Netware 5) was mind-numbingly complicated and often relied on multicast.
No shortage of addresses, either - IPX gave you 32 bits of network addressing and 48 bits of node addressing.
Zeroconf is not a protocol for letting devices talk to each other. As others have already pointed out, there are already protocols which are far better at doing that.
Zeroconf is a protocol for letting devices discover that other devices exist -- without requiring a human to explicitly tell each device.
Don't think that Zeroconf is trying to replace anything.
As for IPv6, true it already has link-local addressing. Thats 1 of the 4 things Zeroconf does. The auto-discovery of *other* devices isn't built into IPv6.
Are you mad?
Power plugs aren't standardized at all. If you don't believe me, walk into the closest Radio Shack and ask for a power plug. Be sure to refuse to give any specification beyond that.
Under capitalism man exploits man. Under communism it's the other way around.
There's a reason that people wrote all that assembler code years ago... because they needed the speed. Nowadays, when I'm writing my Wonder Widget 2000 (tm) I "should" write assembler because it would be a lot more efficient, but I don't have to because everything's faster.
Same thing here. We "should" use all the different protocols because they're more efficient, but as all the hardware gets faster, if I run at 1Gb or 1.2Gb, in reality for most applications, who cares? Ok, so the numbers are made up, but you get the idea.
On top of that, there are benefits to being able to use standard stuff (maintenance, bugs, etc.).
Hardware, just like software, will standardize because it can and there are side benfits.
"Let your heart soar as high as it will. Refuse to be average." - A. W. Tozer
I belive that GSM uses the 900Mhz area (well, at least at europe) while blue tooth uses the 2.5 Ghz area..
Hetz (Heunique)
Apple is doing it anyway. Did you see the Rendezvous-enabled iTunes demo during the keynote? Phil was standing there with a TiBook containing an AirPort card. Jobs was at one of the desktop machines. Phil opens the TiBook, and his MP3 library instantly shows up in the iTunes window Jobs has open. Jobs starts playing a song from it. Phil closes the TiBook. The song stops and the library disappears. He opens it again. The library reappears.
This is supposedly shipping early next year.
This space unintentionally left unblank.
The basic problem is historical. There are several layers of emulation in a modem for historical reasons, and each of them adds latency.
Today's modems are actually synchronous devices with a block-oriented link level protocol connected to a parallel data bus inside the computer. But, for historical reasons, they pretend to be asynchronous byte-oriented devices driven off serial ports. This legacy introduces two sources of delay.
The first source of delay is that modems that emulate serial ports clock data into the modem byte by byte, and not at all that fast a rate. This introduces delay just moving the data from the CPU to the modem's buffers, even before it reaches the phone line.
The second source of delay is the conversion of a byte stream to blocks. The modem sees a byte stream to be sent. It's probably a PPP byte stream, divided into packets, but, typically, the modem doesn't know that. The modem has to block that data up into blocks and send it. But the modem doesn't know where the packets begin and end. It has to guess. Typically, it guesses by using an "accumulation timer", which decides that no more bytes are coming when some period of time has elapsed with no data. This, of course, introduces yet more latency.
These two effects interact, making things even worse. The delay in the accumulation timer has to be scaled to the simulated async "data rate", making the unwanted latency even longer.
Modems today ought to be block devices, like Ethernet controllers. Then you'd just blast an IP datagram down to the modem over the PCI bus, and it would start going out on the wire immediately. But there's so much infrastructure built around async modem emulation and PPP that it's hard to change this now.
The "Single Protocol" Stuart is talking about is TCP/IP, not some newfangled daydream.
-pmb
You pretty much summarized it, excpet the part where you proclaim that a whole different networking stack should be created to "make it impossible from it to escape from the LAN."
Mmmmkay.
-pmb
The "single protocol" is TCP/IP.
With Zeroconf, TCP/IP applications can discover each other over local links without network configuration.
So you could have a row of ethernet ports on the back of your machine, and when you attached a keyboard to one of them, the keyboard and _that_ ethernet port would both assign themselves a link-local address, and the keyboard would run a DNS server that advertised that it was a keyboard available at whatever IP address it had selected for itself.
The key is that link-local addresses are NOT routable accross the internet, and can be claimed by the device without a central arbiter.
This is pretty close to how USB already works, except it uses TCP/IP addresses and packets instead of USB ones.
-pmb
The problem isn't going away. Ethernet null-modem cables are widely used with DSL modems, providing an unnecessary source of consumer confusion.
The video production industry gets it. The SMTPE standard connector for fibre-optic broadcast work is hermaphroditic, much to the relief of production crews.
There ought to be hermaphroditic connectors in USB and RJ11-like form factors, but there aren't.
Good points about the cost and distances, but most of the devices designed for the USB and firewire are not things you generally have a 100 feet away from the computer.
As for the cost, it would appear that the vendors have decided cost regardless that putting 6 USB ports on a machine is better than 1 or two serial ports. Gives the users more flexability and the speed makes their products seem faster to the user as well. For things like temperature sensors, serial is awsome (plus easy to program for).
Ethernet doesn't have to use TCP/IP, but yes, it is overkill.
What I want is something that is a generic bus that everything plugs into. VCR outputs, receiver in/out, tv, computer, mouse, keyboard, etc...
That way the VCR can put data on the bus and the computer can pull it off and make use of it. Or a KVM would become as simple as having computer a take its input from the keyboard device 0x245 and mouse device 0x243 and sending output to video device 0x599. Wanna switch, send a signal out on the bus.
Then again, I guess adding fiber and the logic would make my $20 mouse cost a LOT more. Guess I don't wanna pay $540 for a toaster that can send my TV an image of just how well done my toast is.
Don't 56k modems, or at least one of the most common implementations look for PPP packet boundries and send the buffer immediately?
Rated Stupid: 1 month setting up 10BASE5 networks.
Lars T.
To the guy who modded me down from perfect to terrible Karma - Apple haters still suck
Because ethernet isnt deterministic (due to collisions...
Full duplex ethernet doesn't need CSMA/CD.
Lastly, ethernet is big relatively. USB chips cost less than a buck each
"Big relatively"? Nope, they cost the same. Some hardware vendors (that design their own chips), even combine all of the logic for FireWire, USB, Ethernet, & ATA, all onto the same one chip.
-pmb