How does Acronis Files Connect allow clients to reconnect? What effect does Kerberos authentication have on reconnect behavior?
Acronis Files Connect supports the ability for Macintosh clients to reconnect to the server after a loss of connection. Connections can be lost due to network outages, server failures or client failures. Reconnect behavior allows clients to reestablish a connection to Acronis Files Connect without any user interaction. In most cases, the client is able to reestablish the connection without the loss of any unsaved data. This article will describe different types of reconnect behavior as well as the factors that can impact the ability of a client to successfully reconnect to the server.
In general there are three general reasons for a reconnect: minor problems such as a network outage, the Acronis Files Connect service is restarted, or the Mac client crashes. As one might expect if either the server or client is restarted, one of them will not be aware that the AFP session existed. To solve this problem there are a number different kinds of reconnect that can be negotiated between the client and the server.
When a Macintosh client initially connects to an Acronis Files Connect server, the server sends the client an encrypted piece of data known as a reconnect token. This token can be used if and when reconnect is needed as a way to facilitate the reconnect process without user interaction. When a Macintosh detects a loss of connection to an Acronis Files Connect server, it attempts to contact the server in order to reconnect. If the server can be contacted (say, because the network outage is over), the client sends the reconnect token back to the server. If the token is deemed valid, the Acronis Files Connect server transfers all the session and state information for that client from the old "dead" session to this newly established session. This state includes the set of volumes and files that the client had previously opened. This type of reconnect (known as Primary Reconnect) results in no data loss, and applications running on the client machine should be unaware that the reconnect even took place.
Under certain circumstances, the old "dead" session will not be present when the client reconnects to the server. This can occur if the client takes more than five minutes to reconnect, if the server or the Acronis Files Connect service has crashed, or if (on a cluster) the service has failed over to another cluster node. If the old session is unavailable for any of these reasons, Secondary Reconnect occurs. The client will automatically reopen any previously open volumes and files. However, because the files had to be reopened, unsaved data may be lost.
Clients initially connecting to Acronis Files Connect using Kerberos authentication can successfully reconnect using Primary Reconnect - that is, as long as their old session is still present. However, Secondary Reconnect is not supported for these clients, which means that clients will to reconnect to the server after a cluster failover, or a server/service crash. These clients will have to manually connect to the server in order to reestablish their connection. Clients authenticating to the server using DHX authentication (using a username and password) can reconnect with both the Primary and Secondary Reconnect mechanisms.
If the client machine fails (crashes, loses power, etc.), the old "dead" session will remain on the Acronis Files Connect server for five minutes. If the client machine restarts and the user manually connects to the server during that five minute period, the server will automatically close the old session to free up any locked files. The server cannot transfer session state to this new session because the new session is unaware of any volumes and files opened by the old session due to the reboot. If more than five minutes pass without a reconnect attempt, the old session will automatically be removed, and its associated files closed.