DEPARTMENT OF COMPUTER SCIENCE AND ENGINEERING

CMR COLLEGE OF ENGINEERING & TECHNOLOGY

An Autonomous Institution under UGC, Approved by AICTE, Accredited by NAAC with ‘A’ Grade)

Kandlakoya, Medchal Road, Hyderabad-501401

 A Technical Seminar report on

APPLE TALK
A Dissertation submitted to JNTU Hyderabad in partial fulfilment of
the academic requirements for the award of the degree.

Bachelor of Technology
In
Computer Science and Engineering

Submitted by

Beldhe Pranathi
(15H51A0572)

Department of Computer Science & Engineering

CMR COLLEGE OF ENGINEERING ANDTECHNOLOGY

(An Autonomous Institution under UGC & JNTUH , Approved by AICTE, Permanently Affiliated to JNTUH, Accredited by NAAC with ’A’ Grade.)
KANDLAKOYA, MEDCHAL ROAD, HYDERABAD - 501401.

2015- 2019
 CMR COLLEGE OF ENGINEERING & TECHNOLOGY
KANDLAKOYA, MEDCHAL ROAD, HYDERABAD – 501401

DEPARTMENT OF COMPUTER SCIENCE AND ENGINEERING

CERTIFICATE

This is to certify that the Project report entitled "APPLE TALK" being
submitted by Beldhe Pranathi(15H51A0572), in partial fulfilment for the award of
Bachelor of Technology in Computer Science and Engineering is a record of
bonafide work carried out his/her under my guidance and supervision.
The results embodies in this project report have not been submitted to
any other University or Institute for the award of any Degree.

Dr. K. Vijaya Kumar Koppula

Professor and HOD

CSE Department
 ACKNOWLEDGMENT

With great pleasure I want to take this opportunity to express my heartfelt gratitude to all
the people who helped in making this project work a grand success.

I acknowledge my special thanks to my Seminar Coordinator, Dr. Dilshad Ansari,

Department of Computer Science and Engineering for her constant encouragement, valuable
guidance and help in the successful completion of the seminar.

I acknowledge my special thanks to my Seminar Coordinator, Mrs. Anjusha,

Department of Computer Science and Engineering for her constant encouragement, valuable
guidance and help in the successful completion of the seminar

I would like to thank Dr. K. Vijaya Kumar Koppula, Head of the Department of
Computer Science and Engineering, for his moral support throughout the period of my study in
CMRCET.

I am highly indebted to Dr. V. A. Narayana, Principal CMRCET for giving permission

to carry out this project in a successful and fruitful way.

I would like to thank the Teaching & Non- teaching staff of Department of Computer
Science and Engineering for their co-operation

Finally I express my sincere thanks to Mr. Ch. Gopal Reddy, Secretary, CMR Group of
Institutions, for his continuous care. I sincerely acknowledge and thank all those who gave
support directly and indirectly in completion of this project work.

Beldhe Pranathi
(15H51A0572)

i
 TABLE OF CONTENTS

CHAPTER PAGE
NO. TITLE NO.
ABSTRACT 1

1 INTRODUCTION

1.1 Apple talk 2

1.2 Ether Talk, Token Talk, AppleShare 3

1.3 PhoneNet and other adapters 5

2 DESIGN 6

3 ADDRESSING 9

4 PROTOCOLS 11

4.1 AppleTalk Address Resolution Protocol

4.2 AppleTalk Data Stream Protocol
4.3 Apple Filing Protocol
4.4 AppleTalk Session Protocol
4.5 Datagram Delivery Protocol
4.6 Name Binding Protocol
4.7 AppleTalk Echo Protocol
4.8 Printer Access Protocol
4.9 Routing Table Maintenance Protocol
4.10 Zone Information Protocol
5 PHYSICAL IMPLEMENTATIONS 15

6 NETWORKING MODEL 16

7 CROSS-PLATFORM SOLUTIONS 19

8 SECURITY 20

9 CONCLUSION 22

10 REFERENCES 23

ii
 LIST OF FIGURES

FIGURE PAGE NO

1. Basic working of image enhancement 5

2. Electromagnetic Spectrum 6

3. Image captured during light 7

4. Image captured during dark 7

5. Image captured in total darkness 8

6. Thermal imaging system 8

7. Captured image by thermal imaging 9

8. Basic components of image enhancement 10

9. Output image obtained by image enhancement 11

10. DARK INVADER Multi-purpose Pocket scope 16

11. Goggles 16

12. Stealth 301 Series Day/Night Video Camera 17

iii
 ABSTRACT

AppleTalk is a network operating system designed to connect Apple computers. Its components
are built on Macintosh operating systems. There are two main versions of AppleTalk depending
on how many years in the past the network was implemented, Phase 1 and Phase 2. Phase 2 is
the current installation as of about 2002.AppleTalk/Local Talk networks make use of CSMA/CA
a media access control method. STP cabling is usually used. But it is possible to use UTP or
Fiber Optic cabling depending on cost and/or performance issues. The network topology is a bus
or tree. A Local Talk network is limited to 32 nodes. Local Talk is the data link layer protocol
originally used for Macintoshes. Macintosh computers using Local Talk are linked together
using their printer ports. AppleShare is used as the file and print sharing protocol on AppleTalk
networks. AppleTalk networks make use of an addressing scheme in which each computer when
it comes online: looks for a stored address that it used in a previous session , if one isn't available
then it chooses an address at random from those that are available , then it broadcasts the address
to make sure no other computer is using it , if it is being used then it tries another, if it isn't being
used then it stores the address to potentially be used again when it returns online the next time.

