g r o t t o 1 1

Peeve Farm
Breeding peeves for show, not just to keep as pets
  Blog \Blôg\, n. [Jrg, fr. Jrg. "Web-log".
     See {Blogger, BlogSpot, LiveJournal}.]
     A stream-of-consciousness Web journal, containing
     links, commentary, and pointless drivel.


On My Blog Menu:

InstaPundit
USS Clueless
James Lileks
Little Green Footballs
As the Apple Turns
Entropicana
Cold Fury
Capitalist Lion
Red Letter Day
Eric S. Raymond
Tal G in Jerusalem
Secular Islam
Aziz Poonawalla
Corsair the Rational Pirate
.clue

« ? Blogging Brians # »





Book Plug:

Buy it and I get
money. I think.
BSD Mall




 10/6/2003 -  10/8/2003
 9/29/2003 -  10/5/2003
 9/22/2003 -  9/28/2003
 9/15/2003 -  9/21/2003
  9/8/2003 -  9/14/2003
  9/1/2003 -   9/7/2003
 8/25/2003 -  8/31/2003
 8/18/2003 -  8/24/2003
 8/11/2003 -  8/17/2003
  8/4/2003 -  8/10/2003
 7/28/2003 -   8/3/2003
 7/21/2003 -  7/27/2003
 7/14/2003 -  7/20/2003
  7/7/2003 -  7/13/2003
 6/30/2003 -   7/6/2003
 6/23/2003 -  6/29/2003
 6/16/2003 -  6/22/2003
  6/9/2003 -  6/15/2003
  6/2/2003 -   6/8/2003
 5/26/2003 -   6/1/2003
 5/19/2003 -  5/25/2003
 5/12/2003 -  5/18/2003
  5/5/2003 -  5/11/2003
 4/28/2003 -   5/4/2003
 4/21/2003 -  4/27/2003
 4/14/2003 -  4/20/2003
  4/7/2003 -  4/13/2003
 3/31/2003 -   4/6/2003
 3/24/2003 -  3/30/2003
 3/17/2003 -  3/23/2003
 3/10/2003 -  3/16/2003
  3/3/2003 -   3/9/2003
 2/24/2003 -   3/2/2003
 2/17/2003 -  2/23/2003
 2/10/2003 -  2/16/2003
  2/3/2003 -   2/9/2003
 1/27/2003 -   2/2/2003
 1/20/2003 -  1/26/2003
 1/13/2003 -  1/19/2003
  1/6/2003 -  1/12/2003
12/30/2002 -   1/5/2003
12/23/2002 - 12/29/2002
12/16/2002 - 12/22/2002
 12/9/2002 - 12/15/2002
 12/2/2002 -  12/8/2002
11/25/2002 -  12/1/2002
11/18/2002 - 11/24/2002
11/11/2002 - 11/17/2002
 11/4/2002 - 11/10/2002
10/28/2002 -  11/3/2002
10/21/2002 - 10/27/2002
10/14/2002 - 10/20/2002
 10/7/2002 - 10/13/2002
 9/30/2002 -  10/6/2002
 9/23/2002 -  9/29/2002
 9/16/2002 -  9/22/2002
  9/9/2002 -  9/15/2002
  9/2/2002 -   9/8/2002
 8/26/2002 -   9/1/2002
 8/19/2002 -  8/25/2002
 8/12/2002 -  8/18/2002
  8/5/2002 -  8/11/2002
 7/29/2002 -   8/4/2002
 7/22/2002 -  7/28/2002
 7/15/2002 -  7/21/2002
  7/8/2002 -  7/14/2002
  7/1/2002 -   7/7/2002
 6/24/2002 -  6/30/2002
 6/17/2002 -  6/23/2002
 6/10/2002 -  6/16/2002
  6/3/2002 -   6/9/2002
 5/27/2002 -   6/2/2002
 5/20/2002 -  5/26/2002
 5/13/2002 -  5/19/2002
  5/6/2002 -  5/12/2002
 4/29/2002 -   5/5/2002
 4/22/2002 -  4/28/2002
 4/15/2002 -  4/21/2002
  4/8/2002 -  4/14/2002
  4/1/2002 -   4/7/2002
 3/25/2002 -  3/31/2002
 3/18/2002 -  3/24/2002
 3/11/2002 -  3/17/2002
  3/4/2002 -  3/10/2002
 2/25/2002 -   3/3/2002
 2/18/2002 -  2/24/2002
 2/11/2002 -  2/17/2002
  2/4/2002 -  2/10/2002
 1/28/2002 -   2/3/2002
 1/21/2002 -  1/27/2002
 1/14/2002 -  1/20/2002
  1/7/2002 -  1/13/2002
