| RFC-0037：交易訊息標頭 v3 | |
|---|---|
| 狀態 | 已接受 |
| 區域 |
|
| 說明 | 這項提案會修改 FIDL 線路格式。交易標頭的保留位元組會分配給一個位元組的魔術數字，用於識別所用的線路格式，以及三個位元組的旗標，暫時用於軟體遷移。 |
| 作者 | |
| 提交日期 (年-月-日) | 2019-03-07 |
| 審查日期 (年-月-日) | 2019-03-14 |
摘要
本提案會修改線路格式，如下所示。
交易標頭的保留位元組會分配給：
- 一個位元組的魔術數字，用於識別所用的連線格式；
- 以及用於暫時軟遷移的三個位元組的標記。
此外，與其在標頭中硬塞墓誌銘值，不如使用墓誌銘酬載 struct{int32}。
動機與設計
標頭中含有魔術數字：
- 為讀者提供機制，判斷收到的訊息是否相容 (或附註)，並為寫入者提供機制，指出傳送訊息的格式。
- 魔術數字的排序並非目標，魔術數字應僅經過檢查，若不相容 (即不支援)，則應遭到拒絕。具體來說，我們避免使用「版本」一詞，因為我們需要成對相容性檢查，而不是範圍相容性，例如「支援 v5 到 v8」。
在標題中加入旗標：
- 提供機制協助軟轉換，尤其是繫結不得因不瞭解特定旗標的使用方式而拒絕訊息，而是直接忽略這些旗標。舉例來說，這項功能可用於從靜態聯集遷移。
- 我們偏好將更多位元組分配給旗標 (3 個位元組)，而不是魔術數字 (1 個位元組)，因為我們預期暫時需要的功能會比連線格式類型多得多。
墓誌銘：
最後，我們希望標頭盡可能小，因此明確目標是將標頭維持在 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 個位元組的影響極小。