| RFC-0113：高效率信封 | |
|---|---|
| 狀態 | 已接受 |
| 區域 |
|
| 說明 | 這個 FTP 建議針對信封使用更精簡的編碼。 |
| 變更 | |
| 作者 | |
| 審查人員 | |
| 提交日期 (年/月) | 2021-06-21 |
| 審查日期 (年/月) | 2021-07-21 |
「將信封轉換成明信片」
摘要
這個 RFC 建議使用更精簡的 FIDL1 編碼。
提振精神
信封是可延伸、可持續調整的資料結構 (資料表和可擴充的聯集) 的基礎。信封格式是更精簡且有效率的傳輸方式，可在效能和電線大小影響的更多環境中使用這些擴充結構。
設計
建議的信封格式可按照以下 C 結構描述：
struct Envelope {
uint32_t byte_size;
uint32_t handle_count;
};
與現有的信封格式比較：
- 位元組大小欄位保持不變 (32 位元)。
- 大小包括任何可遞迴編碼的子物件的大小。
- 舉例來說，
vector<string>的大小包括外部向量內部字串子物件的大小。 - 這與目前信封實作大小欄位的現有行為相符。
- 處理次數欄位保持不變 (32 位元)。
- handle_count 是所有遞迴子物件的控制代碼計數。
- 系統會捨棄「存在/不存在」欄位。
- 狀態為「size」(大小) 或「handle_count」欄位以非零的值表示。
- 如缺少項目，大小和帳號代碼數量欄位均以零表示。
- 我們稱之為「零信封」。
- 零信封相當於
FIDL_ALLOC_ABSENT。
- 位元組大小欄位驗證
- 位元組大小欄位必須驗證為 8 的倍數。
解碼器「可能會」使用信封資料指標覆寫信封，假設他們知道信封內容的靜態類型 (結構定義)。如需在內容類型不明的情況下處理信封的建議，請參閱「不明資料」一節。
編碼/解碼表單的 C/C++ 結構
信封的編碼或解碼形式可稱為 C-聯集：
typedef union {
struct {
uint32_t byte_size;
uint32_t handle_count;
} encoded;
void* data;
} fidl_envelope_t;
static_assert(sizeof(fidl_envelope_t) == sizeof(void*));
不明資料
在可改進的資料結構中，接收端 (驗證工具和解碼器) 可能無法知道信封的類型。如果接收者不知道類型，系統可能會以最低限度剖析及略過信封。
- 信封大小會決定您要略過的外線資料量。
- 如果信封的控點數量不為零，驗證工具「必須」儲存或關閉每個控點。
- 如果解碼器想要就地解碼，則解碼器 MAY 會使用指標指向信封的內容，覆寫未知信封。
- 如果解碼器使用指標覆寫信封，就會失去信封的大小和處理次數資訊。繫結 MAY 可讓解碼器在覆寫信封前儲存大小和處理計數資訊，但這個 RFC 並不代表這類機制的運作原理。
導入策略
這項 RFC 是破壞性的傳輸格式變更。
這種複雜的線路遷移程序會由系統改用有效率的信封。這項線路格式變更會與其他遷移作業結合，以降低每項功能的遷移費用。
回溯相容性
建議的傳輸格式變更與 API (來源) 相容。任何手動捲動 FIDL 代碼都必須更新以處理新的線路格式。
傳輸格式變更與 ABI 不相容。
效能
效能評估是在 CL 中執行，該元件用來設計有效的信封設計原型。在這項測試中，輸入內容是已設定所有欄位的資料表。其他輸入內容會產生類似的結果。
以下時間以奈秒為單位。沒有有效率的信封會在箭頭之前，而有效率的信封會顯示在箭頭之後。
| # 個欄位 | 編碼 | 解碼 |
|---|---|---|
| 16 | 64 -> 40 | 176 -> 146 |
| 64 | 165 -> 121 | 321 -> 221 |
| 256 | 567 -> 368 | 923 -> 527 |
| 1024 | 2139 -> 1429 年 | 3284 -> 1636 |
根據輸入內容而定，使用高效率信封的速度似乎是原先的 1.1 至 2 倍
人體工學
- 有效率的可擴充資料結構有助於在效率重要的情境下運用資料，因此使用者不必顧慮效能，還可以在原本需要使用無法擴充的結構時，享有擴充能力帶來的好處。
- 我們甚至希望建議預設將資料表用於 FIDL 資料結構，且結構應保留給高效能的結構定義。
- 可擴充聯集 (RFC-0061) 已嘗試移除靜態聯集。
說明文件
- 傳輸格式說明文件需要更新。
- 更新說明文件時，訊息應做為一流概念說明，當讀者遇到可選性和可擴充的資料結構的傳輸格式時，這樣做就能獲得更好的認知區塊化效果。
- 我們應更新 FIDL 樣式指南，以在何時應使用可擴充類型時提供建議。
安全性
這個 RFC 不會造成任何安全性影響。
這個 RFC 會移除舊格式大小和指標重複的資訊。過去，收到信封時可能會收到非零大小/帳號代碼，FIDL_ALLOC_ABSENT，或是大小/帳號代碼為零，FIDL_ALLOC_PRESENT。這樣就不需要進行額外的驗證檢查。
無法單獨判斷信封是否是散發形式或來自資料的解碼形式。這不算是問題，因為在實務上，繫結中總是有個別的記帳，可以追蹤訊息是採用有線還是解碼形式。
隱私防護
這個 RFC 不會對隱私權造成任何影響。
測試
- 由於這個 RFC 將變更信封的傳輸格式，因此我們認為現有的 FIDL 測試套件 (特別是相容性測試) 能對所有使用信封的情況充分測試。
- 如果同意將線路格式變更視為軟式轉場 (請參閱「實作策略」一節)，我們就會新增測試給對等點進行協商，並有可能切換至新的線路格式。
缺點、替代方案和未知
如果我們認為這個提案的效率提升價值並不值得，可以保留現有的傳輸格式。
先前用於核准的 RFC 拒絕和引數
這個 RFC 先前因下列理由 (請完整複製在這裡) 而遭拒，之後才會重新提交審查：
2019 年 2 月 21 日一開始接受了這個 RFC。FIDL 團隊在 2019 年大部分都致力於穩定電線格式，在第 3 季和第 4 季全程共襄盛舉。遷移作業已於 2019 年 12 月 1 日完成。
穩定功能涵蓋多項變更：
不過，隨著工作進展，到 12 月 1 日的期限已到，FIDL 團隊決定設法實施有效的信封變更，偏好將工作發展到 2020 年。不同於穩定工作的其他變更，高效率信封只是節省記憶體內的大小，就來說非常小，與 FIDL 傳輸格式的其他方面 (例如資料表的稠密格式相比) 更是如此。「延遲」是一種降低專案風險的計算方法，透過減少範圍，就能更快完成所有工作。是 FIDL 團隊的工作時間表
如今我們現在已經快要實現延後 18 個月了，有效率的信封已經被遺忘了。在 2020 年獲得顯著的效能表現，證明這個變化不會對實質影響。
現在要面對真相，這件事不會發生。已拒絕。
為何現在重新核准？
FIDL 團隊目前打算批次處理多項傳輸格式變更，並一次進行遷移。這代表我們有機會以更低成本的方式新增高效率信封支援 (成本會與其他遷移作業共用)。
此外，現在也有具體數據，因為有效率的信封可以提升效能，改善幅度更是顯著。
基於這些因素，我們必須重新執行並執行此 RFC。
先前的圖片和參考資料
這個 RFC 是 rfc-0026 的精簡版本，由於整個 RFC 的達成程度不足，因此遭到拒絕。