本頁面由 Cloud Translation API 翻譯而成。

RFC-0032：高效信封

RFC-0032：有效率的信封
狀態	已遭拒
領域	FIDL
說明	這個 FTP 可為信封設計更精簡的編碼方式。
作者	apang@google.com ianloic@google.com pascallouis@google.com
提交日期 (年-月-日)	2019-02-06
審查日期 (年-月-日)	2019-02-21

編輯此 RFC

編輯 RFC 中繼資料

「將信封轉換成明信片」

拒絕原因

自 2019 年 2 月 21 日起，此 RFC 最初已獲接受。FIDL 團隊致力於固定電線格式，以因應 2019 年大半年的需求而且範圍涵蓋第 3 季和第 4 季。遷移作業已於 12 月 1 日完成， 2019 年。

穩定計畫涵蓋多項變更：

然而，隨著工作尚未結束，而在 12 月 1 日的期限已久， FIDL 團隊決定不執行有效的信封變更，更傾向於 2020 年推動這項計畫。與一部分的其他變更不同而效率高的信封只是記憶體容量的一種儲存量相當小，如果與市場其他指標相比 FIDL 線格式 (例如資料表的密集格式)。「延遲」的計算方式是將範圍縮小及時完成所有工作的機率有所改善所以 FIDL 團隊工作排程

我們現在很快就要延後 18 個月信包長者遺忘。2020 年的卓越成效研究證明則不會產生實質影響

事實是，這一切終將是沒事。已拒絕。

與其他 RFC 的關係

2021 年 6 月，我們重新審視這個主題，並使用基準。這已完成 RFC-0113 提議再導入這項變更，已接受

摘要

這個 FTP 可為信封設計更精簡的編碼方式¹。

提振精神

信封是可擴充可擴充資料結構的基礎 (資料表和可延伸聯集)。更簡潔有效率的信封格式，可以可擴充的結構，以便在效能較高的情況下使用以及電線大小？

設計

建議的信封格式為：

圖：64 位元的位元組小字、MSB 32 位元大小、16 位元 handle_count、
已保留 16 位元

與現有的信封格式比較：

「大小」欄位則維持不變 (32 位元)。
- 大小包括可遞迴的子物件大小編碼。
- 舉例來說，vector<string> 的大小包含外部字串子物件
- 這與目前信封的現有行為相符大小欄位中的值
為保留 16 位元。
- 解碼器「必須」驗證保留的位元是否為零。
- 如果日後想要使用保留的位元，我們應該修改線格式。
  - 對於 FIDL 而言，保留的位元應更全面。以便在各種規格中保持一致的行為
  - 特別是，FIDL 在解碼器中並沒有先決忽略任何位元：定義及指定線路上的所有位元。
  - 這是最簡單的做法，要求使用線路格式。而非啟用前向相容性，以直到決定保留位元的政策決定為止。
handle_count 為 16 位元，而非 32 位元。
- 目前無法傳送 >超過 64 個控制架的 Zircon 管道；我覺得 16 位元可提供足夠空間，可以滿足未來的需求。
- handle_count 包含所有遞迴子物件的控制代碼數量。
系統會捨棄在家狀態/不存在欄位。
- 談吐與儀態會以非零的值， handle_count 欄位。
- 缺席是以大小和處理計數欄位的值都是零
  - 這就是所謂的零信封。
  - 零信封相當於 FIDL_ALLOC_ABSENT。
UINT32_MAX 的大小和 0 帳號代碼是特別的，代表信封內容，但大小為零。
- 如果空白結構體為零，保留這個參數供日後使用化為現實²，確保沒有任何成效否則就會面臨複雜程度的懲罰我們想立即提及這項資訊不會破壞線路格式。
- 我們可以改為竊取其中一個保留的位元。我們對於這並不是什麼意見，不過，如果在這些 Pod 中如何區分「現在而非大小」信封寄件者 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 可提供解碼器的機制，以儲存大小和在覆寫信封前處理計數資訊；本但 FTP 並不代表這類機制的運作原理。

