Appletalk Chattiness - Fact or Fiction?

Appletalk Chattiness - Fact or Fiction?

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

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.

AppleTalk Chatty?
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!

Regards,
Jim

Jim Anders
President
Kaidan Incorporated
703 East Pennsylvania Blvd.
Feasterville, PA 19053
Phone: 215 364-1778
Fax: 215 322-4186
E-mail: info@kaidan.com

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

Comments? Send e-mail to Macs@infront.net.