 |
Business | Industries | Finance | Tax |
| Index: > A B C D E F G H I J K L M N O P Q R S T U V W X Y Z |
|
|||||
| First Prev [ 1 2 3 ] Next Last |
The design fairly rigorously followed the OSI model of protcol layering. Unlike most other early LAN systems, AppleTalk was not built on the archetypal Xerox XNS system, as the intended target was not Ethernet and did not have 48-bit addresses to route. Nevertheless many portions of the AppleTalk system have direct analogs in XNS.
One key differentiator for AppleTalk was that the system contained two protocols aimed at making the system completely self-configuring. The AppleTalk address resolution protocol (AARP) allowed AppleTalk hosts to automatically generate their own network addresses, and the Name Binding Protocol (NBP) was essentially a dynamic DNS system which mapped network addresses to user-readable names. Although systems similar to AARP existed in other systems, Banyan VINES for instance, nothing like NBP has existed until recently.
Both AARP and NBP had defined ways to allow "controller" devices override the default mechanisms. The concept here was to allow routers to provide all of this information, or additionally "hardwire" the system to known addresses and names. On larger networks where AARP could cause problems as new nodes searched for free addresses, the addition of a router could dramatically reduce "chattiness".
Together AARP and NBP made AppleTalk perhaps the easiest to use networking system yet developed. New machines were added to the network simply by plugging them in, and optionally giving them a name. The NBP lists were examined and displayed by a program known as the Chooser (originally because it allowed you to choose your default printer) which would display a list of machines on the local network, divided into classes such as fileservers and printers. All of this was completely automated.
One problem for AppleTalk was that it was originally intended to be part of a project known as Macintosh Office, which would consist a host machine providing routing, printer sharing and file sharing. However this project was cancelled in 1986, and while the LaserWriter included AppleTalk built-in and could be easily dropped on a network, file sharing and routing was left to third parties. Support for a long time was spotty at best, and did not arrive in convincing form until the early 1990s when much of the market was writing off Apple as dead.
AppleTalk is now considered clunky and often called 'verbose', notably on larger networks and WANs where the naming services generated considerable unwanted traffic.
Today AppleTalk support is provided for backward compatibility in many products, but the default networking on the Mac is TCP/IP. Under Mac OS X versions after v10.2, Apple Rendezvous provides discovery and naming services similar to NBP, while standard DHCP provides setup similar to AARP.
An AppleTalk address was a four-byte quantity. This consisted of a two-byte network number, a one-byte node number, and a one-byte socket number. Of these, only the network number required any configuration, being obtained from a router. Each node dynamically chose its own node number, according to a protocol which handled contention between different nodes accidentally choosing the same number. For socket numbers, a few well-known numbers were reserved for special purposes specific to the AppleTalk protocol itself. Apart from these, all application-level protocols were expected to use dynamically-assigned socket numbers at both the client and server end.
Because of this dynamism, users could not be expected to access services by specifying their address. Instead, all services had names which, being chosen by humans, could be expected to be meaningful to users, and also could be sufficiently long enough to minimize the chance of conflicts.
Note that, because a name translated to an address which included a socket number as well as a node number, a name in AppleTalk mapped directly to a service being provided by a machine, which was entirely separate from the name of the machine itself. Thus, services could be moved to a different machine and, so long as they kept the same service name, there was no need for users to do anything different to continue accessing the service. And the same machine could host any number of instances of services of the same type, without any network connection conflicts.
Contrast this with the DNS in TCP/IP, where a name translates only to a machine address, not including the port number that might be providing a service. Thus, if people are accustomed to using a particular machine name to access a particular service, their access will break when the service is moved to a different machine. This can be mitigated somewhat by insistence on using CNAMEs rather than actual machine names to refer to the service, but there is no way of guaranteeing that users will follow such a convention.
| Politics | Business | Finance |
 |
 |
 |
|