12/31/2001 -   1/6/2002
12/24/2001 - 12/30/2001
12/17/2001 - 12/23/2001
Wednesday, July 31, 2002
13:48 - File Sharing-- the way it was meant to be

(top) link
This morning, I was copying an image file-- a silly Photoshopped gag image-- from my desktop machine at home (where I had originally saved it off the Web) to my iMac in the office so that I could show it off to my friends there. In the middle of doing so, I realized that there's a whole lot about that process that I take for granted as a Mac user.

Long ago, back around 1985, when "workgroups" were a pie-in-the-sky office networking dream, and long before anybody had ever considered running FTP or Web servers on their desktop computers, Apple was creating something called AppleTalk. This was a zero-configuration, transport-independent, routable, point-to-point networking protocol that could support file servers and printer sharing with the click of a single button. In the age when only the elite of the computer industry had ever programmed TCP/IP settings or assigned an IP address, AppleTalk pointed toward something light-years beyond what IPv4 promised.

Imagine-- you open up your server browser, and every server in your current routing zone would automatically show up, listed by its plain-English name; you could switch to a different zone if you wanted, or double-click on one of the servers and be prompted for either guest access (which would give you limited access to the resources there) or authenticated user access (giving you free rein over those resources, as configured by the server owner). Then, once you had access, the server's resource would appear on your desktop as though it were another disk, and you could drag files to and from it to your heart's content.

This wasn't just a simple file transfer mechanism either, like FTP or HTTP. This was a complete meta-data-preserving protocol, in which custom icons and resource forks would be dutifully copied, Type and Creator bindings would be maintained, and date stamps would be preserved as made sense. You weren't simply opening a new file with the same name as some file on a remote system and then dumping data into it; you were making a total duplicate of the resource, with all its attendant details, that you could use on your local system just as though you had copied the file there using a floppy disk. Remote resources became part of the local system while the remote server was mounted; files created by applications on remote servers, when double-clicked, would automatically connect to the server and find the application in order to open in it. You could even create aliases to remote resources which would automatically dial the modem, connect to a remote network, mount the resource, and open it with your stored privileges.

AppleTalk machines, when they came online, would automatically assign themselves an address from the available space, and through broadcasts would immediately appear in everybody else's browse lists. Stories abounded about how fun the testing of this protocol was; Kris tells of how at one point, a lab full of several dozen machines were all artificially preprogrammed with a zeroed-out AppleTalk address, and then they were all brought online at once. Every machine broadcast to see whether their own addresses were unique-- and got back replies to the effect that no, they certainly were not. Every machine simultaneously jumped to a random new address, and broadcast again. Some inevitably still had collisions, and had to jump two or three times. But, as the story goes, everything had all settled out within about eight seconds; everybody was on a unique address and ready to talk.

All this back in 1985.

If you had a collection of pictures on one Mac, you effectively had them on all your Macs-- because you could always access them from any of the machines.

Other companies recognized the importance of this kind of connectivity; Microsoft built AppleTalk server support into Windows NT, and AppleTalk routers became entrenched into college campuses the world over. A student could spend many happy hours perusing the various zones throughout the campus and giggling at the clever names other students had assigned to their Macs. (My favorite, at Caltech, was "Bhoutros Bhoutros Duo".)

Eventually, though, two things happened to render AppleTalk irrelevant except among Mac users. The first was the widespread adoption of TCP/IP. And the second was Windows SMB/CIFS file sharing.

TCP/IP became the default Internet protocol because of its easily scalable routability. While AppleTalk was indeed routable, its address space-- designed for browsing rather than for direct connections-- became cumbersome and imprecise for widespread connectivity to really take hold. (Besides, it only really applied to Macs.) All the major services powering the nascent Internet ran on UNIX servers, which meant TCP/IP was the language of FTP and the Web and e-mail, and soon both Windows and the Mac had full TCP/IP implementations in their operating systems; on the Mac this was in addition to AppleTalk, which remained on board for LAN networking-- nice and convenient, and a lot easier than having to deal with TCP/IP settings, but only useful for talking Mac-to-Mac within an office environment.

And by this time, Windows had incorporated SMB into its networking suite, enabling its users to do just about everything that Mac users could do with AppleTalk. (Almost.) SMB shares in a zone could be browsed; remote apps could be run without being installed locally (well, unless they wanted to muck with the Registry, which they often did); users could set up multiple shares on their machines and define labels for them and for the entire networked computer; shortcuts could point to remote shares and mount them automatically.

But SMB, like AppleTalk, was not easily scalable, and routing between zones was nearly impossible. SMB was designed to be much more flat than AppleTalk ever was, and while hierarchies of domains and workgroups could be set up, routing SMB traffic outside the LAN was (and remains) the subject of night sweats among IT administrators all over. You can't file-share to your Windows machine at home, for instance, from your Windows machine at work.

