| RFC-0113：高效信封 | |
|---|---|
| 状态 | 已接受 |
| 领域 |
|
| 说明 | 此 FTP 为信封提出了一种更紧凑的编码方案。 |
| Gerrit 更改 | |
| 作者 | |
| 审核人 | |
| 提交日期（年-月-日） | 2021-06-21 |
| 审核日期（年-月-日） | 2021-07-21 |
“把信封变成明信片”
摘要
此 RFC 针对 FIDL1 提出了一种更紧凑的编码方案。
设计初衷
信封是可扩展、可进化的数据结构的基础 （表和可扩展联合）。 一种更紧凑、更高效的信封电线格式 可扩展结构，用于性能优越的 和线缆尺寸都很重要
设计
建议的信包格式可以描述为以下 C 结构：
struct Envelope {
uint32_t byte_size;
uint32_t handle_count;
};
与现有的信封格式相比：
- 字节大小字段保持不变（32 位）。
- 大小包括可能以递归方式返回的任何子对象的大小 编码。
- 例如，
vector<string>的尺寸包括 外向量的内部字符串子对象。 - 这与当前信封的现有行为一致 尺寸字段。
- 句柄计数字段保持不变（32 位）。
- handle_count 包含所有递归的句柄计数 子对象。
- 存在/缺失字段被丢弃。
- 在线状态由一个非零值（大小或 handle_count 字段。
- 缺失用大小和都属于“0”的句柄。
- 我们称之为“零信封”。
- 零信封相当于
FIDL_ALLOC_ABSENT。
- 验证字节大小字段
<ph type="x-smartling-placeholder">
- </ph>
- 必须验证字节大小字段为 8 的倍数。
解码器可以使用指向信封数据的指针覆盖信封。 假设他们知道信封内容的静态类型（架构）。 请参阅未知数据部分，获取有关操作方法的建议 来处理信封。
编码/解码形式的 C/C++ 结构体
信封的编码或解码形式可以描述为 C 并集：
typedef union {
struct {
uint32_t byte_size;
uint32_t handle_count;
} encoded;
void* data;
} fidl_envelope_t;
static_assert(sizeof(fidl_envelope_t) == sizeof(void*));
未知数据
接收器 - 验证器和解码器 - 可能不知道 它们用于可进化的数据结构中。 如果接收方不知道类型，则可以对信包进行最低限度的解析 已跳过。
- 信封的大小决定了要跳过的外行数据量。
- 如果信封的句柄计数为非零，验证器必须存储 或关闭每个手柄
- 解码器可以使用指向
信封的内容（如果要就地解码）。
- 如果解码器确实用指针覆盖了信封，则会丢失 尺寸和处理信封中的计数信息。 绑定可以为解码器提供一种机制来保存 在覆盖信封之前处理计数信息；这个 RFC 未就此类机制的工作原理发表意见。
实施策略
此 RFC 是一项重大的传输格式更改。
我们将进行复杂的传输格式迁移，以改用高效 信封。这项传输格式变更将与其他迁移合并 以降低每项特性的迁移费用。
向后兼容性
提议的传输格式更改与 API（源）兼容。 需要手动更新任何 FIDL 代码以处理新电线 格式。
传输格式更改与 ABI 不兼容。
性能
在 CL 设计出高效的信封实施原型。对于此测试，输入 是一个设置了所有字段的表其他输入也产生了类似的结果。
以下时间以纳秒为单位。没有高效信封的时间 箭头前面，而使用高效信封的时间位于箭头后面。
| # 个字段 | 编码 | 解码 |
|---|---|---|
| 16 | 64 ->40 | 176 ->146 |
| 64 | 165 ->121 | 321 ->221 |
| 256 | 567 ->368 | 923 ->527 |
| 1024 | 2139 ->1429 | 3284 ->1636 年 |
根据输入的不同，使用高效信封的速度似乎提高了 1.1-2 倍
工效学设计
- 利用更高效的可扩展数据结构， 在效率至关重要的更多情境下，用户需担忧 并享受可扩展性的优势， 以前，他们需要使用非可扩展结构。
- 我们甚至建议将表用于
为实现高性能，应保留 FIDL 数据结构和结构体
上下文。
- 可扩展联合 (RFC-0061) 已尝试 移除静态联合体。
文档
- 线上传输格式文档需要更新。
- 更新文档时， 一流概念：这有助于提高认知 分块。 可扩展数据结构。
- 我们应更新 FIDL 样式指南，以便针对 都应该使用可扩展类型
安全
此 RFC 应该不会对安全造成任何影响。
一个小的安全优势是，此 RFC 会移除
与旧格式中的大小和指针重复。
以前，接收的信封可能具有非零大小/标识名，并且
FIDL_ALLOC_ABSENT 或零大小/句柄和 FIDL_ALLOC_PRESENT。
这需要执行额外的验证检查，您将不再需要此类检查。
无法确定信封是采用电线形式还是 解码形式。这不是问题 练习时，总在绑定中分别记账 可跟踪消息是采用电汇形式还是解码形式。
隐私权
此 RFC 应该不会对隐私造成任何影响。
测试
- 由于此 RFC 将改变信封的电线格式，因此我们认为 现有的 FIDL 测试套件，尤其是兼容性测试 ）能够充分测试使用信封的所有场景。
- 如果我们同意采用软过渡的方式传输有线格式更改（请参阅 实现策略部分），我们将添加 以便对等方进行协商，并可能改用新的有线格式。
缺点、替代方案和未知问题
如果我们认为这种传输方式能够提高 不会物有所值。
之前的 RFC 拒绝和现在用于批准的参数
此 RFC 之前曾被拒绝，理由是（已复制 一字不差的意思）之后才能重新提交以供审核：
2019 年 2 月 21 日，此 RFC 最初被接受。FIDL 团队 在 2019 年的大部分时间里稳定电线格式，最终实现全员演示 （涵盖第三季度和第四季度）。迁移已于以下日期完成： 2019 年 12 月 1 日。
稳定工作涉及多项变化：
然而，随着工作的展开，首截止日期已临近， FIDL 团队决定开始实施高效的信封变革， 希望将这项工作推到 2020 年。与其他部分更改 因此，高效的信封只是内存中的大小 但节省金额很少，特别是与 FIDL 传输格式（例如表的密集格式）。 推迟是一项用于降低项目风险的计算方法，通过缩小范围， 提高了按时完成所有工作的几率。FIDL 团队的 工作时间表。
现在，延期已接近 18 个月，高效信封 早忘了。2020 年的大量绩效表明， 不会产生实质性影响。
是时候直面真相了，这是不会的。已遭拒。
为什么要立即重新批准？
FIDL 团队目前计划将多种传输格式进行批处理。 一次性迁移所有更改这意味着 有机会以较低的成本增加对高效信封的支持（因为 费用会与其他迁移分摊）。
此外，我们现在还提供了 因此其收益非常可观
由于这些因素，现在正是恢复此 RFC 和 实施。
先验技术和参考资料
此 RFC 是 rfc-0026 的精简版本，自 并未能就整个 RFC 获得足够的共识。