Share via

3.2.5 Message Processing Events and Sequencing Rules

  • Article

The "metadata sync" portion of this protocol conforms to the figure as specified in section 3.1.5.

Self-update, authorization, and metadata sync MUST be performed in the sequence shown in the figure as specified in section 3.1.5, although, as an optimization, certain steps MAY be omitted under the conditions specified below. In particular, the client MAY perform the following optimizations.

  • The result of GetConfig (section 3.1.5.2) SHOULD be cached on the client. Subsequent synchronizations MAY omit this method invocation unless the server throws a ConfigChanged ErrorCode.

  • The cookie returned from GetCookie (section 3.1.5.4) or SyncUpdates (section 3.1.5.7) SHOULD be cached on the client. Subsequent synchronizations SHOULD omit the call to GetAuthorizationCookie (section 3.1.5.3) and GetCookie unless the server throws a CookieExpired ErrorCode, or unless the client determines that the clear-text copy of the cookie expiration time shows the cookie to be expired.

  • The registration information sent to the server SHOULD be cached on the client.

    Subsequent synchronizations SHOULD omit the call to RegisterComputer (section 3.1.5.5), unless the registration information has changed on the client, or unless the server throws a RegistrationRequired exception.

In addition to the standard sync path specified above, the client MUST also perform special recovery steps when the server returns certain application-level faults, as specified in section 2.2.2.4.

In addition to metadata sync, the client also initiates content download for applicable updates, installation of those updates after the download completes, and generation of events to report to the server. It is implementation-specific as to when these are performed. Content is downloaded using HTTP (as specified in [RFC2616]. Optionally, content can be downloaded using HTTP in a restartable (progressive) manner using the BITS Upload Protocol [MC-BUP].