Appletalk Chattiness - Fact or
The following articles provide some technical information regarding Appletalk and
the issue of chattiness.
Myth: AppleTalk Is Chatty
By Shelly Brisbin
Folks accuse AppleTalk of being a "chatty" protocol (one that sends too
much data over a network). Because every AppleTalk device (such as a computer or
a printer) constantly polls all the other AppleTalk devices on the network, the protocol
generates a lot of packets. Theoretically, this causes traffic jams on a multiprotocol
AppleTalk is much less chatty than it used to be. Chances are that naysayers are
basing their opinion on old software because they're not up on the latest Mac networking
protocol. Several years ago, Apple introduced AARP (AppleTalk Address Resolution
Protocol), software that cuts down on AppleTalk's chattiness and the packet storms
that can result.
Many people who would smother AppleTalk are comparing it with the wrong protocol
-- NetWare's IPX. It makes more sense to compare it with TCP/IP. Many organizations
that once relied exclusively on IPX for server-based communication with PCs are adding
TCP/IP or moving entirely to it. The move to TCP/IP also includes lots of Macs, which
no longer depend just on AppleTalk for access to e-mail and other network applications.
With so many people using TCP/IP, comparing AppleTalk with IPX is silly. When you
compare AppleTalk with the right protocol, this myth is turned on its head -- TCP/IP
is much chattier than AppleTalk and uses larger data packets too.
Copyright © 1998 Mac Publishing
LLC. All rights reserved.
By Jim Anders
[In response to the claim
that AppleTalk is "too chatty"]
This is a tired, hoary argument from the mid to late 1980s. The general chattiness
issue with AppleTalk was largely solved with AppleTalk Phase 2 - which was implemented
by Apple when George Bush was still President. Issues with the use of AppleTalk traffic
over WAN connections has also been solved for some time.
Of course, today, with the popularity and success of the WWW/Internet, the focus
of attention is TCP/IP, so network managers generally prefer avoiding non-TCP/IP
protocols. However, other than the inconvenience, there is no longer a valid technical
reason to ban AppleTalk protocols, assuming, just as any other protocol, it is setup
and administered correctly. And, with the majority of today's LAN/WAN traffic being
IP, the small, incremental addition of AppleTalk traffic for printing and occasional
FileSharing, just won't make any significant impact.
I wrote about this and other things AppleTalk-related in a book entitled "LiveWired:
A Guide to Networking Macs", published by Hayden Books. It's been out of print
for several years, but there haven't been too many changes to the protocol in that
time, so as far as AppleTalk is concerned, it's still fairly current.
I have a number of spare copies of the book left and if anyone is interested, just
contact the Kaidan office, and if you promise just to peruse the Kaidan website
(QuickTime VR-related products), we will send you a copy of the book for free (Dr.
Troen, I'll reserve a copy until I hear from you one way or the other).
It should also be noted that the individual who convinced me to write the "LiveWired"
book, and who also generously wrote the book's foreword, is none other than Guy Kawasaki!
703 East Pennsylvania Blvd.
Feasterville, PA 19053
Phone: 215 364-1778
Fax: 215 322-4186
Copyright © 1999 Jim
Anders. All rights reserved.
Chatting about AppleTalk
By Mike Basham
The New Straits Times
Mon, Feb 23, 1998
In a previous column about Macintosh networking, I made the statement that AppleTalk
is not really a "chatty" protocol. Several readers sent me electronic mail
about this, since they had been told by network managers that AppleTalk was too chatty
for their network. The original column didn't go into details about what chatty means
or why AppleTalk is falsely accused. These details are a little technical, but I'll
try to explain without making your eyes glaze over.
AppleTalk was designed to make networks easy to use, while transmission control protocol/Internet
protocol (TCP/IP) was designed to support very large networks. This accounts for
why AppleTalk tends to generate more network traffic, which some refer to as chattiness.
For example, if you want to share files with another computer over AppleTalk, all
you have to do is open the Chooser and pick the computer you want from a list. To
do the same thing over IP, you must know either the name or IP address of the computer
you want to access.
Finding an AppleTalk device is kind of like ordering from a restaurant menu; you
see all the options available to you, and you choose the one you want. TCP/IP is
more like a telephone network; before you can call somebody, you need to know their
phone number. If you don't, you can look it up in a book. AppleTalk is much more
user-friendly, but it is not well-suited for very large networks like the Internet.
You wouldn't want to have to pick from a menu of every phone number in the world
whenever you wanted to call your friend. But AppleTalk can work well on networks
of thousands of computers, so long as the network is managed correctly.
AppleTalk is more chatty than IP, but the extra network traffic is necessary in order
to provide convenience. For example, unlike IP, AppleTalk devices don't need to have
a static network address manually assigned, since they can pick a network number
automatically when they start up. Whenever an AppleTalk device is turned on, it broadcasts
10 packets of traffic across the network. These packets are called "AARP"
requests which stands for AppleTalk address resolution protocol. The 10 AARP requests
broadcast a network address that the AppleTalk device would like to use. If no other
device on the network responds to these AARP requests, the address must not be in
use, so the new device uses that address and shuts up. If another device already
has that address, the device tries again with another address.
In most cases, a device can find an unused address immediately, but on poorly-designed
networks, there may not be enough network numbers to go around. If this is the case,
the network will be chatty because new devices will have to work through many addresses
before finding a free one. The solution to this problem is simple: configure the
router so that it gives out more than enough addresses for the network segment it
is responsible for. I won't go into the details of how to do this, but if you're
interested, send me e-mail and I'll explain further.
Another possible cause of network chattiness is the Chooser. When you open the Chooser
and click on AppleShare, your computer must gather information about all the AppleShare
devices on your network segment so it can show you a list. The Chooser updates dynamically
so it can show you when a device has been turned on or off. To do this, it broadcasts
AARP requests to all the devices of a certain kind in a single zone, and they all
respond. In early versions of AppleTalk, this call and response went on as long as
the Chooser was open. Now, it times out after a few minutes if the user leaves the
Chooser open. Still, this can generate lots of traffic if many users open the Chooser
at the same time. The key to managing this kind of traffic is to properly segment
the network so that each logical zone in the Chooser maps directly to a physical
segment of the network. That way, traffic doesn't have to pass through routers every
time a user opens their Chooser. It is also important to keep the number of devices
in a single zone relatively small. This means you should probably segment the network
if you've got more than about 200 AppleTalk devices of the same type in the same
Comments? Send e-mail to Macs@infront.net.