| RFC-0037：事务邮件标头 v3 | |
|---|---|
| 状态 | 已接受 |
| 领域 |
|
| 说明 | 此方案修改了 FIDL 传输格式。系统会将事务标头的预留字节分配给一个 1 字节魔数，用于标识所用的传输格式，以及 3 字节分配给要临时用于软迁移的标志。 |
| 作者 | |
| 提交日期（年-月-日） | 2019-03-07 |
| 审核日期（年-月-日） | 2019-03-14 |
总结
此方案对电汇格式进行了如下修改。
事务标头的预留字节将分配给：
- 一个字节魔数，用于标识所用的传输格式；
- 3 个字节的标志表示临时用于软迁移。
此外，表皮表载荷是 struct{int32}，而不是在标头中淘汰 epitaphs 值。
动机和设计
标头中包含一个神奇的数字：
- 向读取器提供接收的消息是否兼容（或备注）的机制，并为写入者提供一种指示所发送消息格式的机制。
- 魔数的排序没有目标，魔数只需进行检查，如果不兼容（即不支持），则拒绝。具体来说，我们避免使用“版本”这一术语，因为我们希望进行成对兼容性检查，而不是像“支持 v5 到 v8”中那样基于范围的兼容性进行兼容性检查。
标头中包含标记：
- 提供一种有助于软转换的机制，尤其是要求绑定不得拒绝消息（如果不知道某些标志的使用，而是直接忽略）这一要求。例如，它用于远离静态联合。
- 与为标记（3 个字节）分配更多字节而非为魔数（1 个字节）分配更多字节，因为我们预计临时需要比传输格式变种更多的功能。
在表皮相上：
- 圣书被插入
reserved个字节，现在用于魔数和旗帜； - 将 epitaph 作为普通的 vanilla 载荷，
struct{int32}可以从有线格式中移除一种特殊雪花，这种格式通常可以简化绑定并降低出现 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)
绑定不得检查标记，但这些绑定使用或了解的特定标记除外，即设置接收者绑定不知道的位有效。
以线路格式图所示，我们有：
何时应分配新的魔数
初始魔数为 0x01。我们保留一些比较有趣的数字，以供日后观看。
当 FIDL 团队无法合理地逐步淘汰新的传输格式时，必须为新的传输格式分配一个魔数。
性能
将 epitaph 作为 struct{int32} 载荷，而不是将其嵌入到事务标头中，可将读取的最小字节数从 16 个字节增加到 24 个字节。性能绑定堆栈会分配一个小型缓冲区，而增加 8 个字节所产生的影响微乎其微。