WIN10 WUSP协议结合数据库分析简要

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.

---

1. Self-Update
2. 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.
3. Content Synchronization
4. 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.

1. GetAuthorizationCookie: 验证连接到web server的client端

Client Web Service：

used for synchronizing metadata to the client.

1. GetConfig（p22）： 返回server的验证信息，和report要求
2. GetCookie (p25) : client端obtian或者renew cookie。
3. RegisterComputer（26）： client提供自己的各种信息进行注册
4. SyncUpdates（29）： client同步描述更新内容信息的core metadata （抓取的xml信息不全的原因可能是因为抓取的core fragment of metadata）
5. RefreshCache（35）：client端更新自己的cahce of介于revisionID和GUID之间的映射关系
6. GetExtendedUpdateInfo（36）：client端获取到更详细的更新的metadata数据
7. GetFileLocations（39）：返回更新所需要的文件的urls
8. StartCategoryScan（40）：client端向server请求一份在同步更新时需要的preferred categories清单，category scan允许client在一份大的更新目录里面更新一小部分。
9. SyncPrinterCatalog （42）：用于同步metadata时描述最匹配的printer驱动
10. GetExtendedUpdateInfo2（43）：获取额外的metadata，比如解密钥匙或者加密文件。

---

Reporting Web Service:

client报告被选择的events，这些events包含了更新活动的信息

1. 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需要做的步骤：

1. 首先call SyncUpdates，并且设置InstalledNonLeafUpdateIDs 为空。
2. 然后检查结果返回的NewUpdates元素是不是为空：

• 如果为空，那么software更新就已经完成。
• 如果不为空，检验元素里面update的适用性，并且将适用的update放进一个list里面。

3. 接下来使用上一个步骤的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

1. 首先限制哪些revisions用于部署给client计算机组，结合prerequisite or bundle来限制

2. 继续上一步骤返回的set, 挑选出那些Parameters.InstalledNonLeafUpdateIDs中指定的revision ids

3. 继续限制：

• 如果是software的更新同步，选出updatetype为software的revisions。
• 如果是driver的更新同步，…

4. 接下来server必须生成一个所有CachedRevisions的列表：

• 如果是software的更新同步，选出Parameters.InstalledNonLeafUpdateIDs和Parameters.OtherCachedUpdateIDs的交集
• 如果是driver的更新同步，…

返回的结果： server必须返回SyncUpdatesResponse信息给client

1. SyncUpdatesResponse.NewUpdates:
   返回那些在NeededRevisions中不在CachedRevisions中的revision
   这里面的deployment：如果一个revision本身并没有被部署到具体的客户端，但是有一个被部署了的revision和这个revision有依赖关系，这种情况就要把他的DeploymentAction设置为evaluate。

2. SyncUpdatesResponse.OutOfScopeRevisionIDs：
   返回那些在CachedRevisions中不在NeededRevisions中的revision

3. SyncUpdatesResponse.ChangedUpdates：
   返回同时在两个列表中的revision