Penguin

Differences between current version and predecessor to the previous major change of AppleTalk.

Other diffs: Previous Revision, Previous Author, or view the Annotated Edit History

Newer page: version 3 Last edited on Friday, May 5, 2006 9:45:41 pm by LawrenceDoliveiro
Older page: version 2 Last edited on Friday, May 5, 2006 9:27:06 pm by LawrenceDoliveiro Revert
@@ -3,9 +3,9 @@
 !! 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. 
+__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. 
@@ -21,13 +21,13 @@
 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. 
+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). 
+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 
+!! 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). 
+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).