RFC-0032：高效信封

RFC-0032：高效率信封
狀態已遭拒
區域
  • FIDL
說明

這個 FTP 建議針對信封使用更精簡的編碼。
作者
提交日期 (年/月)2019-02-06
審查日期 (年/月)2019-02-21

編輯此 RFC

編輯 RFC 中繼資料

「將信封轉換成明信片」

拒絕原因

我們在 2019 年 2 月 21 日一開始接受了這個 RFC。FIDL 團隊在 2019 年大部分都致力於穩定電線格式，在第 3 季和第 4 季全程共襄盛舉。遷移作業已於 2019 年 12 月 1 日完成。

穩定功能涵蓋多項變更：

不過，隨著工作進展，到 12 月 1 日的期限已到，FIDL 團隊決定設法實施有效的信封變更，偏好將工作發展到 2020 年。不同於穩定工作的其他變更，高效率信封只是節省記憶體內的大小，就來說非常小，與 FIDL 傳輸格式的其他方面 (例如資料表的稠密格式相比) 更是如此。「延遲」是一種降低專案風險的計算方法，透過減少範圍，就能更快完成所有工作。是 FIDL 團隊的工作時間表

如今我們現在已經快要實現延後 18 個月了，有效率的信封已經被遺忘了。在 2020 年獲得顯著的效能表現，證明這個變化不會對實質影響。

現在要面對真相，這件事不會發生。已拒絕。

與其他 RFC 的關係

在 2021 年 6 月，我們重新瀏覽了這個主題，並使用指定目標基準進行評估。結果證明，RFC-0113 提議重新導入變更，結果已獲接受。

摘要

這個 FTP 為信封提供了更精簡的編碼1。

提振精神

信封是可延伸、可持續調整的資料結構 (資料表和可擴充的聯集) 的基礎。信封格式是更精簡且有效率的傳輸方式，可在效能和電線大小影響的更多環境中使用這些擴充結構。

設計

建議的信封格式為：

圖：64 位元小字符、MSB 32 位元大小、16 位元控制代碼、16 位元預留數

與現有的信封格式比較：

  • 大小欄位保持不變 (32 位元)。
    • 大小包括任何可遞迴編碼的子物件的大小。
    • 舉例來說，vector<string> 的大小包括外部向量內部字串子物件的大小。
    • 這與目前信封實作大小欄位的現有行為相符。
  • 預留 16 位元。
    • 解碼器必須驗證保留的位元為零。
    • 如果我們日後要使用保留的位元，建議您改為修改線路格式。
      • 您應針對 FIDL 更全面地考慮保留的位元，以便讓不同規格的行為保持一致。
      • 要特別注意的是，FIDL 中並沒有先例，讓解碼器忽略任何位元：已定義及指定線上的所有位元。
      • 這是最容易的決定：必須變更傳輸格式，而非啟用前向相容性，才能簡化作業，直到決定保留位元的政策為止。
  • hand_count 為 16 位元，而非 32 位元。
    • 目前，Zircon 管道無法傳送超過 64 個帳號代碼，我們覺得 16 位元已足以因應未來需求。
    • handle_count 是所有遞迴子物件的控制代碼計數。
  • 系統會捨棄「存在/不存在」欄位。
    • 狀態為「size」(大小) 或「handle_count」欄位以非零的值表示。
    • 如缺少項目，大小和帳號代碼數量欄位均以零表示。
  • UINT32_MAX 的大小和處理 0 的情況很特殊，它代表有但大小為零的信封內容。
    • 如果零大小的空白結構變成實際2，那就會保留下來，不會對解碼器造成任何效能或複雜度負面影響。我們希望現在提及這個項目，以免未來的實作程序中斷線路格式。
    • 我們可以改為竊取其中一個保留位元。 我們並沒有對這種看法，只要能夠區分「存在但為零的」信封和 FIDL_ALLOC_ABSENT，這沒關係。享受共識。

解碼器「可能會」使用信封資料指標覆寫信封，假設他們知道信封內容的靜態類型 (結構定義)。如需在內容類型不明的情況下處理信封的建議，請參閱「不明資料」一節。

編碼/解碼表單的 C/C++ 結構

信封的編碼形式可用以編碼或解碼形式的聯集表示。

typedef union {
  struct {
    uint32_t size;
    uint16_t handle_count;
    uint16_t reserved;
  } encoded;
  void* data;
} fidl_envelope_t;

static_assert(sizeof(fidl_envelope_t) == sizeof(void*));

不明資料

在可改進的資料結構中，接收端 (驗證工具和解碼器) 可能無法知道信封的類型。如果接收者不知道類型，系統可能會以最低限度剖析及略過信封。

  • 信封大小會決定您要略過的外線資料量。
  • 如果信封的控點數量非零，驗證工具「必須」處理指定數量的控點。
    • 預設的處理行為「必須」關閉所有帳號代碼。
  • 如果解碼器想要就地解碼，則解碼器 MAY 會使用指標指向信封的內容，覆寫未知信封。
    • 如果解碼器使用指標覆寫信封，就會失去信封的大小和處理次數資訊。繫結 MAY 可讓解碼器在覆寫信封前儲存大小和處理計數資訊；此 FTP 並不代表這類機制的運作原理。

導入策略

這個 FTP 是嚴重的傳輸格式變更問題。

兩個 FIDL 對等端都必須瞭解新的信封格式，並向同業告知他們瞭解新格式，才能使用新格式。因此，這通常會視為硬性轉換。由於這個 FTP 並未新增任何功能，如果我們決定將此變更套用為硬轉換，作者建議此變更與其他線路格式變更 (例如建議的序數大小變更) 分組。