執行策略

這個 FTP 是破壞線格式變更。

FIDL 同儕都必須瞭解新的信封格式，以及向同事新的格式因此，通常帳戶會視為硬性轉換。由於這個 FTP 並未加入任何新功能，如果我們決定將這項功能納入強制轉換效果，作者建議將這項變更歸為一組其他傳輸格式變更 (例如調整序數大小)。

儘管如此，緩和轉換作業仍有可行的。以下為兩種做法：

交易訊息中有 uint32 保留/旗標欄位標題。我們可以保留 1 位元供啟動的同儕表示，並分階段進行柔和轉換：
1. 確保所有客戶並伺服器就能瞭解新的傳輸格式。我們會繼續使用舊的線路格式。
2. 啟用新的電線格式，方法是在交易郵件標頭。如果雙方都已設定日期，雙方都可以改用新的線格式。
3. 柔性轉換效果涵蓋所有層後她可以使用新的電匯格式。我們可以移除交易郵件標頭中的位元。
4. 刪除舊線格式的程式碼，然後保留交易郵件標頭位元。
我們可以用特殊方式加上 FIDL 訊息類型和/或介面，「[WireFormat=EnvelopeV2]」屬性 (或類似屬性)，表示訊息/介面應使用新的傳輸格式。
1. 使用 WireFormat 屬性裝飾介面時，似乎配合線段變更，應該就能比較容易對結構體執行 WireFormat 變更，因為結構可能是不同介面中使用的函式，而繫結需要額外的邏輯才能決定使用結構體的結構定義。
2. 我們建議介面 [WireFormat] 屬性會影響介面方法引數的傳輸格式，不含以遞迴方式影響引數的結構
3. 即可啟用部分遷移程序，並選擇採用新的電匯格式。讓團隊按照自己的步調學習
4. 當所有結構體和介面都擁有 [WireFormat] 屬性時，可能放置舊線格式，以假設所有結構體和介面會使用新的傳輸格式，而忽略這個屬性

這兩種軟體轉換方法都需要大量的開發時間以及容許錯誤透過實作程式碼來正確執行任一方法、在計畫上執行，完成後續操作，移除舊程式碼並不容易。

我們可能編寫出程式碼來處理舊版和新的電匯格式廣告資源否則就無法逐步降落我們導入新線格式支援的時，請使用 CL。有鑑於處理這兩種傳輸格式的程式碼經常存在，因此我們建議使用上述任一個 softM 指令，設計出可以進行柔性轉換的原型轉換策略。這類原型設計過程也可能有助於制定一般的成功策略日後可能還會變更線路格式變更，但這可能很重要。如果不是，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 會提供建議，但我們依然會主動尋求意見與在以下決策方面取得共識：

我們應該考慮進行軟性轉換或硬轉換？詳情請參閱實踐策略專區：專業與共 30,000 個
我們建議使用 32 位元的尺寸、16 位元來處理和預留大小 16 位元。
- 32 位元的尺寸是否合理？
- 16 位元的帳號代碼是否合理？
rfc-0026，此提案衍生自提議的內嵌資料對於 32 位元的型別直接加入信封中
- 由於新增這個提案後增加導入作業的複雜度，並帶來邊際效益除非有大量欄位可以內嵌
- 目前尚無階段進展，希望有更多可選性的做法所有資訊 (例如將選填欄位分組選用的結構這類工作可能會淘汰內嵌能帶來的任何好處。

既有藝術品和參考資料

這個 FTP 是 rfc-0026 的簡化版本，自該版本起已遭拒整個 FTP 的共識不足

提案。內嵌、任何地方的信封，以及移動字串/向量數量已全部移除。

這個 FTP 以 rfc-0026 為基礎，但「只」包含外部信封↩
請注意，今天的空白 (零欄位) 結構體會在傳輸中佔用一個位元組。 ↩