AppleTalk: Difference between revisions
No edit summary |
No edit summary |
||
Line 1: | Line 1: | ||
'''AppleTalk''' is a [[proprietary protocol|proprietary]]off your barnet [[protocol stack|suite of networking protocols]] developed by [[Apple Inc.]] for their [[Apple Macintosh|Mac computers]]. AppleTalk included a number of features that allowed [[local area network]]s to be connected with no prior setup or the need for a centralized router or server of any sort. Simply connecting together AppleTalk equipped systems would automatically assign addresses, update the distributed namespace, and configure any required inter-networking routing. It was a true [[plug-n-play]] system. |
'''AppleTalk''' is a [[proprietary protocol|proprietary]]off your barnet [[protocol stack|suite of networking protocols]] developed by [[Apple Inc.]] for their [[Apple Macintosh|Mac computers]]. AppleTalk included a number of liam mcgowan is a gayy |
||
features that allowed [[local area network]]s to be connected with no prior setup or the need for a centralized router or server of any sort. Simply connecting together AppleTalk equipped systems would automatically assign addresses, update the distributed namespace, and configure any required inter-networking routing. It was a true [[plug-n-play]] system. |
|||
AppleTalk was released for the original Macintosh in 1985, and was the primary protocol used by Apple machinery through the 1980s and 90s. Versions were also released for the [[IBM PC]] and compatibles, and the [[Apple IIGS]]. AppleTalk support was also available in most networked printers (especially [[laser printer]]s), some [[file server]]s and a number of [[router (computing)|router]]s. Through this period, AppleTalk was, by far, the most popular networking system in the world. |
AppleTalk was released for the original Macintosh in 1985, and was the primary protocol used by Apple machinery through the 1980s and 90s. Versions were also released for the [[IBM PC]] and compatibles, and the [[Apple IIGS]]. AppleTalk support was also available in most networked printers (especially [[laser printer]]s), some [[file server]]s and a number of [[router (computing)|router]]s. Through this period, AppleTalk was, by far, the most popular networking system in the world. |
Revision as of 09:52, 11 May 2012
AppleTalk is a proprietaryoff your barnet suite of networking protocols developed by Apple Inc. for their Mac computers. AppleTalk included a number of liam mcgowan is a gayy features that allowed local area networks to be connected with no prior setup or the need for a centralized router or server of any sort. Simply connecting together AppleTalk equipped systems would automatically assign addresses, update the distributed namespace, and configure any required inter-networking routing. It was a true plug-n-play system.
AppleTalk was released for the original Macintosh in 1985, and was the primary protocol used by Apple machinery through the 1980s and 90s. Versions were also released for the IBM PC and compatibles, and the Apple IIGS. AppleTalk support was also available in most networked printers (especially laser printers), some file servers and a number of routers. Through this period, AppleTalk was, by far, the most popular networking system in the world.
The rise of TCP/IP during the 1990s led to a re-implementation of most of these types of support on that protocol, and AppleTalk became unsupported as of the release of Mac OS X v10.6 in 2009. Many of AppleTalk's more advanced auto-configuration features have since been introduced in Bonjour.
History
Prehistory
After the release of the Apple Lisa computer in January 1983, Apple invested considerable effort in the development of a local area networking (LAN) system for the machines. Known as AppleNet, it was based on the seminal Xerox XNS protocol stack but running on a custom 1 Mbsp coaxial cable system, as opposed to 10 Mbit/s Ethernet. AppleNet cards would be provided for the Lisa and the Apple II. It was announced early in 1983 with a fall introduction at the target price of $500.[1]
At that time, early LAN systems were just coming to market, including Ethernet, Token Ring and ARCNET. This was a topic of major commercial effort at the time, dominating shows like the National Computer Conference (NCC) in Anaheim in May 1983. Even at this time, Ethernet's widespread acceptance suggested it was to become a de facto standard.[2] It was at this show that Steve Jobs asked Gursharan Sidhu a seemingly innocuous question, "Why has networking not caught on?"[3]
Four months later, in October, AppleNet was cancelled. At the time, they announced that "Apple realized that it's not in the business to create a networking system. We built and used AppleNet in-house, but we realized that if we had shipped it, we would have seen new standards coming up."[4] In January, Jobs announced that they would instead be supporting IBM's Token Ring, which he expected to come out in a "few months".[4]
AppleBus
Through this period, Apple was deep in development of the Macintosh computer. During development, engineers had made the fateful decision to use the Zilog 8530 serial controller chip (SCC) instead of the lower cost and more common UART to provide serial port connections.[5] The SCC cost about $5 more than a UART, but offered much higher speeds up to 250 kbit/s (or higher with additional hardware) and internally supported a number of basic networking-like protocols like IBM's BiSync.[6]
The SCC was chosen because it would allow multiple devices to be attached to the port. Peripherals equipped with similar SCC's could communicate using the built-in protocols, interleaving their data with other peripherals on the same bus. This would eliminate the need for more ports on the back of the machine, and allowed for the elimination of expansion slots for supporting more complex devices (the Atari 8-bit family used a similar solution, known as SIO). The initial concept was known as AppleBus, envisioning a system controlled by the host Macintosh polling "dumb" devices in a fashion similar to the modern Universal Serial Bus.[7]
AppleTalk
The Macintosh team had already begun work on what would become the LaserWriter, and had considered a number of other options of how to share these expensive machines and other resources. A series of memos from Bob Belleville clarified these concepts, outlining the Mac, LaserWriter and a file server system which would become Macintosh Office.[3] By late 1983 it was clear that IBM's Token Ring would not be ready in time for the launch of the Mac, and might miss the launch of these other products as well. In the end, Token Ring would not ship until 1985.
Jobs' earlier question to Sidhu had already sparked a number of ideas. When AppleNet was cancelled in October, Sidhu led an effort to develop a new networking system based on the AppleBus hardware. This new system would not have to conform to any existing preconceptions, and was designed to be worthy of the Mac - a system that was user-installable, had zero-configuration, and no fixed network addresses - in short, a true plug-and-play network.[8] Considerable effort was needed, but by the time the Mac was released the basic concepts had been outlined and some of the low-level protocols on their way to completion. Sidhu mentioned the work to Belleville only two hours after the Mac was announced.[3]
The "new" AppleBus was announced in early 1984, allowing direct connection from the Mac or Lisa through a small box that plugged into the serial port and connected via cables to the next computer upstream and downstream. Adaptors for Apple II and Apple III were also announced.[9] Apple also announced that AppleBus networks could be attached to, and would appear to be a single node within, a Token Ring system.[4] Details were sketchy.
When the newly-christened AppleTalk shipped in early 1985, it included a number of compromises. These included a speed of 230.4 kbit/s, 1000 feet maximum distance, and only 32 nodes per LAN.[10] However, as the basic hardware was built-in to the Mac, adding nodes cost only about $50 for the adaptor box. The entire networking stack required only about 6 kB of RAM.[11] Additionally, the system was designed for future expansion. The addressing system allowed for expansion to 255 nodes in a LAN, and using "bridges" (which came to be known as routers) one could interconnect LANs into larger collections. "Zones" allowed devices to be addressed within a bridge-connected internet. Additionally, AppleTalk was designed from the start to allow use with any potential underlying physical link.[12]
The relatively slow speed of AppleTalk allowed further reductions in cost. Instead of using RS-422's balanced transmit and receive circuits, the AppleTalk Personal Network cabling used a single common electrical ground, which limited speeds to about 500 kbsp, but allowed one conductor to be removed. This meant that common three-conductor cables could be used. Additionally, the adaptors were designed to be "self-terminating", meaning that nodes at the end of the network could simply leave their last connector unconnected. There was no need for the wires to be connected back together into a loop, nor the need for hubs or other devices. To join an existing network, one simply plugged in the adaptor and connected a cable to the nearest free machine.
AppleTalk was so easy to use that ad-hoc networks tended to appear whenever multiple Macs were in the same room.[13] Apple would later use this in an advertisement showing a network being created between two seats in an airplane.[14]
PhoneNet, EtherTalk and TokenTalk
A thriving 3rd party market for AppleTalk devices developed over the next few years. One particularly notable example was an alternate adaptor designed by BMUG and commercialized by Farallon as PhoneNet.[15] This was essentially a replacement for Apple's connector that had conventional phone jacks instead of Apple's round connectors. PhoneNet allowed AppleTalk networks to be connected together using normal phone wires, even existing runs already being used for phones.
Other companies took advantage of the SCC's ability to use external clocks to support higher transmission speeds up to 1 Mbit/s. In these systems, the external adaptor also included its own clock, and used that to signal the SCC instead of it taking its signal from the computer's internal clock. The higher speed transmissions often required more capable cables. Although they offered greatly improved performance, such solutions remained rare as they were generally incompatible with machines running LocalTalk/PhoneNet, and also required patches to the networking stack that often caused problems.
By 1987 Ethernet was clearly winning the standards battle over Token Ring, and in the middle of that year Apple introduced EtherTalk 1.0 for the newly released Macintosh II computer. The package included both a NuBus card with Ethernet ports and a new Network control panel that allowed the user to select which physical connection to use for networking (from "Built-in" or "EtherTalk"). The release's new networking stack also expanded the system to allow a full 255 nodes per LAN. With its release, AppleTalk Personal Network was renamed LocalTalk.[16] Token Ring would eventually be supported with the similar TokenTalk product, which also used the same Network control panel and underlying software. Many 3rd party companies would introduce compatible Ethernet and Token Ring cards that used these same drivers.
The appearance of EtherTalk also led to a problem - networks with new and old Macs needed some way to communicate between each other. This could be as simple as a network of Ethernet Mac II's trying to talk to a LaserWriter. Apple had considered the problem, and AppleTalk included the possibility for a low-cost LocalTalk-to-Ethernet bridge, but they felt it would be a low-volume product and left it to 3rd parties.[17] A number of companies responded, both existing communications vendors like Hayes and Cisco Systems, as well as newly formed companies like Kinetics. Contrary to Apple's belief these would be low-volume, by the end of 1987, 130,000 such systems were in use. AppleTalk was at that time the most used networking system in the world, with over three times the installations of any other vendor.[18]
AppleTalk Phase II and other developments
A significant re-design was released in 1989 as AppleTalk Phase II. In many ways, Phase II can be considered an effort to make the earlier version (never called Phase I) more generic. LANs could now support more than 255 nodes, and zones were no longer associated with physical networks, but were entirely virtual constructs used simply to organize nodes. For instance, one could now make a "Printers" zone that would list all the printers in an organization, or one might want to place that same device in the "2nd Floor" zone to indicate its physical location. Phase II also included changes to the underlying inter-networking protocols to make them less "chatty", which had previously been a serious problem on networks that bridged over wide-area networks.[19]
By this point Apple had a wide variety of communications products under development, and many of these were announced along with AppleTalk Phase II. These included updates to EtherTalk and TokenTalk, AppleTalk software and LocalTalk hardware for the IBM PC, EtherTalk for Apple's A/UX operating system allowing it to use LaserPrinters and other network resources, and the Mac X.25 and MacX products.
Ethernet had become essentially universal by 1990, and it was time to build Ethernet into Macs direct from the factory. However, the physical wiring used by these networks was not yet completely standardized. Apple solved this problem using an AppleBus-like solution, using a single port on the back of the computer into which the user could plug an adaptor for any given cabling system. This FriendlyNet system was based on the industry-standard Attachment Unit Interface, but deliberately chose a non-standard connector that was smaller and easier to use, which they called "Apple AUI", or AAUI. FriendlyNet was first introduced on the Quadra 700 and Quadra 900 computers, and used across much of the Mac line for some time.[20] As with LocalTalk, a number of 3rd party adaptors quickly appeared.
As 10-BASE-T became the de-facto cabling system for Ethernet, second-generation Power Macintosh machines added a 10-BASE-T port in addition to the AAUI, and eventually dropped AAUI on Macs with the New World ROM.
The capital-I Internet
In 1988 Apple had released MacTCP, a system that allowed the Mac to support TCP/IP on machines with suitable Ethernet hardware. However, this left many universities with the problem of supporting IP on their many LocalTalk-equipped Macs. Stanford University pioneered development of a system, MacIP, that allowed IP packets to be routed over LocalTalk networks with the support of a suitable "gateway" machine. These were initially custom devices, but it was soon common to include such support in a LocalTalk-to-Ethernet bridge.[20] MacTCP would become a standard part of the Mac OS in 1994,[21] by which time it also supported SNMP and PPP.
For some time in the early 1990s, the Mac was a primary client on the rapidly expanding Internet. Among the better known programs in wide use were Fetch, Eudora, NewsWatcher and the NCSA packages, especially NCSA Mosaic and its offspring, Netscape Navigator.[22] Additionally, a number server products appeared that allowed the Mac to host Internet content. Through this period, Macs had about 2 to 3 times as many clients connected to the Internet as any other platform,[23] this in spite of the relatively small overall marketshare.
As the world quickly moved to IP for both LAN and WAN uses, Apple was faced with maintaining two increasingly outdated code bases on an ever-wider group of machines as well as the introduction of the PowerPC based machines. This led to the OpenTransport efforts, which re-implemented both MacTCP and AppleTalk on an entirely new code base adapted from the standard STREAMS. Early versions had problems and did not become stable for some time.[24] By that point, Apple was deep in their ultimately doomed Copland efforts.
Legacy and abandonment
With the purchase of NeXT and subsequent development of Mac OS X, AppleTalk was strictly a legacy system. Support was added to OS X in order to provide support for the large number of existing AppleTalk devices, notably laser printers and file shares, but alternate connection solutions common in this era, notably USB for printers, limited their demand. As Apple abandoned many of these product categories, and all new systems were based on IP, AppleTalk became less and less common. AppleTalk support was finally removed from the MacOS in Mac OS X v10.6 in 2009.[25]
However, the loss of AppleTalk did not reduce the desire for networking solutions that combined its ease-of-use with IP routing. Apple has led development of many such efforts, from the introduction of the AirPort router to the development of the Zero configuration networking system and their implementation of it, Bonjour.
Design
This article needs additional citations for verification. (October 2007) |
The AppleTalk design rigorously followed the OSI model of protocol layering. Unlike most of the early LAN systems, AppleTalk was not built using the archetypal Xerox XNS system. The intended target was not Ethernet, and it did not have 48-bit addresses to route. Nevertheless, many portions of the AppleTalk system have direct analogs in XNS.
One key differentiation for AppleTalk was it contained three 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 a dynamic system for mapping 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 to override the default mechanisms. The concept was to allow routers to provide the information or "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 reduce "chattiness." Together AARP and NBP made AppleTalk an easy-to-use networking system. New machines were added to the network by plugging them and optionally giving them a name. The NBP lists were examined and displayed by a program known as the Chooser which would display a list of machines on the local network, divided into classes such as file-servers and printers.
Addressing
An AppleTalk address was a 4-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 (originally the LocalTalk Link Access Protocol LLAP and later the AppleTalk Address Resolution Protocol, AARP)[26] 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 A records in the DNS, 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 CNAME records indicating service rather than actual machine names to refer to the service, but there is no way of guaranteeing that users will follow such a convention. (Some newer protocols, such as Kerberos and Active Directory use DNS SRV records to identify services by name, which is much closer to the AppleTalk model.)
Protocols
AppleTalk Address Resolution Protocol
AARP resolves AppleTalk addresses to link layer, usually MAC, addresses. It is functionally equivalent to ARP.
AARP is a fairly simple system. When powered on, an AppleTalk machine broadcasts an AARP probe packet asking for a network address, intending to hear back from controllers such as routers. If no address is provided, one is picked at random from the "base subnet", 0. It then broadcasts another packet saying "I am selecting this address", and then waits to see if anyone else on the network complains. If another machine has that address, it will pick another address, and keep trying until it finds a free one. On a network with many machines it may take several tries before a free address is found, so for performance purposes the successful address is "written down" in NVRAM and used as the default address in the future. This means that in most real-world setups where machines are added a few at a time, only one or two tries are needed before the address effectively become constant.
AppleTalk Data Stream Protocol
This was a comparatively late addition to the AppleTalk protocol suite, done when it became clear that a TCP-style reliable connection-oriented transport was needed. Significant differences from TCP were:
- a connection attempt could be rejected
- there were no "half-open" connections; once one end initiated a tear-down of the connection, the whole connection would be closed (i.e., ADSP is full-duplex, not dual simplex).
Apple Filing Protocol
The Apple Filing Protocol (AFP), formerly AppleTalk Filing Protocol, is the protocol for communicating with AppleShare file servers. Built on top of AppleTalk Session Protocol (for legacy AFP over DDP) or the Data Stream Interface (for AFP over TCP), it provides services for authenticating users (extensible to different authentication methods including two-way random-number exchange) and for performing operations specific to the Macintosh HFS filesystem. AFP is still in use in Mac OS X, even though most other AppleTalk protocols have been deprecated.
AppleTalk Session Protocol
ASP was an intermediate protocol, built on top of ATP, which in turn was the foundation of AFP. It provided basic services for requesting responses to arbitrary commands and performing out-of-band status queries. It also allowed the server to send asynchronous attention messages to the client.
AppleTalk Transaction Protocol
ATP was the original reliable transport-level protocol for AppleTalk, built on top of DDP. At the time it was being developed, a full, reliable connection-oriented protocol like TCP was considered to be too expensive to implement for most of the intended uses of AppleTalk. Thus, ATP was a simple request/response exchange, with no need to set up or tear down connections.
An ATP request packet could be answered by up to eight response packets. The requestor then sent an acknowledgement packet containing a bit mask indicating which of the response packets it received, so the responder could retransmit the remainder.
ATP could operate in either "at-least-once" mode or "exactly-once" mode. Exactly-once mode was essential for operations which were not idempotent; in this mode, the responder kept a copy of the response buffers in memory until successful receipt of a release packet from the requestor, or until a timeout elapsed. This way, it could respond to duplicate requests with the same transaction ID by resending the same response data, without performing the actual operation again.**
Datagram Delivery Protocol
DDP was the lowest-level data-link-independent transport protocol. It provided a datagram service with no guarantees of delivery. All application-level protocols, including the infrastructure protocols NBP, RTMP and ZIP, were built on top of DDP. AppleTalk's DDP corresponds closely to the Network layer of the Open Systems Interconnection (OSI) communication model.
Name Binding Protocol
NBP was a dynamic, distributed system for managing AppleTalk names. When a service started up on a machine, it registered a name for itself as chosen by a human administrator. At this point, NBP provided a system for checking that no other machine had already registered the same name. Later, when a client wanted to access that service, it used NBP to query machines to find that service. NBP provided browseability ("what are the names of all the services available?") as well as the ability to find a service with a particular name. Names were human readable, containing spaces, upper and lower case letters, and including support for searching.
AppleTalk Echo Protocol
AEP (AppleTalk Echo Protocol) is a transport layer protocol designed to test the reachability of network nodes. AEP generates packets to be sent to the network node and is identified in the Type field of a packet as an AEP packet. The packet is first passed to the source DDP. After it is identified as an AEP packet, it is forwarded to the node where the packet is examined by the DDP at the destination. After the packet is identified as an AEP packet, the packet is then copied and a field in the packet is altered to create an AEP reply packet, and is then returned to the source node.
Printer Access Protocol
PAP was the standard way of communicating with PostScript printers. It was built on top of ATP. When a PAP connection was opened, each end sent the other an ATP request which basically meant "send me more data". The client's response to the server was to send a block of PostScript code, while the server could respond with any diagnostic messages that might be generated as a result, after which another "send-more-data" request was sent. This use of ATP provided automatic flow control; each end could only send data to the other end if there was an outstanding ATP request to respond to.
PAP also provided for out-of-band status queries, handled by separate ATP transactions. Even while it was busy servicing a print job from one client, a PAP server could continue to respond to status requests from any number of other clients. This allowed other Macintoshes on the LAN that were waiting to print to display status messages indicating that the printer was busy, and what the job was that it was busy with.
Routing Table Maintenance Protocol
RTMP was the protocol by which routers kept each other informed about the topology of the network. This was the only part of AppleTalk that required periodic unsolicited broadcasts: every 10 seconds, each router had to send out a list of all the network numbers it knew about and how far away it thought they were.
Zone Information Protocol
ZIP was the protocol by which AppleTalk network numbers were associated with zone names. A zone was a subdivision of the network that made sense to humans (for example, "Accounting Department"); but while a network number had to be assigned to a topologically-contiguous section of the network, a zone could include several different discontiguous portions of the network.
Physical implementation
The initial default hardware implementation for AppleTalk was a high-speed serial protocol known as LocalTalk that used the Macintosh's built-in RS-422 ports at 230.4 kbit/s. LocalTalk used a splitter box in the RS-422 port to provide an upstream and downstream cable from a single port. The topology was a bus: cables were daisy-chained from each connected machine to the next, up to the maximum of 32 permitted on any LocalTalk segment. The system was slow by today's standards, but at the time the additional cost and complexity of networking on PC machines was such that it was common that Macs were the only networked personal computers in an office. Other larger computers, such as UNIX or VAX workstations, would commonly be networked via Ethernet.
Other physical implementations were also available. One common replacement for LocalTalk was PhoneNet, a 3rd party solution (from a company called Farallon, now called Netopia) that also used the RS-422 port and was indistinguishable from LocalTalk as far as Apple's LocalTalk port drivers were concerned, but ran over the two unused wires in standard four-wire phone cabling. PhoneNet was considerably less expensive to install and maintain. Ethernet and Token Ring was also supported, known as EtherTalk and TokenTalk respectively. EtherTalk in particular gradually became the dominant implementation method for AppleTalk as Ethernet became generally popular in the PC industry throughout the 1990s. Besides AppleTalk and TCP/IP, any Ethernet network could also simultaneously carry other protocols such as DECnet, NetBEUI, and IPX.
Networking model
OSI Model | Corresponding AppleTalk layers |
---|---|
Application | Apple Filing Protocol (AFP) |
Presentation | Apple Filing Protocol (AFP) |
Session | Zone Information Protocol (ZIP) AppleTalk Session Protocol (ASP) AppleTalk Data Stream Protocol (ADSP) |
Transport | AppleTalk Transaction Protocol (ATP) AppleTalk Echo Protocol (AEP) Name Binding Protocol (NBP) Routing Table Maintenance Protocol (RTMP) |
Network | Datagram Delivery Protocol (DDP) |
Data link | EtherTalk Link Access Protocol (ELAP) LocalTalk Link Access Protocol (LLAP) TokenTalk Link Access Protocol (TLAP) Fiber Distributed Data Interface (FDDI) |
Physical | LocalTalk driver Ethernet driver Token Ring driver FDDI driver |
Versions
![]() | This section needs expansion. You can help by adding to it. (June 2008) |
AppleTalk version | Apple Filing Protocol | Corresponds to | Notes |
---|---|---|---|
56 | System 7.0 | ||
57.0.4 | System 7.12 | ||
58.1.1 | System 7.1.2 | ||
58.1.3 | System 7.5 | ||
60.3 | Mac OS 7.6.1 | Open Transport 1.3 | |
60.0a6 | Mac OS 8.6 | Open Transport 2.0.3 | |
3.0 | Mac OS X 10.0.3 | ||
2.1, 2.0 and even 1.1 | Mac OS X v10.2 | ||
2.2, 3.0 and 3.1 | Mac OS X v10.3 | ||
3.2 | Mac OS X v10.4 |
Cross-platform solutions
When AppleTalk was first introduced the dominant office computing platform was the PC compatible running MS-DOS. The "TOPS Teleconnector"[27] system enabled MS-DOS PCs to communicate over AppleTalk network hardware; it comprised an AppleTalk interface card for the PC and a suite of networking software allowing such functions as file, drive and printer sharing. As well as allowing the construction of a PC-only AppleTalk network, it allowed communication between PCs and Macs with TOPS software installed. (Macs without TOPS installed could use the same network but only to communicate with other Apple machines.) The Mac TOPS software did not match the quality of Apple's own either in ease of use or in robustness and freedom from crashes, but the DOS software was relatively simple to use in DOS terms, and was robust.
The BSD and Linux operating systems support AppleTalk through an open source project called Netatalk, which implements the complete protocol suite and allows them to both act as native file or print servers for Macintosh computers, and print to LocalTalk printers over the network.
The Windows Server operating systems supported AppleTalk starting with Windows NT and ending after Windows Server 2003. Miramar included AppleTalk in its PC MacLAN product which was discontinued by CA in 2007. Group Logic continues to bundle its AppleTalk protocol with its ExtremeZ-IP server software for Macintosh-Windows integration which supports Windows 2008 Server and Windows Vista as well prior versions. HELIOS Software GmbH offers a proprietary implementation of the AppleTalk protocol stack, as part of their HELIOS UB2 server. This is essentially a File and Print Server suite that runs on a whole range of different platforms.
In addition, Columbia University released the Columbia AppleTalk Package (CAP) which implemented the protocol suite for various Unix flavors including Ultrix, SunOS, *BSD and IRIX. This package is no longer actively maintained.
Ports Used
Sample iptables rules to allow Netatalk access
# Netatalk needs a flock of ports. # This is the one-line-per-port example, and should work with # older versions of iptables. -A UVAfw -s 128.143.0.0/16 -p tcp --dport 427 -j ACCEPT -A UVAfw -s 128.143.0.0/16 -p udp --dport 427 -j ACCEPT -A UVAfw -s 128.143.0.0/16 -p tcp --dport 548 -j ACCEPT -A UVAfw -s 128.143.0.0/16 -p tcp --dport 201 -j ACCEPT -A UVAfw -s 128.143.0.0/16 -p tcp --dport 202 -j ACCEPT -A UVAfw -s 128.143.0.0/16 -p tcp --dport 204 -j ACCEPT -A UVAfw -s 128.143.0.0/16 -p tcp --dport 206 -j ACCEPT #-A UVAfw -s 137.54.0.0/16 -p tcp --dport 427 -j ACCEPT #-A UVAfw -s 137.54.0.0/16 -p udp --dport 427 -j ACCEPT #-A UVAfw -s 137.54.0.0/16 -p tcp --dport 548 -j ACCEPT #-A UVAfw -s 137.54.0.0/16 -p tcp --dport 201 -j ACCEPT #-A UVAfw -s 137.54.0.0/16 -p tcp --dport 202 -j ACCEPT #-A UVAfw -s 137.54.0.0/16 -p tcp --dport 204 -j ACCEPT #-A UVAfw -s 137.54.0.0/16 -p tcp --dport 206 -j ACCEPT # Multiport variant of the netatalk ports above. # I'm not quite sure why 427 is missing. -A UVAfw -m multiport -s 128.143.0.0/16 -p tcp --dports 548,201,202,204,206 -j ACCEPT
See also
- Netatalk is a free, open-source implementation of the AppleTalk suite of protocols.
- Network File System
- Remote File System
- Samba
- Server Message Block
References
- Citations
- ^ Oppenheimer 2004, Slide 3.
- ^ David Ahl, "1983 National Computer Conference, May 16-19, Anaheim, California", Creative Computing, August 1983, p. 188
- ^ a b c Sidhu, Andrews & Oppenheiner 1989, p. xxiii.
- ^ a b c Bartimo 1984, p. 45.
- ^ Oppenheimer 2004, Slide 6.
- ^ Zilog Z8530 User's Manual", Zilog, p. 1-1
- ^ Oppenheimer 2004, Slide 9.
- ^ Oppenheimer 2004, Slide 10.
- ^ Jim Barimo, "Appl, waiting for IBM net, links micros with AppleBus", InfoWorld, 26 March 1984, pp 45-46
- ^ Oppenheimer 2004, Slide 15.
- ^ Oppenheimer 2004, Slide 19.
- ^ Oppenheimer 2004, Slide 17.
- ^ Lee Larson, "LocalTalk to EtherTalk?", Louisville Computer News, October 1999
- ^ "Apple Computer Ad - Powerbook Networking"
- ^ Oppenheimer 2004, Slide 28.
- ^ Oppenheimer 2004, Slide 30.
- ^ Oppenheimer 2004, Slide 31.
- ^ Oppenheimer 2004, Slide 32.
- ^ Oppenheimer 2004, Slide 34.
- ^ a b Oppenheimer 2004, Slide 36.
- ^ Oppenheimer 2004, Slide 43.
- ^ Oppenheimer 2004, Slide 46.
- ^ Oppenheimer 2004, Slide 51.
- ^ Oppenheimer 2004, Slide 54.
- ^ "Mac OS X v10.6: Mac 101 – Printing". Retrieved on 2009-09-02.
- ^ Sidhu, Andrews & Oppenheiner 1989.
- ^ TOPS Teleconnector MS-DOS networking system over AppleTalk
- Bibliography
Referencing may look daunting, but it's easy enough to do. Here's a guide to getting started. References are important to validate your writing and inform the reader. Any editor can remove unreferenced material, and unsubstantiated articles may end up getting deleted, so when you add something to an article, it's advisable to also include a reference to say from where it came. If you need any assistance, let me know.
- Gursharan Sidhu, Richard Andrews and Alan Oppenheiner, "Inside AppleTalk, Second Edition", Addison-Wesley, 1989, ISBM 0-201-55021
- Jim Bartimo, "Apple, waiting for IBM net, links micros with AppleBus", InfoWorld, 26 March 1984, p. 45
- Alan Oppenheimer, "A History of Macintosh Networking", MacWorld Expo, January 2004