Escolar Documentos
Profissional Documentos
Cultura Documentos
Differential signaling can transmit data at rates as high as 10 million bits per second, or may be sent on cables as long as 1500 meters. Some systems directly interconnect using RS-422 signals, or RS422 converters may be used to extend the range of RS-232 connections. The standard only defines signal levels; other properties of a serial interface are set by other standards. Several key advantages offered by this standard include the differential receiver, a differential driver and data rates as high as 10 megabaud at 12 metres (40 ft). The specification itself does not set an upper limit on data rate, but rather shows how signal rate degrades with cable length. The figure plotting this stops at 10 Mbit/s. RS-422 only specifies the electrical signaling characteristics of a single balanced signal. Protocols and pin assignments are defined in other specifications. The mechanical connections for this interface are specified by EIA-530 (DB-25 connector) or EIA-449 (DC-37 connector), however devices exist which have 4 screw-posts to implement the transmit and receive pair only. The maximum cable length is 1500 m. Maximum data rates are 10 Mbit/s at 12 m or 100 kbit/s at 1200 m. RS-422 cannot implement a truly multi-point communications network such as with EIA-485, however one driver can be connected to up to ten receivers. RS-422 can interoperate with interfaces designed to MIL-STD-188-114B, but they are not identical. RS422 uses a nominal 0 to 5 volt signal while MIL-STD-188-114B uses a signal symmetric about 0 V. However the tolerance for common mode voltage in both specifications allows them to interoperate. Care must be taken with the termination network. EIA-423 is a similar specification for unbalanced signaling (RS-423).
Introduction to RS422
Serial communication methods to transfer information between equipment have been defined by standards for nearly half a century. The oldest and best known standard is RS232, a standard which defines the communication between DTE, data terminal equipment, and DCE, data communication equipment. The relatively short distances and low speed the RS232 serial interface can handle demanded for newer standards like RS422, RS423 and RS485. In this document, I will focus on the RS422 interface for serial balanced differential communications.
RS/EIA/TIA-423 is a standard for serial communications. It defines an unbalanced (single-ended) interface (similar to RS-232), with a single, unidirectional sending driver, and allows for up to 10 receivers (similar to RS-422). It is normally implemented in integrated circuit technology and can also be employed for the interchange of serial binary signals between DTE & DCE. There is no commonpinout for RS-423. The BBC Micro computer used a 5-pin DIN connector. DEC used it extensively with a Modified Modular Jackconnector. This was sometimes called "DEC-423".
Use of a common ground is one weakness of RS-423 (and RS-232): if devices are far enough apart or on separate power systems, the ground will degrade between them and communications will fail, resulting in a condition that is difficult to trace. In this respect the balanced serial connections USB, RS-422 and RS-485 are better,
[1]
are better yet, because of the galvanic isolation provided by the signal transformers.
Introduction to RS423
The RS423 standard is one of the lesser known serial communication standards. Its older brother RS232 is widely known because serial ports with this interface are present on almost all computer systems. RS422and RS485 are differential which makes them useful in applications where noise immunity is an issue, like in industrial applications. The single ended RS423 standard sits somewhere inbetween these standards as an enhancement of RS232 with longer cable lengths and higher allowed data rates. Although RS423 is currently not widely implemented, it has seen a broad usage in the late eighties of the previous century because of its backward compatibility with RS232. Hewlett Packard shipped their computers with a serial interface capable of communicating on both RS232 and RS423 levels and Digital Equipment Corporation used the RS423 signal levels on their DECConnect MMJ serial interface standard. Because RS232 and RS423 are both single ended serial communication standards with comparable signal levels, it was possible to use these RS423 interfaces in both pure RS423 applications, and mixed RS232/RS423 situations.
The maximum allowed cable length with RS423 is 1200 meter, just as with RS422 and RS485. The maximum data rate is 100 kbps which is only five times faster than default RS232 and much slower than possible with RS422 and RS485. Detailed information of the interface characteristics of RS423 can be found in the serial interface comparison table.
AppleTalk is a proprietary suite of networking protocols developed by Apple Inc. for their Macintosh computers. AppleTalk included a number of 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. Connecting together AppleTalk equipped systems would automatically assign addresses, update the distributed namespace, and configure any required inter-networking routing. It was a plug-nplay system. AppleTalk was released for the original Macintosh in 1985, and was the primary protocol used by Apple devices 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. 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 autoconfiguration features have since been introduced in Bonjour, while Universal Plug and Play serves similar needs.
Contents
[hide]
1 History
o o o o o o o o o
1.1 Prehistory 1.2 AppleBus 1.3 AppleBus networking 1.4 AppleTalk 1.5 PhoneNet and other adaptors 1.6 EtherTalk, TokenTalk and AppleShare 1.7 AppleTalk Phase II and other developments 1.8 The capital-I Internet 1.9 Legacy and abandonment
2 Design 3 Addressing
4 Protocols
o o o o o o o o o o o
4.1 AppleTalk Address Resolution Protocol 4.2 AppleTalk Data Stream Protocol 4.3 Apple Filing Protocol 4.4 AppleTalk Session Protocol 4.5 AppleTalk Transaction Protocol 4.6 Datagram Delivery Protocol 4.7 Name Binding Protocol 4.8 AppleTalk Echo Protocol 4.9 Printer Access Protocol 4.10 Routing Table Maintenance Protocol 4.11 Zone Information Protocol
5 Physical implementation 6 Networking model 7 Versions 8 Cross-platform solutions 9 See also 10 References 11 External links
History[edit]
Prehistory[edit]
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 [1] stack but running on a custom 1 Mbit/s coaxial cable system rather than Xerox's 4 Mbit/s Ethernet. AppleNet was announced [2] early in 1983 with a fall introduction at the target price of $500 for plug-in AppleNet cards for the Lisa and the Apple II. 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 theNational Computer Conference (NCC) in Anaheim in May 1983. All of the systems were jockeying for position in the market, but even at this time Ethernet's widespread acceptance suggested [3] it was to become a de facto standard. It was at this show that Steve Jobs asked Gursharan Sidhu a seemingly innocuous [4] question, "Why has networking not caught on?" 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 [5] would have seen new standards coming up." In January, Jobs announced that they would instead be supporting IBM's Token [5] Ring, which he expected to come out in a "few months".
AppleBus[edit]
Through this period, Apple was deep in development of the Macintosh computer. During development, engineers had made the decision to use the Zilog 8530 serial controller chip (SCC) instead of the lower cost and more common UART to [6] provide serial port connections. The SCC cost about $5 more than a UART, but offered much higher speeds up to 250 kilobytes per second (or higher with additional hardware) and internally supported a number of basic networking-like [7] protocols like IBM's Bisync. 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 initial concept was known as AppleBus, envisioning a system controlled by the host [8] Macintosh polling "dumb" devices in a fashion similar to the modern Universal Serial Bus.
AppleBus networking[edit]
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 [4] concepts, outlining the Mac, LaserWriter and a file server system which would become Macintosh Office. 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 [9] products as well. In the end, Token Ring would not ship until October 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[10][third-party source needed] configuration, and no fixed network addresses - in short, a true plug-and-play network. 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 [4] were on their way to completion. Sidhu mentioned the work to Belleville only two hours after the Mac was announced. 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 [11] II and Apple III were also announced. Apple also announced that AppleBus networks could be attached to, and would [5] [5] appear to be a single node within, a Token Ring system. Details of how this would work were sketchy.
AppleTalk[edit]
When the newly-christened AppleTalk shipped in early 1985, it included a number of compromises. These included a speed of [12] 230.4 kbit/s, 1000 feet maximum distance, and only 32 nodes per LAN. Since the basic hardware was built into the Mac, adding nodes only cost about $50 for the adaptor box. In comparison, Ethernet or Token Ring cards cost hundreds or thousands of dollars. The entire networking stack required only about 6 kB of RAM.
[13]
addressing system allowed for expansion to 255 nodes in a LAN (although only 32 could be used at that time), and by using "bridges" (which came to be known as "routers", although technically not the same) one could interconnect LANs into larger collections. "Zones" allowed devices to be addressed within a bridge-connected internet. Additionally, AppleTalk was designed [14] from the start to allow use with any potential underlying physical link. 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 kbit/s, but allowed one conductor to be removed. This meant that common three-conductor cables could be used for wiring. 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 the adaptor into the computer and connected a cable to the nearest machine with a free port. AppleTalk was so easy to use that ad-hoc networks tended to appear whenever multiple Macs were in the same [15] [16] room. Apple would later use this in an advertisement showing a network being created between two seats in an airplane.
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 [22] be a low-volume product and left it to 3rd parties. 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 lowvolume, by the end of 1987, 130,000 such systems were in use. AppleTalk was at that time the most used networking system [23][third-party source needed] in the world, with over three times the installations of any other vendor. 1987 also marked the introduction of the AppleShare product, a dedicated file server that ran on any Mac with 512 kB of RAM or more. A common AppleShare machine was the Mac Plus with an external SCSI hard drive. AppleShare was the #3 [24] network operating system in the late 1980s, behind Novell NetWare and Microsoft MS-NET. AppleShare was effectively the replacement for the failed Macintosh Office efforts, which had been based on a dedicated file server device.
with the support of a suitable "gateway" machine. These were initially custom devices, but it was soon common to include [26] MacIP support in LocalTalk-to-Ethernet bridges. MacTCP would now become a standard part of the Mac OS until [27] 1994, 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, eXodus, NewsWatcher and the NCSA packages, especially NCSA [28] Mosaic and its offspring, Netscape Navigator. Additionally, a number of 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 [29][third-party source needed] platform, despite 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 [30] Unix standard STREAMS. Early versions had problems and did not become stable for some time. By that point, Apple was deep in their ultimately doomed Copland efforts.
[citation needed]
Design[edit]
This section needs additional citations for verification. Please help improve this article by adding citations to reliable sources. Unsourced material may be challenged and removed. (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 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 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[edit]
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 [32] later the AppleTalk Address Resolution Protocol, AARP) 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. As NBP names 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 to a machine's 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 usingCNAME 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 [original research?] Directory use DNS SRV records to identify services by name, which is much closer to the AppleTalk model.
Protocols[edit]
This section does not cite any references or sources. Please help improve this section by adding citations to reliable sources. Unsourced material may be challenged and removed. (June 2012)
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.
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.**
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[edit]
Interior of Apple LocalTalk interface box. In 1989, these boxes typically cost US $90 each. The connectors feature automatic electrical termination of the LocalTalk signal bus; insertion of a LocalTalk bus cable depresses a normally closed switch behind the connector, disabling termination for that connector.
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[edit]
OSI Model Corresponding AppleTalk layers
Application
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
Data link
EtherTalk Link Access Protocol (ELAP) LocalTalk Link Access Protocol (LLAP)
TokenTalk Link Access Protocol (TLAP) Fiber Distributed Data Interface (FDDI)
Physical
Versions[edit]
This section requires expansion. (June 2008)
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
60.0a6
Mac OS 8.6
3.0
Mac OS X 10.0.3
Mac OS X v10.2
Mac OS X v10.3
3.2
Mac OS X v10.4
Cross-platform solutions[edit]
When AppleTalk was first raoed, the dominant office computing platform was the PC compatible running MS-DOS. Apple [33] introduced the AppleTalk PC Card in early 1987, allowing PCs to join AppleTalk networks and print to LaserWriter printers. A [34] [35] year later AppleShare PC was released, allowing PCs to access AppleShare file servers. The "TOPS Teleconnector" MSDOS networking system over AppleTalk</ref> 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. GroupLogic continues to bundle its AppleTalk protocol with its ExtremeZ-IP server software for Macintosh-Windows integration which supports Windows 2008 Serverand 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.