Mac OS X,  Mac OS X Server,  Mass Deployment

Reducing Inactive AFP Traffic

In Windows, when you have connected to a share, as with a mapped drive letter, that share shows as Active. At some point, if the client cannot communicate with the open session to a SMB/CIFS server the drive will appear to the Windows client as OFFLINE. AFP does something similar, but the result is a constant communication with the AFP server (at least constant as it is perceived from the Finder). While this communication may appear to be constant it is actually verified by the server every 30 seconds, and the AFP client software, if no poll is sent from the server, the client will also attempt to reach out to the server to verify that the connection is available. This process is known as tickling.

AFP uses the tickle to verify that clients are still connected to a server. However, this communication causes a minimal amount of network congestion, which some environments want to keep to a minimum. This is similar to the concept of disabling protocols in a network stack that are not being used. These protocols aren’t likely to cause issues on one machine, but when employed by thousands of host they can effectively cause a Denial of Service on the server.

Provided that you use AFP, you’re just not going to want to disable the tickle. By default it happens every 30 seconds with no user intervention (other than connecting to a share point and having a session greater than 30 seconds). While you’re not going to want to disable it, you can reduce the number of seconds between updates, to reduce traffic. For example, the following command will reduce the time between tickles to 60 seconds:

serveradmin settings afp:tickleTime = 60

In order to set the tickleTime value back to 30 seconds, you would simply issue the following command:

serveradmin settings afp:tickleTime = 30

Setting a tickleTime isn’t for everyone. In fact, it’s pretty rare when this kind of step is needed; but if your Mac servers are causing a lot of collisions on the network and using packet analysis you determine the traffic to be due to DSI/AFP packets, then it is a fine time to test out using tickleTime as a potential solution. If it doesn’t resolve your issue then you can always move back to 30 seconds. While it can cause beach balls to last a fair amount of time in the event that a server connection is lost, it can also be used to reduce traffic.

Finally, the concept of a constant communication channel for file services may be foreign to even a seasoned Windows admin. However, this is just a reality of playing in the Apple sandbox.