View Source: AppleTalk - Waikato Linux Users Group

Edit PageHistory Diff Info LikePages
__~AppleTalk__ was a local-area networking protocol stack created by [Apple Computer|Apple]. It was built into every [Macintosh], and also for a long time in practically every PostScript printer, whether sold by Apple or anybody else.

!! Nice Things About ~AppleTalk

__No configuration__ for desktop machines. All network addresses were dynamically assigned, so machines could simply be plugged into the LAN and switched on, and they had full network functionality. Only routers required any actual configuration.

__No need to worry about network addresses at all__. Network services were accessed, not by their addresses, but by user-assigned names. Names mapped, not just to machine addresses, but also to socket numbers (the equivalent of [TCP/IP] port numbers). Thus, unlike in TCP/IP where practically every application-level service needs its own well-known port number assignment, in ~AppleTalk only a few low-level infrastructure services (including of course the name-lookup service itself) needed fixed socket numbers: all application-level services could use dynamically-assigned socket numbers.

__No centralized name servers__. Each machine kept its own track of the names it had registered.

__Names referred to ''services'', not to ''machines''__. This meant that a service could be moved from one machine to another, and provided it kept the same name, users didn't even need to be told this had happened. Compare CNAMEs in the [DNS], which are a bit of a kludge because you have to keep telling people to use the CNAME, not the actual machine name, otherwise the scheme doesn't work.

__Browseability__. Instead of having to type in any service names, you could simply query the network for all services of the desired type, and display them in a list to choose from.

! Printer Access Protocol (PAP)

This was created for the Apple ~LaserWriter, which was the first popular PostScript printer, and a key part of the original Desktop Publishing industry that the Macintosh spearheaded. The early ~LaserWriters were considered too expensive to be connected to just one machine, and since the early Macs didn't have enough grunt to run printer-sharing services while serving desktop users, the logical thing was to build the printer-sharing service into the printer itself.

Unlike that piece of excrement known as [LPD|ftp://ftp.rfc-editor.org/in-notes/rfc1179.txt], PAP implemented a ''full-duplex'' connection. This was particularly important with ~PostScript, because with complicated print jobs it was possible to run into errors with exceeding memory or other printer implementation limits, problems with corrupted fonts etc, so if the communication channel didn't allow you to receive any diagnostics back from the printer, it would be as though your print job had simply disappeared into a black hole.

Another important feature of PAP was ''out-of-band status queries''. This meant that, even while the printer was busy with a print job, it could still respond to status queries from other users' machines, telling them it was busy and with whose job. In this way, all other users trying to print were kept in a "waiting to print" state until the printer was free to service them, instead of simply having their requests abort with a "connection refused" response.

!! Not-So-Nice Things About ~AppleTalk

Machine addresses were only 24 bits. Socket numbers were only 8 bits.

Didn't really scale very well beyond the LAN environment.

Some sysadmin types, more used to TCP/IP, claimed that ~AppleTalk was too "chatty" (used too much network bandwidth maintaining its automatic lookups etc). I think this was questionable: even in the days when 10Mb/s [Ethernet] was considered fast, I never saw this "chat" amount to more than a few percent of bandwidth. For comparison, Novell ~NetWare (which was very popular around the same time) required ''every server'' to periodically broadcast the list of services it was providing, which ~AppleTalk never did--only ~AppleTalk routers were required to do periodic unsolicited broadcasts.

!! The Legacy Of ~AppleTalk

Even though Apple itself has been moving away from ~AppleTalk for some years now, nevertheless its ease of use set a standard that [TCP/IP] is still trying to match. The effort to do this is called ZeroConf, and it is trying add the no-configuration-needed, easy browseability etc as an extra layer on top of standard TCP/IP protocols. I guess the reason they want to do things this way is because building such features into the protocol stack at a lower level would cost too much in performance and scalability (as happened with ~AppleTalk).
2 pages link to AppleTalk:
Last edited on Friday, May 5, 2006 9:45:41 pm by LawrenceDoliveiro
Edit PageHistory Diff Info LikePages