Omaha 客户端库

更新时间：2024-08

这是Omaha协议协议客户端端的平台和产品无关实现，用于向设备或应用程序指示可用的更新。

概述

设计目标

• 功能： 想要使用Omaha协议进行更新管理的设备所需的所有协议功能。
• 大规模正确操作： 在大规模使用时，必须实现一些行为以确保全局同步不会发生，并且如果某些外部操作导致大量客户端同步，它们需要快速解同步。
• 可测试性： 通过单元测试全面覆盖正常和异常用例。
• 模块化： 通过Rust Traits将模块清晰地分离以提高可测试性和可移植性。
• 关注点分离： 协议的状态机及其管理策略完全分离以提高可测试性。

高级设计

这是对库的主要概念组件的概述

Omaha客户端库提供了以下主要部分

• 一个 App 结构体，用于定义需要更新检查的东西。
• 协议的 状态机。

以及定义（通过Traits）供库的使用者实现以下内容

• 当 StateMachine 需要做出决策时使用的 策略。
• 用于收集系统数据以便于Policy对StateMachine做出决策的PolicyEngine。
• 用于执行安装/更新的Installer。
• 用于向库用户提供状态和进度的Observer。

这种划分允许二进制或更新检查服务的实现者专注于Policy、Installer等平台和产品特定的方面。

StateMachine与其他组件之间的关系如下：

状态机与策略

StateMachine向Policy提出各种问题，例如“是否是检查更新的时间？”或“现在是否可以安装更新？”

Policy实现本身是无状态的、自少的和幂等的。它必须不跟踪任何自己的状态，并且具有相同参数的重复问题必须得到相同的答案。

策略引擎与策略本身

Policy回答问题，但为了这样做，它通常需要来自系统的数据（例如当前时间）。Policy无法自行收集任何数据。它用于做出决策的所有信息都来自PolicyEngine，它是StateMachine和Policy之间的中介。

PolicyEngine接受从StateMachine传递给它的参数，添加它需要收集的数据（称为PolicyData），或它一直在跟踪的状态，并调用Policy做出决策，该决策被返回到StateMachine。

虽然Policy是无状态的，但PolicyEngine几乎肯定不是，但它仅执行收集和持有可以传递给Policy通过PolicyData的状态。

状态机与安装程序

状态机指示安装程序执行更新，并随着更新的下载和应用的进行，安装程序向状态机提供进度和状态通知。完成后，状态机可能向安装程序发出重新启动的信号。

状态机与安装程序（安装计划）状态机获取Omaha响应，并从协议的角度对其进行解析/验证后，将其传递给安装程序以创建安装计划以执行响应中包含的更新。

状态机

StateMachine有两个部分

1. 一个外循环，该循环启动定期的更新检查。
2. 一个内部流程，该流程执行对Omaha的必要请求，以正确检查和提供对更新的反馈。

流程如下

完全同步的任务（且在StateMachine内部）用蓝色表示，需要异步操作的任务用红色表示。错误路径转换用红色表示，成功路径转换用绿色表示，错误和成功情况都采取的转换用黑色表示。

存在许多“无关紧要”的任务，特别是关于向Omaha报告事件和错误。这些是“尽力而为”的措施，会等待响应，但如果没有响应或响应格式不正确，则状态机不会采取与成功情况不同的行动，不会重试，并继续执行下一个任务。

左侧的错误情况涉及发出本地状态消息，以及结束协议，而不需要通知Omaha。这些是当前无法执行更新检查，或更新检查本身失败（在传输层），或者响应表示没有要执行更新的情况。

右侧的错误情况需要报告给Omaha。它们按顺序如下：来自Omaha的格式错误的响应，基于当前策略数据或策略决策无法执行响应和安装计划，或在执行更新过程中出现的错误。

测试和开发

该存储库附带一个“hello world”示例，用于展示如何在程序中使用库。有关示例的更多详细信息，请参阅其自己的README.md。

该存储库还包含Omaha协议的模拟服务器实现，可用于对包括http请求/响应方案的程序进行端到端测试。模拟服务器在其自己的README.md中进行了描述，包括如何针对模拟服务器运行hello world示例的标准示例。