| RFC-0037：交易訊息標頭 v3 | |
|---|---|
| 狀態 | 已接受 |
| 區域 |
|
| 說明 | 這項提案會修改 FIDL 線路格式。交易標頭的保留位元組會分配給一個位元組魔術數字，用於識別所用電報格式，以及三個用於暫時軟遷移的旗標位元組。 |
| 作者 | |
| 提交日期 (年-月-日) | 2019-03-07 |
| 審查日期 (年-月-日) | 2019-03-14 |
摘要
本提案會修改線路格式，如下所示。
交易標頭的保留位元組會分配給：
- 一個位元組魔術數字，用於識別所使用的線路格式。
- 而三個位元組的標記則是用於暫時執行軟遷移。
此外，碑文酬載不是在標頭中塞入碑文值，而是 struct{int32}。
動機與設計
標頭中含有神奇數字：
- 為讀者提供機制，指出收到的訊息是否相容 (或附註)，並對稱地提供機制，讓作者指出傳送訊息的格式。
- 排序魔術數並非目標，魔術數應只需檢查，如果不相容 (即不支援)，則應予以拒絕。具體來說，我們不使用「版本」一詞，因為我們希望進行成對的相容性檢查，而非「支援 v5 到 v8」那樣的範圍相容性。
在標頭中加入標記：
- 提供機制協助軟性轉換，特別是要求繫結不得在不知道如何使用特定標記時拒絕訊息，而應直接忽略。例如，這項功能可用於從靜態聯集移轉。
- 我們傾向將更多位元組分配給旗標 (3 個位元組)，而非魔術數字 (1 個位元組)，因為我們預期會需要更多功能 (而非線路格式變化版本)。
在墓誌銘文上：
- 銘文被塞進
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 團隊無法合理地逐步淘汰所要改進或取代的線路格式，則必須為新的線路格式指派魔術數字。
成效
將碑文設為 struct{int32} 酬載，而不是嵌入交易標頭，可將讀取的位元組數從 16 位元組增加到 24 位元組。高效繫結堆疊會配置小型緩衝區，因此增加 8 位元組的影響不大。