AppleTalk was designed for small networks. Fortunately, these small networks can be connected
together. Each subnetwork is called a zone and has a name for identification. Resources in other
zones can be configured so that they can be accessed by a click on the zone name. AppleTalk
networks can be fairly directly connected to networks of other architectures such as Ethernet or
Token Ring. Apple has developed Ether Talk or Token Talk, which are cards that enable
Macintosh computers to connect to networks operating under 802.3 and 802.5 specifications,
respectively

1
APPLE TALK
 CHAPTER -1
1 INTRODUCTION
AppleTalk is a set of proprietary networking protocols developed by Apple for their computer
systems. AppleTalk was included in the original Macintosh released in 1984. In 2009, it became
unsupported with the release of Mac OS X v10.6 and was dropped in favor of TCP/IP
networking, allowing Apple computers to use the same standard to communicate with other
computers.

The design of AppleTalk followed the OSI Model of protocol layering with two protocols aimed
at making the system completely self-configuring:

AppleTalk Address Resolution Protocol (AARP): Allowed hosts to automaticall generate their
own network addresses

Name Binding Protocol (NBP): A dynamic system that maps network addresses to user-readable
names. Macintosh computers using Local Talk are linked together using their printer ports.
AppleShare is used as the file and print sharing protocol on AppleTalk networks. AppleTalk
networks make use of an addressing scheme in which each computer when it comes online:
looks for a stored address that it used in a previous session , if one isn't available then it chooses
an address at random from those that are available , then it broadcasts the address to make sure
no other computer is using it , if it is being used then it tries another, if it isn't being used then it
stores the address to potentially be used again when it returns online the next time.

AppleTalk networks can be fairly directly connected to networks of other architectures such as
Ethernet or Token Ring. Apple has developed Ether Talk or Token Talk, which are cards that
enable Macintosh computers to connect to networks operating under 802.3 and 802.5
specifications, respectively

2
APPLE TALK
1.1 APPLE TALK

Just prior to its release in early 1985, AppleBus was renamed AppleTalk. The system had a
number of limitations, including a speed of only 230.4 kbit/s, a maximum distance of 1000 feet
from end to end, and only 32 nodes per LAN. But as 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.

Additionally, the entire networking stack required only about 6 kB of RAM, allowing it to run on
any Mac.

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.

The system was designed for future expansion; the 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 from the start to allow use with any potential underlying
physical link.

The main advantage of AppleTalk was that it was completely maintenance-free. To join a device
to a network, you simply plugged the adaptor into the machine, then connected a cable from it to
any free port on any other adaptor.

AppleTalk's internal protocols negotiated a working network address number, automatically gave
the computer a human-readable name, and collected up a list of the names and types of other
machines on the network so the user could browse the devices through the GUI-based Chooser.
AppleTalk was so easy to use that ad-hoc networks tended to appear whenever multiple Macs
were in the same room. Apple would later use this in an advertisement showing a network being
created between two seats in an airplane.

3
APPLE TALK
1.2 ETHER TALK, TOKEN TALK AND APPLE SHARE

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.[21]
Token Ring would eventually be supported with the similar TokenTalk product, which used the
same Network control panel and underlying software. Many third 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 IIs 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 third parties.[22] 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.[23]
[third-party source needed] 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 network
operating system in the late 1980s, behind Novell NetWare and Microsoft's MS-Net.[24]
AppleShare was effectively the replacement for the failed Macintosh Office efforts, which had
been based on a dedicated file server device.

4
APPLE TALK
1.3 PHONENET AND OTHER ADAPTERS

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 in 1987.[17] 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 telephone wires, and with very little
extra work, could run analog phones and AppleTalk on a single four-conductor phone cable.

Other companies took advantage of the SCC's ability to read external clocks in order 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's clock input pins. The best known such system was
Centram's FlashTalk, which ran at 768 kbit/s, and was intended to be used with their TOPS
networking system.[18] A similar solution was the 850 kbit/s DaynaTalk, which used a separate
box that plugged in between the computer and a normal LocalTalk/PhoneNet box. Dayna also
offered a PC expansion card that ran up to 1.7 Mbit/s when talking to other Dayna PC cards.[19]
[20] Several other systems also existed with even higher performance, but these often required
special cabling that was incompatible with LocalTalk/PhoneNet, and also required patches to the
networking stack that often caused problems.

CHAPTER-2
5
APPLE TALK
2. DESIGN
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[citation needed].

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.

CHAPTER-3

6
APPLE TALK
3. ADDRESSING
An AppleTalk address was a 4-byte quantity. This consisted of a two-byte network number, 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)[33] 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 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 in order 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 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.

