---

AFP Login

To make use of any resource managed by a file server, the AFP client must first log in to the server. This section provides an overview of the AFP login process.

After a user selects an AFP server to log in to, the AFP client sends the FPGetSrvrInfo command to request information about that server. The server returns information that includes

• the AFP versions the server supports

• the user authentication methods (UAMs) the server supports

• the server’s machine type

• the server’s name

• the server’s network address

• the server’s signature

• whether the server supports optional functionality, such as reconnect, Open Directory, FPCopyFile, FPChangePassword, saving passwords, and server notifications

During the AFP login process, the AFP client tells the server which AFP version the client will use to establish the connection and which UAM it will use to authenticate the user.

Each AFP version is uniquely described by a string of up to 16 characters called the AFP version string. The AFP version strings for the AFP versions supported by AFP 3.x are listed in Table 1-12.

The UAMs supported by AFP 3.x and their corresponding strings are listed in Table 1-13.

The prospective AFP client initiates the login process by sending an FPLogin or an FPLoginExt command to the server. Both commands include the AFP version string and the UAM string that the client has selected. Depending on the selected UAM method, the FPLogin or FPLoginExt command may include user login information (such as a user name or password), or a subsequent FPLoginCont command may include such information. The sending of additional FPLoginCont commands may be required to complete user authentication, as described in the next section, “File Server Security.”

If the UAM succeeds, an AFP session between the AFP client and the server begins.

As mentioned earlier, in addition to the AFP and UAM versions that the server supports, the FPGetSrvrInfo command returns a Flags parameter whose bits provide additional information about the server that is useful to an AFP client. The bits of the Flags parameter are listed in Table 1-14.

In this section:

Reconnecting Sessions
Recovering From a System Crash
Disconnect Timers

Reconnecting Sessions

If an AFP session is disconnected due, for example, a network outage, but the AFP client still has the required information, the AFP client can reconnect the session.

Clients that use the Reconnect UAM, described in “Reconnect,” follow these steps to reconnect:

1. Log in successfully by calling FPLoginExt using a UAM that provides a session key.

2. Call FPGetSessionToken to get a token, specifying the Type parameters as kRecon1Login (5).

3. Periodically call FPGetSessionToken with the Type parameter set to kReconn1Refresh (7) to refresh the token before it expires.

4. If a disconnect occurs, call FPLoginExt to log in again, specifying the Reconnect UAM as the UAM, and passing the current token obtained by calling FPGetSessionToken in step 2 or 3. The reconnect token contains all of the user name and password information required for the server to authenticate the client, so logging in again does not require the client to repeat the authentication steps that took place in step 1.

5. If the login in step 4 completes successfully, call FPDisconnectOldSession and pass the token obtained in step 2. If the server can find the previous session identified by the token, it will transfer all the previous session’s open files and locked resources to the new session and return a result code of kFPNoErr.

Clients that don’t use the Reconnect UAM follow these steps to reconnect:

1. Log in successfully by calling FPLogin or FPLoginExt.

2. Call FPGetSessionToken to get a token.

3. If a disconnect occurs, log in again using the same UAM, user name and password that were used in step 1.

4. Call FPDisconnectOldSession and pass the token obtained in step 2. If the server can find the previous session identified by the token, it will transfer all the previous session’s open files and locked resources to the new session and return a result code of kFPNoErr.

In either case, if the reconnect fails for any reason, the client must start over by logging in again as in step 1. The client should call FPDisconnectOldSession and send the current token to tell the server that it can free resources that were locked up by the earlier session.

If the server returns a result code other than kFPNoErr, the AFP client can attempt to reopen its files. If the files were previously opened without Deny Modes and the AFP client did not apply byte range locks, the client should be able to reopen those files. In this case, reconnect is also deemed successful. If the reconnect is not successful, an AFP client can take the steps described in the next section, “Recovering From a System Crash.”

Recovering From a System Crash

If an AFP session is disconnected and the client reconnect information is lost due to a local system crash, the AFP client will not be able to reconnect the session. If the server allows reconnect, any files that were left open on the remote server when the local system crashed will be saved but will not be available for opening until the reconnect timeout expires. This also applies to the case where a sleeping AFP client fails to wake up or crashes and the server is saving the information until the sleep timeout expires.

To tell the server to close files left open by an old session and disconnect that session, an AFP client that supports AFP 3.1 and later can create and save a unique client-defined identifier and use the FPGetSessionToken command to send it the server. The client must do this before the local system crashes, for example, as part of its login sequence. When it receives the identifier, the server associates the identifier with the current session.

Later, if the local system crashes and is restarted, the AFP client can log in and send the FPGetSessionToken command again, this time telling the server to look for a session having the specified identifier. If the server finds such a session, it closes the files that are associated with it, frees any other associated resources, and disconnects the old session.

Disconnect Timers

In previous versions of AFP, there was only one timer for determining whether a disconnect had occurred. With 10.2.x, there are two timers for determining disconnections:

• Active timer, which is set to 60 seconds by default

• Idle timer, which is set to 120 seconds by default

If the client has an outstanding request to the server and has not received any data (including tickles) from the server, the client waits until the active timer expires before assuming that a disconnect has occurred.

If the client has no outstanding requests to the server, the client waits until the idle timer expires before assuming that a disconnect has occurred.

Special considerations arise when the system is awakening from sleep:

• If the system is on a LAN, the active timer is set to (activeTimer / 4).

• If the system is on a WAN, the active timer is set to (activeTimer / 2).

If the client is connected to an AFP 2.x server, the Active time and the Idle timer are both set to 120 seconds.

In all situations, after a disconnect, if the server supports reconnect, reconnect is started.

---