| RFC-0037：事务性消息标头 v3 | |
|---|---|
| 状态 | 已接受 |
| 区域 |
|
| 说明 | 此提案修改了 FIDL 有线格式。交易标头的预留字节分配给一个字节的 magic number，用于标识所用的有线格式；另外三个字节用于标志，这些标志旨在临时用于软迁移。 |
| 作者 | |
| 提交日期（年-月-日） | 2019-03-07 |
| 审核日期（年-月-日） | 2019-03-14 |
摘要
此提案修改了有线格式，如下所示。
交易标头的预留字节分配给：
- 一个字节的幻数，用于标识所用的有线格式；
- 还有 3 个字节用于标志，这些标志旨在临时用于软迁移。
此外，墓志铭值不再强行塞入标头中，而是以 epitaph 载荷的形式存在，即 struct{int32}。
动机和设计
在标头中包含魔数：
- 为读取器提供一种机制，用于指示收到的消息是否兼容（或不兼容），并为写入器提供一种对称的机制，用于指示发送的消息的格式。
- 魔法数的顺序不是目标，只需检查魔法数，如果不兼容（即不支持），则拒绝。具体来说，我们避免使用“版本”一词，因为我们希望进行成对的兼容性检查，而不是像“支持 v5 到 v8”那样基于范围的兼容性检查。
在标头中添加标志：
- 提供一种机制来帮助实现软过渡，特别是要求绑定不得因不知道某些标志的用法而拒绝消息，而应直接忽略这些标志。例如，此功能用于从静态联合迁移。
- 我们更倾向于为标志分配更多字节 (3 字节)，而不是为 magic number 分配更多字节 (1 字节)，因为我们预计临时需要的功能比 wire 格式风格多得多。
在墓志铭中：
- 墓志铭被强行塞入
reserved字节中，而这些字节现在用于魔数和标志； - 将墓志铭设为普通的有效负载
struct{int32}可从有线格式中移除一个特殊的 snowflake，这通常会简化绑定并降低出现 bug 或不兼容问题的可能性。
最后，我们希望尽可能缩小标头，并明确目标是将其保持在 16 字节，同时支持上述额外要求。
交易消息标头的演变
FIDL2（“v2”）：
- 交易 ID (
uint32) - 预留（
uint32） - 标志（
uint32个） - 序数 (
uint32)
- 交易 ID (
uint32) - 预留 (
uint32) 或 Epitaph 值 (zx.status) - 标志（
uint32个） - 序数 (
uint32)
- 交易 ID (
uint32) - 预留 (
uint32) 或 Epitaph 值 (zx.status) - 序数 (
uint64)
最初，覆盖字节 4 到 7 的预留 (uint32) 字段旨在与 zx_channel_call 的要求保持一致。不过，该系统调用已稳定，不再需要此要求。
版本 3
我们将事务性消息标头（“v3”）稳定为：
- 交易 ID (
uint32) - 标志（
array<uint8>:3，即 3 个字节） - 魔数 (
uint8) - 序数 (
uint64)
绑定不得检查标志，除非是这些绑定正在使用或了解的特定标志，也就是说，设置接收方绑定未知的位是有效的。
线框格式图如下：
何时应分配新的魔数
初始 magic number 将为 0x01。我们稍后会提供更有趣的数字。
当 FIDL 团队无法合理地逐步淘汰正在发展或替换的线格式时，必须为新线格式分配一个 magic number。
性能
让墓志铭成为 struct{int32} 载荷，而不是嵌入在交易标头中，可将读取的最小字节数从 16 字节增加到 24 字节。高性能绑定堆栈会分配一个小型缓冲区，增加 8 字节的影响很小。