Differences between version 2 and predecessor to the previous major change of AppleTalk.
Other diffs: Previous Revision, Previous Author, or view the Annotated Edit History
| Newer page: | version 2 | Last edited on Friday, May 5, 2006 9:27:06 pm | by LawrenceDoliveiro | Revert |
| Older page: | version 1 | Last edited on Friday, May 5, 2006 9:09:59 pm | by LawrenceDoliveiro | Revert |
@@ -1,23 +1,33 @@
__~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
+!
! Nice Things About ~AppleTalk
-Absolutely minimal
configuration. 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
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.
+__
No need to worry about network addresses at all__
. Network services were accessed, not by their addresses, but by user-assigned names.
-No centralized name servers. Each machine kept its own track of the names it had registered.
+__
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.
+__
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.
+__
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 pritner-sharing service into the printer itself.
+!
Printer Access Protocol (PAP)
-! Not-So-Nice Things About ~AppleTalk
+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 (the equivalent of TCP/IP port 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).
+
+!! 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).
