| RFC-0037：交易郵件標頭 v3 | |
|---|---|
| 狀態 | 已接受 |
| 區域 |
|
| 說明 | 本提案會修改 FIDL 傳輸格式。系統會將交易標頭的保留位元組分配給一個位元組魔法號碼，以識別所使用的傳輸格式，以及三個位元組，以供暫時遷移用的旗標使用。 |
| 作者 | |
| 提交日期 (年/月) | 2019-03-07 |
| 審查日期 (年/月) | 2019-03-14 |
摘要
此提案會修改傳輸格式，如下所示。
系統會將交易標頭的保留位元組數分配給以下項目：
- 一個位元組的磁數字，用於識別所使用的傳輸格式。
- 此外，旗標還有三個位元組，用來進行軟性遷移作業。
此外，epitaph 酬載是 struct{int32}，而不是標頭中的「Adhorning epitaphs」。
動力與設計
在標題中加入神奇數字：
- 此機制可讓讀取者瞭解收到的訊息是否相容 (或附註)，以及對寫入者提供一種機制，用來表示訊息傳送的格式。
- 魔術數字的順序為非目標，應直接檢查魔術數字，如果不相容 (例如不支援)，就會拒絕。具體來說，我們不相信「version」一詞，因為我們要進行配對相容性檢查，而非「支援 v5 到 v8」中的範圍式相容性。
在標頭中使用旗標：
- 提供處理軟轉換的機制，特別是繫結「不得」在不知道是否使用特定旗標時拒絕訊息的要求，直接忽略這類要求。例如，用於遷移離開靜態聯集。
- 我們傾向將更多位元組分配給標記 (3 個位元組)，而非使用魔法數字 (1 個位元組)，因為我們預期在暫時需要更多的功能，而不只是傳輸格式變種版本。
使用 Epitaph：
- Epitaph 會「shoehored」進入
reserved個位元組，現在用於魔法數字和標記； - 使用基數是純粹的惡意酬載
struct{int32}會從連接格式中移除一個特殊雪花，這樣通常可以簡化繫結，並降低發生錯誤或不相容的可能性。
最後，我們想盡量縮小標頭，這個明確目標就是將標頭維持在 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 個位元組對影響幾乎不會造成太大影響。