Apple realized that the world had sidestepped their plans for networking and had gone down a different road. They knew that AppleTalk would not survive as a non-IP protocol, because more and more new routers being implemented didn't support (or the administrators didn't bother to configure) AppleTalk routing. The elegant hierarchical zone approach, with its named lists of servers, wasn't going to work in a world of direct point-to-point client-server connectivity. So, in Mac OS 8, they shifted gears, and out came AppleTalk/IP.

It worked just like AppleTalk, as far as the file-sharing and the authentication parts were concerned. The big difference was that instead of having to browse through a list of machines on the LAN, you could now specify a direct IP address or hostname, and it would connect directly to that machine-- no matter where on the real, live, TCP/IP-based Internet it was. Mount a friend's drive in Rhode Island from your laptop in the San Francisco airport? No problem. Grab those movie files off your home machine's desktop and show them to people at work? Go right ahead. While Windows users had to install FTP servers and wrestle with IIS and move files around to get them into the right place for sharing before leaving the machine's presence if they wanted to fetch files off them remotely, Mac users simply connected to the remote machine and mounted the share they needed.

And in Mac OS X, it became even simpler-- setting up shares became nearly irrelevant, as the system's multi-user nature asserted its dominance over what had previously been a confusing mess of assignable per-user privileges. Now, a guest user (if allowed access) could only mount each user's Public folder, inside which was a Drop Box that he could copy files into (but could not open); a neat way for users without accounts on the server to be able to send files to the server's owner or to other users without any risk. But an authenticated user could mount not only other users' Public folders, but also his own complete Home folder, or (if he had Administrator privileges) the entire disk. Or other disks in the system. And once that share was mounted on the remote user's desktop, he could copy files to and from it as though it were a local disk.

With AppleTalk/IP, Mac users have their long-time capabilities back, scaled to match the modern Internet. If we have files on one Mac, we have those same files on any Mac-- regardless, now, of what transport connects those machines, or even where in the country they might respectively be. I can sit on the couch downstairs with my iBook, browsing the image files from my desktop machine upstairs while connected wirelessly via AirPort. I can grab my in-progress book chapters from the home machine and copy them to my computer at work without having to do anything to the home machine but connect to it. The only configuration involved in AppleTalk is flipping the "on" switch, as always.

And now it's just part of a pantheon. We've also got "on" switches for the Web and FTP servers, for SSH connections, and even for impersonating an SMB server to other Windows machines (when Jaguar arrives).

But it's still not quite good enough for Apple. You see, it's flexible-- but it's not elegant. It's not truly zero-configuration, like AppleTalk was back in its early conception. It still has to deal with DHCP servers, TCP/IP settings, gateways, masquerading, leases-- it's just not as seamless as it could be.

Well, good news: it's all coming full circle, with Rendezvous.

We're on our way back to the original promise of networking that we had in front of us in 1985. When Rendezvous is here, not only will we not have to configure any network settings (all the machines will negotiate working settings between them all whenever anybody appears on the network), but sharable services will build themselves into browseable lists for everybody on the network to peruse. Within the local zone, iTunes playlists and iChat partners will automatically make themselves available to each other's machines, Mail will notify us when someone who has sent us a message is on the network and available to contact directly, printers will automatically configure themselves without any setup beyond plugging them in-- and that's just the first iteration, before we've discovered what this can really mean for us.

Meanwhile, I don't find myself deprived at all of functionality and ease, since I was able to simply hop over to my home machine and grab that picture off the desktop. I'm sure this capability will eventually make it into Windows, and when it does, everybody will hail it as a great advancement that they're not sure how they were ever able to get by without; but I've taken it for granted all these years. It's easy to lose sight of the magic of a piece of technology if you use it every day of your life, enough so that you come to depend on it.

Every time someone tries to send me a file over the fitful and crash-prone ICQ transfer protocol, or has to put a file up on a Web server somewhere, or has to fire up Gnutella or KaZaA to try to get a reliable cross-network point-to-point transfer going, I'm struck by the wistful feeling of something beautiful that we'll never be able to enjoy to its full potential-- and it's made all the more stark every time Marcus tells me "Hey, check your Drop Box-- I put another couple of files in there for you".

It could all be this easy. Somewhere out there, there's an alternate Earth where it is.



UPDATE: As clarified by Kris, the big AppleTalk settling-out test actually occurred in 1989, when the new Ethernet-based implementation of AppleTalk (called EtherTalk) was being developed. Prior to that, AppleTalk was designed to operate over serial cables, and because of the characteristics and limitations of serial topologies, the settling-out behavior wouldn't have been anywhere near as dramatic as it was over Ethernet.



Back to Top


© Brian Tiemann