39625: Acronis Files Connect: AFP Reconnect/Timeout definitions and behavior

use Google Translate

Last update: 11-07-2017


This article provides information provided by Apple, Inc. on the definitions of various types of AFP Reconnects and Timeouts as well as the differences between how Mac OS X Tiger and Mac OS X Leopard handle them.


AFP Reconnect and Timeout Definitions


  • Primary Reconnect
    - Client has lost contact with the server, but the server has saved all the session and state information for that client. A successful Primary Reconnect will result in NO data loss. All files, state, etc are restored exactly to the way they were before losing contact with the server. Primary reconnect is always attempted first and if that fails, then a Secondary Reconnect is attempted. The expectation is that Primary Reconnect should only occur rarely (only if some other problem is causing the client to lose its connection).

  1. Secondary Reconnect
  2. - Client has lost contact with the server and the server does not have the saved session and state information. Any open files that had deny modes or byte range locks are now closed and unsaved data may be lost (although most applications will let you save the current data to a new file). Applications that were currently using those files will normally display an error stating that the file is no longer accessible. You can reopen the file using that same application. Any open files that did not use deny modes or byte range locks are automatically reopened. The expectation is that Secondary Reconnect should be extremely rare since it indicates that the server has crashed.

  3. Active Timeout
  4. - Client has an outstanding request to the server and has not yet received any data back from the server. The client will only wait for the Active Timeout to expire (default is 60 seconds) before assuming the server is disconnected. If reconnect is supported on this server, then reconnect will be started. Note: For older AFP 2.x servers the Active Timeout is set to 120 seconds due to too many premature disconnects. The 120 seconds is the original Time Out defined in the AFP 2.x protocol specifications.


  • Idle Timeout
    - Client has no outstanding requests to the server, and no packets have been received from the server when the Idle Timeout expires (default is 120 seconds), then the server is disconnected. In the AFP protocol, both the client and the server are required to send a Session Maintenance (Tickle) packet every 30 seconds.

  1. Fast Timeout
  2. - If the system is coming out of sleep, then there is a high chance that the servers are not reachable anymore. Thus, the Fast Timeout is used and it is set to be (Active Timeout / 4) if the server is connected to via a LAN or (Active Timeout / 2) if on a WAN. The LAN or WAN determination is done by checking the round trip time it takes for a single packet early in the connection setup. The Fast Timeout is just a shorter variation of the Active Timeout and is used in the same way.

Disconnect / Reconnect Behavior in Tiger (10.4)

In Tiger, it did not matter if you pulled the Ethernet cable from the Client or the Server CPU. You would still have to wait for the Active Timeout or the Idle Timeout to expire before reconnect was started. Also in Tiger, all AFP volumes were "hard mounted" which meant that all the file system calls were blocked until Reconnect worked or failed. Since Reconnect continued to retry for about 10 minutes, the mounted AFP file system would block all calls for that entire 10 minutes and this led to the "Spinning Beach Ball" affect where one by one, all your applications would start to Beach Ball. Obviously this was not ideal for mobility cases such as laptops that are constantly getting disconnected from their networks. Even worse was the fact that the "Server Not Responding" dialog would not always get displayed because sometimes it too got stuck behind the blocked file system calls.

New In Leopard (10.5) are "Soft Mounts" and "No Route to Host" Detection

"No Route to Host" Detection is the ability of the TCP stack to report when a remote TCP address is no longer reachable. Instead of having to wait for TCP retransmit to time out (or the AFP Active or Idle timeouts to expire), we can now get an immediate error when the remote TCP address is no longer reachable. So, if you unplug the Ethernet cable from the client side, the client will immediately notice it and the AFP Reconnect will start immediately. Another example is if you use VPN and have a server mounted through VPN, but VPN now disconnects. Again, the TCP stack will return an error and the AFP Client will immediately start into reconnect. Of course if you unplug the Ethernet on the Server side, then the AFP Client will not go into reconnect until the Active or Idle timeouts expire. Note: several network related products from Apple are now using the "No Route toHost" to better improve our User's mobility experiences.

"Soft Mounts" is the same idea as the NFS "soft mounts". After a short amount of time, if the reconnect has not succeeded or failed, then the mounted AFP volume will start returning ETIMEDOUT errors instead of blocking the file system calls. About 10 seconds after reconnect starts, ETIMEDOUT errors will begin to be returned on all file system calls. If reconnect works, then errors will stop being returned. If reconnect fails, then Apple forces the volume to be un-mounted as it is in Tiger. By using "Soft Mounts" having all the User's applications slowly start "beach balling" until reconnect works or fails (which can take as long as 10 minutes) is avoided. Also, by return the soft mount errors, the "Server Not Responding" dialogs which let the User decide if they want to force un-mount the volumes earlier are always displayed. Note: AFP Home directories are "hard mounted" by default.