Penguin
Recent Changes
Annotated edit history of AppleTalk version 3, including all changes. View license author blame.
Rev Author # Line
1 LawrenceDoliveiro 1 __~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.
2
2 LawrenceDoliveiro 3 !! Nice Things About ~AppleTalk
1 LawrenceDoliveiro 4
2 LawrenceDoliveiro 5 __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.
1 LawrenceDoliveiro 6
3 LawrenceDoliveiro 7 __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.
1 LawrenceDoliveiro 8
2 LawrenceDoliveiro 9 __No centralized name servers__. Each machine kept its own track of the names it had registered.
1 LawrenceDoliveiro 10
2 LawrenceDoliveiro 11 __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.
1 LawrenceDoliveiro 12
2 LawrenceDoliveiro 13 __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.
1 LawrenceDoliveiro 14
2 LawrenceDoliveiro 15 ! Printer Access Protocol (PAP)
1 LawrenceDoliveiro 16
2 LawrenceDoliveiro 17 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.
18
19 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.
20
21 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.
22
23 !! Not-So-Nice Things About ~AppleTalk
1 LawrenceDoliveiro 24
3 LawrenceDoliveiro 25 Machine addresses were only 24 bits. Socket numbers were only 8 bits.
1 LawrenceDoliveiro 26
27 Didn't really scale very well beyond the LAN environment.
28
3 LawrenceDoliveiro 29 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.
2 LawrenceDoliveiro 30
3 LawrenceDoliveiro 31 !! The Legacy Of ~AppleTalk
2 LawrenceDoliveiro 32
3 LawrenceDoliveiro 33 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).