Share via

3.2.2 Timers

  • Article

Web Services Management Protocol Extensions for Windows Vista extends the behavior of the WS-Management Protocol, as specified in [DMTF-DSP0226], by defining one timer.

Client Operation Timeout timer: A timer used to trigger cleanup of any state associated with an outstanding operation Request if a corresponding Response message is not received from the server in a timely manner. When any WSDL Request is sent, the client instantiates a new timer and starts it. When a Response is received, the client halts the timer that is associated with the initial Request. For more details see section 3.2.5. The timer interval MUST be set to the number of milliseconds given by the sum of the wsman:OperationTimeout header value (as specified in section 3.2.4.1.2) and the NetworkDelayms configuration setting (as specified in section 2.2.4.6). The minimum value MUST be 500. The maximum value MUST be 4294967295. The default value MUST be 65000.

Connection KeepAlive Timer: A timer used to trigger sending of a KeepAlive message. The timer is started after sending any message to the server and is restarted when any message other than a KeepAlive message is sent to the server. The timer interval is implementation-specific but SHOULD be less than the client's HTTP connection time-out value.<130>

Request Retry Timer: A timer used by enhanced CIM operations to resend the request after the primary HTTP connection is interrupted. This timer is initially stopped. When started, the timer's retry interval SHOULD be computed using the following algorithm:

  1. The current time is taken as CurrentTime. If CurrentTime is greater than (RetryStartTime + 180 seconds), further retries are not performed and the Request Retry Timer is not started.

  2. Otherwise, a random number is chosen between 0 and an upper bound of (15 * (2 ^ (CurrentRetryAttemptCount - 1))) as the value for RetryWaitSeed. This value is in seconds. This formula doubles the upper bound on each retry attempt, such that the first interval is between 0 and 15 seconds, the second between 0 and 30 seconds, then 0 and 60 seconds, and so on.

  3. If (CurrentTime + RetryWaitSeed) is greater than (RetryStartTime + 180 seconds), RetryWaitSeed is reduced to (RetryStartTime + 180 – CurrentTime), also measured in seconds.

  4. The algorithm forces retry attempts to take place at certain ForcedRetryPoints, which are at 55 seconds, 115 seconds, and 175 seconds. If the RetryWaitSeed selected in the previous steps yields a time that is beyond the nearest ForcedRetryPoint in the future, reduce RetryWaitSeed to that value. For example, if RetryWaitSeed is 122 seconds in the future, reduce it to 115 seconds.

  5. If the previous steps yield a RetryWaitSeed value of 0 seconds, RetryWaitSeed is adjusted to a value of 10 milliseconds.

  6. The final value of RetryWaitSeed is taken as the retry request timer’s retry interval.