3.2.5 Message Processing Events and Sequencing Rules
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 cookie returned from GetCookie (section 188.8.131.52) or SyncUpdates (section 184.108.40.206) SHOULD be cached on the client. Subsequent synchronizations SHOULD omit the call to GetAuthorizationCookie (section 220.127.116.11) 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 18.104.22.168), 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 22.214.171.124.
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 should be performed. Content is downloaded using HTTP (as specified in [RFC2616]. Optionally, content can be downloaded using HTTP in a restartable (progressive) manner using [MC-BUP].