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