CHAPTER-4
7
APPLE TALK
4.1 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.

4.2 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).

4.3 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 macOS, even though most other AppleTalk protocols have been deprecated

8
APPLE TALK
4.4 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 d performing
out-of-band status queries. It also allowed the server to send asynchronous attention messages to
the client.

4.5 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.

4.6 Name Binding Protocol

Name Binding Protocol 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.

4.7 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.

4.8 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

9
APPLE TALK
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.

4.9 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.

4.10 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.

10
APPLE TALK
 CHAPTER- 5
5 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. A very popular replacement for LocalTalk
was PhoneNet, a 3rd party solution from Farallon Computing, Inc. (renamed Netopia, acquired
by Motorola in 2007) 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.
Foreshadowing today's network hubs and switches, Farallon provided solutions for PhoneNet to
be used in "star" as well as bus configurations, with both "passive" star connections (with the
phone wires simply bridged to each other at a central point), and "active" star with "PhoneNet
Star Controller" hub hardware.
Apple's LocalTalk connectors didn't have a locking feature, so connectors could easily come
loose, and the bus configuration resulted in any loose connector bringing down the whole
network, and being hard to track down. PhoneNet RJ-11 connectors, on the other hand, snapped
into place, and in a star configuration any wiring issue only affected one device, and problems
were easy to pinpoint. PhoneNet's low cost, flexibility, and easy troubleshooting resulted in it
being the dominant choice for Mac networks into the early 1990s.
AppleTalk protocols also came to run over Ethernet (coaxial and then twisted pair) and Token
Ring physical layers, labeled by Apple as EtherTalk and TokenTalkrespectively. EtherTalk
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 and IPX.

11
APPLE TALK
 CHAPTER-6
6.1 Networking Model

OSI Model Corresponding AppleTalk layers

Application Apple Filing Protocol (AFP)

Presentation Apple Filing Protocol (AFP)

Zone Information Protocol (ZIP)

Session AppleTalk Session Protocol (ASP)
AppleTalk Data Stream Protocol (ADSP)

AppleTalk Transaction Protocol (ATP)

AppleTalk Echo Protocol (AEP)
Transport
Name Binding Protocol (NBP)
Routing Table Maintenance Protocol (RTMP)

Network Datagram Delivery Protocol (DDP)

EtherTalk Link Access Protocol (ELAP)

LocalTalk Link Access Protocol (LLAP) 
Data link
TokenTalk Link Access Protocol (TLAP) 
Fiber Distributed Data Interface (FDDI)

LocalTalk driver
Ethernet driver
Physical
Token Ring driver
FDDI driver

12
APPLE TALK
 CHAPTER-7

7.1 CROSS-PLATFORM SOLUTIONS

When AppleTalk was first introduced, the dominant office computing platform was the PC
compatible running MS-DOS. Apple introduced the AppleTalk PC Card in early 1987, allowing
PCs to join AppleTalk networks and print to LaserWriter printers.[34] A year later AppleShare
PC was released, allowing PCs to access AppleShare file servers.[35]

The "TOPS Teleconnector"[36] MS-DOS networking system over AppleTalk 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 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.

13
APPLE TALK
 CHAPTER-8

8.1 SECURITY
AppleTalk, like many network protocols, makes no provisions for network security. The design
of the AppleTalk protocol architecture requires that security measures be implemented at higher
application levels. Cisco supports AppleTalk distribution lists, allowing control of routing
updates on a per-interface basis. This security feature is similar to those that Cisco provides for
other protocols. Note that the Cisco implementation of AppleTalk does not forward packets with
local source and destination network addresses. This behavior does not conform to the definition
of AppleTalk in the Apple Computer inside AppleTalk publication. However, this behavior is
designed to prevent any possible corruption of the AARP table in any AppleTalk node that is
performing address gleaning Through MAC.

Advantages
 Apple automatically includes AppleTalk in the Macintosh operating system.

 Easy to implement and configure

 Setting up a small workgroup is simple and inexpensive

Disadvantages
 It is not suitable for very large networks

 It is very slow compared to other LAN links at 230.4 Kbps

 It is unsuitable for bandwidth intensive applications

14
APPLE TALK
 CONCLUSION

AppleTalk includes an address-resolution method much like TCP/IP's ARP. The AppleTalk
version is called AARP.

AARP uses broadcasts to discover the hardware address of a node. The primary network layer
routing protocol in AppleTalk is the Datagram Delivery Protocol (DDP).

DDP provides a best-effort connectionless datagram service. There are five key implementations
of the transport layer in AppleTalk: RTMP, NBP, AURP, ATP, and AEP

15
APPLE TALK
 REFERENCES
W. de Leeuw and R. van Liere. Case Study: Comparing Two Methods for Filtering External
Motion in 4D Confocal Microscopy Data. Joint Eurographics .

W.E. Lorensen and H.E. Cline. Marching cubes: a high resolution 3D surface construction
algorithm. Computer Graphics (Siggraph’87 Proceedings), 21(4), pp163-169.

M. Levoy. Display of surfaces from volume data. Computer Graphics & Application

16
APPLE TALK