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
... 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.
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.
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.
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.
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.
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.
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
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.