RFC-0032：高效信封

RFC-0032：高效信封
状态已拒绝
领域
  • FIDL
说明

此 FTP 为信封提出了一种更紧凑的编码方案。
作者
提交日期（年-月-日）2019-02-06
审核日期（年-月-日）2019-02-21

修改此 RFC

修改 RFC 元数据

“把信封变成明信片”

遭拒原因

2019 年 2 月 21 日，此 RFC 最初被接受。FIDL 团队 在 2019 年的大部分时间里稳定电线格式，最终实现全员演示 （涵盖第三季度和第四季度）。迁移已于 12 月 1 日完成， 2019 年。

稳定工作涉及多项变化：

然而，随着工作的展开，首截止日期已临近， FIDL 团队决定开始实施高效的信封变革， 希望将这项工作推到 2020 年。与其他部分更改 因此，高效的信封只是内存中的大小 但节省金额很少，特别是与 FIDL 传输格式（例如表的密集格式）。 推迟是一项用于降低项目风险的计算方法，通过缩小范围， 提高了按时完成所有工作的几率。FIDL 团队的 工作时间表。

现在，延期已接近 18 个月，高效信封 早忘了。2020 年的大量绩效表明， 不会产生实质性影响。

是时候直面真相了，这是不会的。已遭拒。

与其他 RFC 的关系

2021 年 6 月，我们重新审视了这一主题，并采用 定位基准。今天的培训到此结束 RFC-0113 提议重新引入此项变更， 已被接受。

摘要

此 FTP 为信封1提出了更紧凑的编码方案。

设计初衷

信封是可扩展、可进化的数据结构的基础 （表和可扩展联合）。 一种更紧凑、更高效的信封电线格式 可扩展结构，用于性能优越的 和线缆尺寸都很重要

设计

建议的信包格式为：

图：64 位小端序字、MSB 32 位大小、16 位 handle_count， 16 位预留

与现有的信封格式相比：

  • 大小字段保持不变（32 位）。
    • 大小包括可能以递归方式返回的任何子对象的大小 编码。
    • 例如，vector<string> 的尺寸包括 外向量的内部字符串子对象。
    • 这与当前信封的现有行为一致 尺寸字段。
  • 16 位已预留。
    • 解码器必须验证预留位是否为零。
    • 如果以后想要使用保留位， 线上传输格式。
      • 应更全面地考虑 FIDL 的预留位， 以确保行为在各种规范之间保持一致。
      • 特别是，在 FIDL 中，解码器在 忽略所有位：线路上的所有位均已定义和指定。
      • 这一决定是最简单的一个 - 需要采用线缆格式 而不是启用向前兼容性，以保持 在预留位政策出台之前，一切都变得简单了。
  • handle_count 为 16 位，而不是 32 位。
    • 目前无法将 >64 个手柄在锆石上 渠道；我们认为 16 位有足够的提升空间来满足未来的需求。
    • handle_count 包含所有递归子对象的句柄计数。
  • 存在/缺失字段被丢弃。
    • 在线状态由一个非零值（大小或 handle_count 字段。
    • 缺失用大小和都属于“0”的句柄。
  • 大小为 UINT32_MAX 且句柄计数为 0 的特殊情况是： 表示存在但大小为零的信封内容。
    • 如果零大小的空结构体，则预留此预留以供将来使用。 成为现实2，并且不会造成任何效果提升， 解码器的复杂性或复杂性惩罚。 现在我们想提及这一点， 以便将来可能实现 不会破坏传输格式。
    • 我们可以改为窃取其中一个预留位。 我们没有强烈的意见；只要还有 区分“当前大小，但大小为零”的方法信封发件人 FIDL_ALLOC_ABSENT，没关系。 很高兴能达成共识。

解码器可以使用指向信封数据的指针覆盖信封。 假设他们知道信封内容的静态类型（架构）。 请参阅未知数据部分，获取有关操作方法的建议 来处理信封。

编码/解码形式的 C/C++ 结构体

信封的编码形式可以由编码 或解码形式。

typedef union {
  struct {
    uint32_t size;
    uint16_t handle_count;
    uint16_t reserved;
  } encoded;
  void* data;
} fidl_envelope_t;

static_assert(sizeof(fidl_envelope_t) == sizeof(void*));

未知数据

接收器 - 验证器和解码器 - 可能不知道 它们用于可进化的数据结构中。 如果接收方不知道类型，则可以对信包进行最低限度的解析 已跳过。

  • 信封的大小决定了要跳过的外行数据量。
  • 如果信封的句柄计数为非零，验证程序必须处理 指定数量的句柄。
    • 默认处理行为必须为关闭所有手柄。
  • 解码器可以使用指向 信封的内容（如果要就地解码）。
    • 如果解码器确实用指针覆盖了信封，则会丢失 尺寸和处理信封中的计数信息。 绑定可以为解码器提供一种机制来保存 在覆盖信封之前处理计数信息；这个 对于此类机制的工作原理，FTP 并没有发表意见。

实施策略

此 FTP 是一种重大的传输格式更改。

两个 FIDL 对等方都需要了解新的信封格式，并且 将这种理解传达给同事，以供双方使用 新格式。 因此，这通常被视为一种困难的过渡。 由于此 FTP 没有添加任何新功能 作者建议将此更改归入 其他传输格式更改（例如提议的序数大小更改）。