也就是說，可以進行柔性轉換。方法如下：

  1. 交易訊息標頭中有 uint32 保留/旗標欄位。我們可以保留 1 位元給啟動的對等點，以表明它瞭解新的傳輸格式，分階段進行軟轉換：
    1. 確認所有用戶端和伺服器都能辨識新舊網路線格式。 我們會繼續使用舊線路格式。
    2. 請在交易訊息標頭中讓同業設定位元，藉此啟用新的線路格式。如果雙方都有設定位元，雙方都可以切換至新的線路格式。
    3. 當柔性轉換通過所有圖層後，所有 Fuchsia 都可以使用新的傳輸格式。我們可以移除交易訊息標頭中的位元設定。
    4. 刪除舊傳輸格式的程式碼，然後取消保留交易訊息標頭位元。
  2. 我們可以使用「[WireFormat=EnvelopeV2]」屬性 (或類似) 修飾特定 FIDL 訊息類型、介面或兩者，以表示訊息/介面應使用新的傳輸格式。
    1. 雖然使用 WireFormat 屬性來裝飾介面，似乎與傳輸格式變更保持一致，但因為結構可在不同的介面中使用，所以繫結需要額外的邏輯來決定使用結構的結構定義。
    2. 我們建議介面 [WireFormat] 屬性只影響介面方法引數的傳輸格式，而不會以遞迴方式影響引數的結構。
    3. 如此即可啟用部分遷移及選擇採用新的傳輸格式，讓團隊按照自己的步調遷移。
    4. 一旦所有結構體和介面都擁有 [WireFormat] 屬性，我們可以捨棄舊的傳輸格式，並假設所有結構體和介面都使用新的傳輸格式，並忽略這個屬性。

這兩種軟轉換方法都需花費大量開發時間、測試時間和空間發生錯誤。如要正確執行任一方法，並對計畫執行及成功移除舊程式碼，是相當費力的事。

我們可能會有可同時處理新舊傳輸格式的程式碼；否則，當我們對新傳輸格式的支援時，可能無法逐步放置 CL。鑒於能處理這兩種傳輸格式的程式碼，建議您採用上述其中一種軟轉換方法，設計能否進行軟轉換的原型。這類原型設計工作可能也會導致最終的破壞性電線格式變更產生一般策略，而且可能很有價值。如果不是，則 c'est la vie；硬性轉換則為強制轉換。

無論是要進行軟轉換或強制轉換，凡是手動彙整 FIDL 訊息的 Fuchsia 執行個體，都必須升級為新的傳輸格式。

回溯相容性

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

傳輸格式變更與 ABI 不相容。透過「實施策略」一節所述的策略，或許可以達到 ABI 相容性。

效能

這個 FTP 會大幅縮減信封所需的大小，看起來就像是整體淨利益。但是，如果可擴充的資料結構因效率較佳而變得較為普遍，這可能會被使用增加的成本所得，進而導致整體訊息較少且動態配置，且與使用無法擴充的資料結構相較。

人體工學

  • 有效率的可擴充資料結構有助於在效率重要的情境下運用資料，因此使用者不必顧慮效能，還可以在原本需要使用無法擴充的結構時，享有擴充能力帶來的好處。
  • 我們甚至希望建議預設將資料表用於 FIDL 資料結構，且結構應保留給高效能的結構定義。
    • 可擴充聯集 (RFC-0061) 已嘗試移除靜態聯集。

說明文件

  • 傳輸格式說明文件需要更新。
  • 更新說明文件時，訊息應做為一流概念說明，當讀者遇到可選性和可擴充的資料結構的傳輸格式時，這樣做就能獲得更好的認知區塊化效果。
  • 我們應更新 FIDL 樣式指南，以在何時應使用可擴充類型時提供建議。

安全性

這個 FTP 應不會對安全性造成重大影響。

其中一個次要的安全優點是，此 FTP 會移除舊格式中大小和指標重複的資訊。過去，收到信封時可能會收到非零大小/帳號代碼，FIDL_ALLOC_ABSENT，或是大小/帳號代碼為零，FIDL_ALLOC_PRESENT。這樣就不需要進行額外的驗證檢查。

測試

  • 由於這個 FTP 將變更信封的傳輸格式，因此我們認為現有的 FIDL 測試套件 (特別是相容性測試) 將可充分測試使用信封的所有情境。
  • 如果同意將線路格式變更視為軟式轉場 (請參閱「實作策略」一節)，我們就會新增測試給對等點進行協商，並有可能切換至新的線路格式。

缺點、替代方案和未知

如果我們認為這個提案的效率提升價值並不值得，可以保留現有的傳輸格式。

設計決策

雖然此 FTP 會提供建議，我們仍積極針對下列決策尋求意見和共識：

  • 我們是否考慮過慢轉換或強制轉換？請參閱「實作策略」一節，瞭解優缺點。
  • 我們建議使用 32 位元做為大小、16 位元進行控制代碼，並保留 16 位元。
    • 32 位元的大小合理嗎？
    • 16 位元的帳號代碼是否合理？
  • rfc-0026 這個提案衍生自 <= 32 位元類型，提議將資料直接內嵌進信封。
    • 我們決定撤銷這個提案，因為此提案會提高導入作業的複雜度，且除非有大量內嵌欄位，否則可帶來額外好處。
    • 我們正在努力改善選用性，例如將選填欄位組合成單一選用的結構。這類工作可能會過時當中的任何好處。

先前的圖片和參考資料

這個 FTP 是 rfc-0026 的精簡版本，由於整個 FTP 的普遍程度不足，因此遭到拒絕。

。 內嵌、密封和世界各地的信封都已移除，以及將字串/向量數量移動到外線。

  1. 這個 FTP 來自 rfc-0026，但「只」採用外線信封↩

  2. 請注意，今日空的 (零欄位) 結構會在網路上佔用一個位元組。 ↩