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."
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.
Hey, don't forget his (sadly unimplemented) contribution to improved modem communications:
Number 3: It's the Latency, Stupid
Stuart's official title at Apple is "Wizard Without Portfolio", meaning smart guy not tied to any one department. He's earned that.
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 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.