Share via

3.2.2 Timers

  • Article

In general, the timers defined in this section run until they expire. After they expire, expiration processing is performed, as defined in section 3.2.5.

Some of these timers have features to randomly delay their expiration, to perform a retry behavior, and to persist across instantiations of the client. These behaviors are defined as follows:

  • Period:

    Each timer described in this section has a period. A running timer MUST expire as soon as possible after both the period and the optional random delay (described as follows) have passed. A timer's period MUST NOT change.

  • Random delay:

    If a timer defines a random delay, then after the period has passed, the timer MUST NOT expire until after the random delay. This is done so that if a server is servicing a large number of clients, the risk is reduced that all the clients will synchronize and flood the server with simultaneous requests. If a running timer has a delay, the delay MUST be randomly calculated after the timer's period has passed. The means by which randomness is determined for the delay is arbitrary, but is bounded in the timer descriptions later in this section.

  • Persistence:

    If a timer supports persistence, and the timer is running when the client is stopped, the timer's remaining period MUST be preserved across client stops and starts. For example, if the client starts a timer with a period of 60 minutes, and subsequently the client stops running for 40 minutes, then the timer period will expire 20 minutes after the client has been restarted. Note that only the period is persisted, not the random delay.

  • Retry Period:

    If a timer supports retries, and a retry is required (as specified in section 3.2.5), it MUST be restarted to a retry delay, rather than stopping or restarting to its normal period. When the timer expires after this retry delay, the expiration steps of section 3.2.5 MUST again be followed. The length of the retry delay is defined in the following individual timer definitions.

Unless otherwise stated in the following timer descriptions, the only feature in the preceding list that timers MUST have is a period. Unless otherwise stated in the remainder of this section, timers MUST NOT restart automatically when they expire:

VolumeInitializationTimer: This timer is used by the client to synchronize its ClientVolumeTable with the server's ServerVolumeTable, and to synchronize its MoveNotificationList with the server's FileTable. This timer MUST have a period of 1 minute. If a retry of this timer is required (as specified in section 3.2.5.1), VolumeInitializationTimer MUST be restarted to a delay randomly selected between 30 minutes and 2 hours, but limited such that the timer does not exceed 6 hours past its original due time. Once this timer reaches 6 hours past its original due time, it MUST be stopped. See section 3.2.5.1 for details on the client actions that are taken when this timer expires.

RefreshTimer: This timer is used by the client to refresh the server state. This timer MUST have a period of 30 days, a random delay of up to 6 hours, persist, and be restarted automatically when it expires. If retries are required (as specified in section 3.2.4.3), this timer MUST be restarted to a delay randomly selected between 1 and 24 hours. See sections 3.2.5.2 for details on the client actions taken when this timer expires.

InfrequentMaintenanceTimer: This timer is used by the client to periodically validate/update VolumeInformation fields. This timer MUST have a period of 30 days, a random delay of up to 6 hours, persist, and be restarted automatically when it expires. See section 3.2.5.4 for details on the client actions taken when this timer expires.

FrequentMaintenanceTimer: This timer is used by the client to periodically validate and/or update VolumeInformation fields. This timer MUST have a period of 1 day, a random delay of up to 2 hours, persist, and be restarted automatically when it expires. See section 3.2.5.3 for details on the client actions taken when this timer expires.

DeleteNotificationTimer: This timer is used by the client to inform the server of files that have been deleted from the client. This timer MUST have a period of 5 minutes. See section 3.2.5.5 for details on the client actions taken when this timer expires.

MoveNotificationTimer: This timer is used by the client to inform the server of files that have been moved from a volume on the client to another volume (possibly to another volume on the client, or possibly to a volume on another computer). This timer MUST have a period of 30 seconds. If a retry is necessary, as specified in section 3.2.4.2, the retry delay MUST be calculated as follows:

  • On the first retry, the delay MUST be 30 seconds.

  • If subsequent retries are necessary, the retry delay MUST be the minimum of: double the previous retry delay; 4 hours; or a delay that would cause the sum of the retry delays to be 24 hours. Once this last condition is reached (that is, 24 hours and 30 seconds after the timer is started), the timer MUST be stopped.