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.
Besides the fact that it's 403'd, the single protocol / plug type is already here with firewire, and/or USB. HD's, modems, NICs, mice all work on one of the two now. It's very nice, if not-so greatly designed.
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.
Didn't apple already try this with firewire, and to a less extent, USB?
I seem to have accidentally stumbled across MacSlash.
News for smarmy elitist artsy-fartsy types who compare their computer to a personal relationship or complain about speakers. Stuff that matters.
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.
HTTP Forbidden error. Nice posting job.
It's called IPv6....done.
... 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.
Lemme gues, this sounds great But am I betting Apple would want a patent on this "Single Protocol" ....Why not right
Here is an opp for someone with a few spare bucks and a patent atty to stick it to the big boys, patent it now, grab it early, I mean how hard can it be to write a patent that says "One protocol to subde them all ?"
I am kidding of course, writng patent abstract is a royal pain if youve ever done it, if they are good enough to withstand scrutiny that is.
Im game, 1 protocol for everything lets call it HTTP, that would rock, native http hard drive, just plug a HD into the network, instant web server.
I mean, wouldnt it be REALLY cool to have EVERYTHING talking back and forth in HTTP, then we would never have to worry about IIS or apache security again, it would ALL be swiss cheese.
(I really hop all you slashdotters know the above is ALL in jest)
Sig went tro...aahemmm.....fishing........
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.
Wouldn't that be FireWire? It'll do storage, peripherals, and act as a transport for TCP/IP right now. No vision needed.
--saint
Rendezvous is great and all, but I doubt it will ever consume more of the poster's time than did Cheshire's most important contribution: the network tank game Bolo *g*
wow ! I didn't know that stuart works at Apple now !
He's the famous author of the ancient bolo game and corresponding cult. Probably died out by now, but I wasted a good part of my eyes and brain on bolo many years ago
When will I end this grieving ? When will my future begin ?
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!
"Didn't apple already try this with firewire, and to a less extent, USB?"
Actually, it's USB that is used for everything from input and storage devices to cameras, microphones, and speakers to modems, printers, scanners, and so on...
Firewire is mostly used for the transfer of stored data to and from things like video cameras and drives.
Either way, I wouldn't say Apple "tried" so much as "succeeded" with their goal.
I'm thinking the name of the protocol will begin fire and end with wire. Wow, that even rhymes!
Umm yep, one interface with one company behind it. Nope there won't be any innovation snuffing there, only stiff licensing fees to anyone who wants to make a product that uses it... hmmm... I worry... but on a lighter side you while you chat about this idea you could: A: Eat Sharp Glass B: Clean your ears out with super glue C: Drive surgical needles under you fingernail then type your 400 page manefesto D: Sexually Experiment with Razor Blades E: Jump rope with a metal chain (insulated handles of course) on an electrified plate carried 2000 amps at 240 volts as you ponder how long it takes before you screw up F: Floss with a mono-filament thread or finally G: Go out and get a college education with a major in "Traversing the 12 Seprioths in a pursuit to become God"
-=[ Who Is John Galt? ]=-
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.
A single protocol for everything, eh? OK. So when someone finds an exploit, they can break EVERYTHING on your system/connected to your system. Wonderful. And let's not forget: 1 protocol = focal point for exploitation which means more manpower to break it which means gets broken even faster than an IIS box. Again, Wonderful.
"I'm just here to regulate funkiness."
You must not have been a very good player!
$2 would get me through a shopping trip to JC Penneys, I'd get 90 minutes easy at Aladdins castle - PLAYING
$5 would get me through an afternoon of bowling...
Of course, this was back when video games were A QUARTER
I read somewhere else that this will go out and find all the printers (and other devices I guess) that are on your network so you have less work to do.
Sounds like it will muss up a clean running IP network like IPX did. If so, no thanks.
- 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.
Yeah, it might be a long time. Whoops! What's that sitting in my component rack? A ReplayTV? And it's doing what? Streaming video to the unit in my bedroom? Wow, that was quick.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.
Before encountering this article I had no idea in the world what Zeroconf was.
Here's their web site. They give a description on the main page.
a3c6 0e89 b1ec aa4d d630 26c8 d07e 7eed 8148 5503 02b4 dfaa 9922 b28d 0820 c4af
I'm just waiting for the mythical Protocol 7.
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.
i think getting all your device (even your micro wave ;) ) will be well done and easy. far easier to have one type of cable and protocol to communicate with each computer device and configure them.
some problems are:
- speed: with ethernet, we are limited to Gigabit (or do you prefer optical everywhere ...) compare to firewire future (1,6 Gbps to 3,2)
- wireless speed: same problem but also battle beetween bluetooth and 802.11b.
on the fact, we risk a poor security because there is one protocol, i said it will increase !
more programmers on one protocol and ONE recognized and universal implementation for all systems Linux, Windows, MacOS X, *BSD, etc...
so we are sure they can interoperate and are securely connected ...
but well, when could i go in the future :-)
So Zeroconf is a protocol for letting devices discover that other devices exist -- without requiring a human to explicitly tell each device.
By Jini, I think he's got it.
Luke, help me take this mask off
Stuart, the author of the addictive Mac tank game Bolo, granted permission several years ago for Windows and Linux versions of the popular game. By the time these were released, Mac Bolo was already out of development and they never really took off in popularity, but they are still developed and available.
The Linux client uses SDL, the Windows client may, too.
Get them here
sm
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
Here's an idea I had. Why instead of inventing new "standards" like Firewire and USB don't we just use ethernet for everything? Network cards are really cheap these days, and integrated into the motherboard.
To avoid requiring a mouse implement a TCP/IP stack another protocol could be used, which would make it impossible from it to escape from the LAN. Then we'd plug the computer into the hub, and the mouse, printer, keyboard and everything else too.
Of course this would be annoying if the network was really busy, but the motherboard could always have a second ethernet connector, and if needed a second hub could be used. The advantages would be greater speed and possibly cheaper prices as network cards cost next to nothing.
Also, wouldn't that be a great way of troubleshooting devices? No more hours spending if a device doesn't work because it's broken of it's not supported. Just start ethereal and watch if it's sending anything.
I belive that GSM uses the 900Mhz area (well, at least at europe) while blue tooth uses the 2.5 Ghz area..
Hetz (Heunique)
Why does everyone have to be 'the next new thing'?
"During times of universal deceit, telling the truth becomes a revolutionary act." - George Orwell, 1984
Actually, Firewire is the official brand identity for IEEE1394 now.
1 cable - It's the epitome of Apple.
Pretty soon even the power will be USB.
Everyone is born right-handed; only the greatest overcome it
Regarding your sig...
I totally agree. Except. If everyone did that and there were no negative mods, goatse.cx and porn posters could mod themselves up too effectively.
I'm happy that I don't see that shazz when I wade in at level 3.
There are no trails. There are no trees out here.
Pls teach me how to randmly abbrev and CAP words like you.
Everyone is leaving out a very important factor: COST! That's the reason different protocols exist at all. RS-232 is one of the cheapest to implement, many CPUs can take it right in on a chip. Also, it works over long distances (100+ feet), something that firewire, USB 2.0, IDE, etc CAN'T do. The compromise: speed. On a desktop, it's not that bad -- you can drop the distance requirement and crank up the speed, but it takes a more expensive chip. Serial-type busses are still cheaper than trying to integrate an ethernet controller and a processor just to move packets around. Let's not forget that TCP/IP has a LOT of overhead compared to a serial bus, and you don't need routability when you're going from point A to point B. Different applications, different protocols. It's just a matter of cost.
Anyone remember the Apple Desktop Bus back from early days? That was pretty slick in itself. Right idea, but it was just a tad too slow.
Here are some links from the IETF website: (documents also mentioned in the interview)
Zero Configuration Networking (zeroconf)
Zeroconf IP Host Requirements
Dynamic Configuration of IPv4 Link-Local addresses [ietf.org]
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.
+4 Insightful?!?
I'm afraid that the parent poster is VERY MUCH incorrect. Firewire, USB, and Bluetooth are all as different from RS232 Serial as, say, a Parallel port.
A month or two I checked out Bolo, too. I played a game with a friend in Dallas. Before we were done, another guy joined our game.
So, there ARE people still playing.
Bolo is a great game for the same reason all great games are great games: Sound fundamental concept/design.
--Richard
They all are optimized for one thing: Moving digital data. The whole point of any port on the back of a computer (except for the power port, of course) is to transfer data from point A to point B. Also, the Universal Port doesn't have to be "optimized" for a single purpose. Just so long as you can teach a monkey how to use it, and the monkey is happy with the port's proformance, then it works. Sure, you could make a port that is faster/cheaper/etc., but no one would buy it, because the Universal Port is everywhere, and it is easy enough, cheap enough, and fast enough.
So why is he such a visionary if Winmodems are so bad?
Winmodems aren't necessarily bad they just have tradeoffs. For example, see this link.
I think the main reason people around here don't like them is because the companies that make them are usually pretty protective of their software drivers. So no one can write Linux drivers for them without some kind of massive reverse engineering.
Never underestimate the power of fiber.
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.
Yes...I know they are light years different, but they are all doing the same thing - moving data from whats at one end of the wire to the other...just like Serial and Parallel does. (Except bluetooth/ir - from one end point to the other).
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.
Oh sweet sweet Bolo how I miss you. I only got to play it at a University once. (I'm in Unveristy now so the glory days of Bolo predated my post secondary)
Random is the New Order.
wow, sounds remarkably like USB or Firewire. BFD.
Don't 56k modems, or at least one of the most common implementations look for PPP packet boundries and send the buffer immediately?
One thing I hate more than IT/MIS consultants that dabble in the occult is IT/MIS consultants that use a proprietary Occult System (OS) like that peddled by MS. When I was a young IT/MIS Consultant, we only had 10 SEPHIROTH (note the spelling, dumbass), and WE WERE GLAD TO HAVE 'EM! I was thinking it would be nice if people posting actually read the material they were posting on, but then I remembered this was /.
It's not offtopic, dumbass. It's orthogonal.
Thank God you were joking. I was "fish-faced" there for a second.