RFC-0113：有效信封

「Turning Envelopes into Postcards」(將信封變成明信片)

摘要

這項 RFC 建議採用更精簡的 FIDL ¹ 編碼。

提振精神

信封是可擴充、可演進資料結構 (表格和可擴充聯集) 的基礎。信封的線路格式更精簡有效率，因此這些可擴充的結構體能用於更多情境，提升效能並縮減線路大小。

設計

建議的封包格式可描述為下列 C 結構：

struct Envelope {
    uint32_t byte_size;
    uint32_t handle_count;
};

與現有信封格式相比：

• 位元組大小欄位維持不變 (32 位元)。
  • 大小包括可能以遞迴方式編碼的任何子物件大小。
  • 舉例來說，vector<string> 的大小包括外部向量的內部字串子物件大小。
  • 這與目前封包實作的 size 欄位現有行為相符。
• 控制代碼計數欄位維持不變 (32 位元)。
  • handle_count 包含所有遞迴子物件的控制代碼計數。
• 已捨棄「存在/缺席」欄位。
  • 如果大小或 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*));

不明資料

接收器 (驗證器和解碼器) 在可演進的資料結構中使用時，可能不知道封包的類型。如果接收者不知道類型，系統可以最低程度地剖析信封並略過。

• 信封的大小決定要略過多少行外資料。
• 如果信封的控制代碼計數不為零，驗證器「必須」儲存或關閉每個控制代碼。
• 如果解碼器想就地解碼，可以將不明封包覆寫為指向封包內容的指標。
  • 如果解碼器確實會以指標覆寫封包，封包中的大小和控制代碼計數資訊就會遺失。繫結「可能」會提供機制，讓解碼器在覆寫封包前儲存大小和控制代碼計數資訊；本 RFC 不會針對這類機制的運作方式表示意見。

導入策略

這項 RFC 是破壞性的連線格式變更。

我們會進行複雜的線路格式遷移作業，改用有效率的信封。這項線路格式異動將與其他遷移作業合併，以降低每項功能的遷移成本。

回溯相容性

建議的傳輸格式變更與 API (來源) 相容。任何手動捲動的 FIDL 程式碼都必須更新，才能處理新的線路格式。

傳輸格式變更與 ABI 不相容。

效能

我們在 CL 中執行了效能評估，在這項測試中，輸入內容是已設定所有欄位的資料表。其他輸入內容也產生類似結果。

以下時間以奈秒為單位。箭頭前方的時間表示沒有效率封包的時間，箭頭後方的時間則表示有效率封包的時間。

視輸入內容而定，使用有效率的信封似乎快了 1.1 到 2 倍

人體工學

• 更有效率的可擴充資料結構可應用於更多重視效率的環境，因此使用者不必太擔心效能，而且可享有可擴充性的優點，不必再使用不可擴充的結構。
• 我們甚至可能建議預設應將表格用於 FIDL 資料結構，並保留結構體用於高效能環境。
  • 可擴充聯集 (RFC-0061) 正在嘗試移除靜態聯集。

說明文件

• 線路格式說明文件需要更新。
• 更新說明文件時，應將封包說明為第一級概念：這樣一來，讀者遇到選用性和可擴充資料結構的連線格式時，就能更輕鬆地認知分塊。
• 我們應更新 FIDL 樣式指南，建議何時應使用可擴充型別。

安全性

這項 RFC 不應會造成任何安全性影響。

這項 RFC 的一項次要安全優勢是，可移除舊格式中大小和指標重複的資訊。先前，可能會收到大小/控點不為零的信封和 FIDL_ALLOC_ABSENT，或是大小/控點為零的信封和 FIDL_ALLOC_PRESENT。這需要額外的驗證檢查，但現在不需要了。

單憑資料無法判斷信封是否為線路形式或解碼形式。這不是問題，因為在實務上，繫結中一律會進行個別的記帳作業，追蹤訊息是否為線路形式或已解碼。

隱私權

這項 RFC 不應對隱私權造成任何影響。

測試

• 由於這項 RFC 會變更信封的連線格式，我們認為現有的 FIDL 測試套件 (尤其是相容性測試) 足以測試所有使用信封的案例。
• 如果我們同意將線路格式變更做為軟轉換 (請參閱「實作策略」一節)，我們會新增同層級協商測試，並可能切換至新的線路格式。

缺點、替代方案和未知事項

如果我們認為這項提案的效率提升幅度不值得實作成本，可以保留現有的線路格式。

先前拒絕 RFC 的原因，以及現在核准的原因

這項 RFC 先前遭到拒絕，理由如下 (以下為原文)：

這項 RFC 最初於 2019 年 2 月 21 日獲得接受。FIDL 團隊在 2019 年大部分時間都致力於穩定線路格式，並在第 3 季和第 4 季全力以赴，遷移作業已於 2019 年 12 月 1^日完成。

穩定性工作涵蓋多項變更：

• 重大 RFC-0061：可擴充的聯集
• RFC-0032：有效率的信封，即本 RFC
• RFC-0037：交易訊息標頭 v3
• RFC-0048：明確的聯集序數

不過，隨著工作展開，且 12 月 1^日的期限逼近，FIDL 團隊決定延後實作有效率的信封變更，並將這項工作延至 2020 年。與其他穩定性工作相關的變更不同，有效率的封包只是節省了記憶體大小，而且節省的空間非常小，尤其是與 FIDL 線路格式的其他方面 (例如表格的密集格式) 相比。延期是為了降低專案風險而進行的計算，縮減範圍後，按時完成所有工作的機率就會提高。FIDL 團隊的工作時間也是如此。

延後期限至今已將近 18 個月，高效信封早已被遺忘。2020 年的重大效能工作顯示，這項異動不會造成重大影響。

是時候面對現實了，這是不可能發生的。已遭拒。

為什麼現在需要重新核准？

FIDL 團隊目前打算將多項線路格式變更分批處理，並一次完成所有變更的遷移作業。也就是說，您有機會以較低的成本新增對有效封包的支援 (因為成本會與其他遷移作業共用)。

此外，現在也有具體數字顯示，由於有效率的信封，效能提升幅度顯著。

基於上述因素，現在是重新提出並實作這項 RFC 的好時機。

既有技術和參考資料

這項 RFC 是 rfc-0026 的簡化版本，由於整個 RFC 未獲得足夠共識，因此遭到拒絕。