尽管如此，还是可以进行软过渡。 下面介绍了两种方法：

  1. 事务性消息中包含 uint32 预留/标志字段 标头。 我们可以为发起对等端预留 1 位，以表明它 能够理解新的传输格式，以及分阶段的软转换： <ph type="x-smartling-placeholder">
      </ph>
    1. 确保所有客户和服务器可以识别新的线上传输格式 我们继续使用旧有的传输格式。
    2. 通过让对等设备在 事务消息标头。 如果双方都设置了位，则双方都可以切换到新的位 线上传输格式。
    3. 当软过渡经过所有层之后， Fuchsia 可以使用新的数据线格式。 我们可以取消在事务邮件标头中设置位。
    4. 删除旧传输格式的代码，并取消保留 事务消息标头位。
  2. 我们可以使用 “[WireFormat=EnvelopeV2]”属性（或类似属性），指示 message/interface 应使用新的传输格式。
    1. 使用 WireFormat 属性装饰接口似乎 最好能与传输格式更改保持一致， 在结构体上实施 WireFormat 更改，因为结构体可以是 并且绑定需要额外的逻辑来 确定使用结构体的上下文。
    2. 我们建议让接口 [WireFormat] 属性影响 仅采用接口方法参数的传输格式， 以递归方式影响参数的结构。
    3. 这样可以实现部分迁移并选择采用新的有线格式，并且 让团队按照自己的节奏前进
    4. 一旦所有结构体和接口都具有 [WireFormat] 属性，我们 可以丢弃旧的传输格式，假设所有结构体和接口使用 新的线上格式，并忽略该属性。

这两种软过渡方法都需要大量开发时间， 测试时间和出错空间 通过实现代码来正确执行任一方法，按计划执行， 而成功跟进并删除旧代码将是一项艰巨的工作。

我们可能会使用代码来处理旧版和新的线上传输格式 否则，就无法逐步 实现对新传输格式的支持时使用的 CL。 鉴于会有处理这两种传输格式的代码，我们建议 使用上述软过渡之一进行原型设计，以确定软过渡是否可行 过渡方法。 此类原型设计工作还可能会引出通用的着陆策略 未来会发生重大线路格式变更，这些变更或许很有价值。 如果没有，c'est la vie；非常困难

对于软过渡或硬过渡，如果 FIDL 信息手动传送，也需要升级到新线路 格式。

向后兼容性

提议的传输格式更改应与 API（源）兼容。 需要手动更新任何 FIDL 代码以处理新电线 格式。

传输格式更改与 ABI 不兼容。 可以通过概述的策略实现 ABI 兼容性 在实现策略部分。

性能

这个 FTP 使信封的大小变小了 认为这是从整体上而言显著的净收益。 然而，如果由于其自身的偏见， 但使用量的增加可能会抵消这方面的影响， 与使用后者相比， 非可扩展数据结构。

工效学设计

  • 利用更高效的可扩展数据结构， 在效率至关重要的更多情境下，用户需担忧 并享受可扩展性的优势， 以前，他们需要使用非可扩展结构。
  • 我们甚至建议将表用于 为实现高性能，应保留 FIDL 数据结构和结构体 上下文。
    • 可扩展联合 (RFC-0061) 已尝试 移除静态联合体。

文档

  • 线上传输格式文档需要更新。
  • 更新文档时， 一流概念：这有助于提高认知 分块。 可扩展数据结构。
  • 我们应更新 FIDL 样式指南，以便针对 都应该使用可扩展类型

安全

此 FTP 应该不会对安全造成重大影响。

这个 FTP 有一个微小的安全优势 与旧格式中的大小和指针重复。 以前，接收的信封可能具有非零大小/标识名，并且 FIDL_ALLOC_ABSENT 或零大小/句柄和 FIDL_ALLOC_PRESENT。 这需要执行额外的验证检查，您将不再需要此类检查。

测试

  • 由于这个 FTP 正在改变信封的传输格式 现有的 FIDL 测试套件，尤其是兼容性测试 ）能够充分测试使用信封的所有场景。
  • 如果我们同意采用软过渡的方式传输有线格式更改（请参阅 实现策略部分），我们将添加 以便对等方进行协商，并可能改用新的有线格式。

缺点、替代方案和未知问题

如果我们认为这种传输方式能够提高 不会物有所值。

设计决策

虽然这个 FTP 可以提供建议，但我们也在积极寻求建议， 达成共识：

  • 我们要考虑软转换还是硬转换？请参阅 实施策略部分（面向专业人士和缺点
  • 我们建议针对大小使用 32 位，为句柄使用 16 位，并预留 16 位。
    • 32 位的大小合理吗？
    • 为句柄使用 16 位是否合理？
  • rfc-0026（此提案的派生来源），建议采用内嵌数据
    • 我们决定撤消对此提案的内联操作 实现复杂性显著增加，并且仅提供边际收益 除非有大量字段可内联。
    • 我们还有很多工作要做，以便进一步考虑可选性 例如将可选字段分组为单个 可选结构体。 此类工作可能会取代内联可能带来的任何优势。

先验技术和参考资料

此 FTP 是 rfc-0026 的精简版本，自 整个 FTP 方面的共识不足。

提案。 内嵌、随时随地处理信封，以及移动字符串/矢量计数 都已被删除。

  1. 此 FTP 基于 rfc-0026，但只使用外行信封 ↩

  2. 请注意，目前空（零字段）结构体会占用一个字节网络。 ↩