Client-Server Protocol enables client machines to determine available, applicable software updates, and to download those updates for installation. This protocol is a SOAP-based protocol that uses HTTP 1.1 as its transport and includes four distinct phases.
- Self-Update
- Metadata Synchronization: reduce the amount of update metadata that clients need to synchronize, update metadata is divided into fragments.
- The client invokes the SyncUpdates method, which returns to the client a “core” fragment.
- If the client determines that update content is required, it then invokes the GetExtendedUpdateInfo method to obtain additional metadata fragments.
- Content Synchronization
- Reporting: The client reports events to the server that provide information on its update-related activities
2.1 compression encoding and decoding
SimpleAuth Web Service:
restricting availability of updates to groups of clients.
- GetAuthorizationCookie: 验证连接到web server的client端
Client Web Service:
used for synchronizing metadata to the client.
- GetConfig(p22): 返回server的验证信息,和report要求
- GetCookie (p25) : client端obtian或者renew cookie。
- RegisterComputer(26): client提供自己的各种信息进行注册
- SyncUpdates(29): client同步描述更新内容信息的core metadata (抓取的xml信息不全的原因可能是因为抓取的core fragment of metadata)
- RefreshCache(35):client端更新自己的cahce of介于revisionID和GUID之间的映射关系
- GetExtendedUpdateInfo(36):client端获取到更详细的更新的metadata数据
- GetFileLocations(39):返回更新所需要的文件的urls
- StartCategoryScan(40):client端向server请求一份在同步更新时需要的preferred categories清单,category scan允许client在一份大的更新目录里面更新一小部分。
- SyncPrinterCatalog (42):用于同步metadata时描述最匹配的printer驱动
- GetExtendedUpdateInfo2(43):获取额外的metadata,比如解密钥匙或者加密文件。
Reporting Web Service:
client报告被选择的events,这些events包含了更新活动的信息
- ReportEventBatch(46): 报告与software更新相关的时间出现情况
Cookie: server用来储存client端的授权,认证,还有协议状态信息的
协议细节:
server生成一个加密cookie用于封装server对于每个client的协议状态,然后server要求每个client保留这个cookie。client每次对server调用方法的时候,都要出示这个cookie, 然后server会在与client进行交互的过程中将这个cookie进行更新。
Prerequisite Table: An update’s prerequisites are specified in CNF,ex: (U6 OR U8) AND (U2) AND (U5 OR U3)
client不会把一个revision当成一个必要的revision,除非他的prerequiste条件满足了,那就是至少有一个满足每个CNF的disjunctive子句的update已经安装。
Bundle Table: 一个表述updates之间关系的集合,bundled updates are specified in CNF,ex: (R6 OR R8) AND (R2) AND (R5 OR R3)
self update:
在协议的最开始,client必须检查自己需不需要self-update, 如果server不对client展示自己的self-update内容目录,那么两者之间的交互就无法进行。 client使用http的get请求从self-update内容目录里面获取文件。
SyncUpdates(73):
被调用去实现software和driver的metadata的同步,
client需要做的步骤:
- 首先call SyncUpdates,并且设置InstalledNonLeafUpdateIDs 为空。
- 然后检查结果返回的NewUpdates元素是不是为空:
- 如果为空,那么software更新就已经完成。
- 如果不为空,检验元素里面update的适用性,并且将适用的update放进一个list里面。
- 接下来使用上一个步骤的list:
- 把IsLeaf标记为false的update ids放进InstalledNonLeafUpdateIDs sent in the last call to SyncUpdates
- 把剩下的driver类型的update ids放进 CachedDriverIDs
- list里面剩下的update ids放进OtherCachedUpdateIDs
然后再调用一次SyncUpdates,重复以上步骤
server需要做的步骤:目的是计算出NeededRevisions列表给client
-
首先限制哪些revisions用于部署给client计算机组,结合prerequisite or bundle来限制
-
继续上一步骤返回的set, 挑选出那些Parameters.InstalledNonLeafUpdateIDs中指定的revision ids
-
继续限制:
- 如果是software的更新同步,选出updatetype为software的revisions。
- 如果是driver的更新同步,…
- 接下来server必须生成一个所有CachedRevisions的列表:
- 如果是software的更新同步,选出Parameters.InstalledNonLeafUpdateIDs和Parameters.OtherCachedUpdateIDs的交集
- 如果是driver的更新同步,…
返回的结果: server必须返回SyncUpdatesResponse信息给client
-
SyncUpdatesResponse.NewUpdates:
返回那些在NeededRevisions中不在CachedRevisions中的revision
这里面的deployment:如果一个revision本身并没有被部署到具体的客户端,但是有一个被部署了的revision和这个revision有依赖关系,这种情况就要把他的DeploymentAction设置为evaluate。 -
SyncUpdatesResponse.OutOfScopeRevisionIDs:
返回那些在CachedRevisions中不在NeededRevisions中的revision -
SyncUpdatesResponse.ChangedUpdates:
返回同时在两个列表中的revision