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

RFC-0138：處理未知互動

RFC-0138：處理不明互動
狀態	已接受
領域	FIDL
說明	我們擴大 FIDL 語意，讓對等互連能處理不明互動。
毛皮變化	534921
作者	pascallouis@google.com
審查人員	abarth@google.com ianloic@google.com yifeit@google.com
提交日期 (年-月-日)	2021-05-25
審查日期 (年-月-日)	2021-10-27

編輯此 RFC

編輯 RFC 中繼資料

摘要

我們擴大 FIDL 語意，讓對等體能處理不明互動，例如或接收未知的方法呼叫。為達成此目標：

為 FIDL 推出彈性的互動方式和嚴格的互動方式 語言。即使未知，也能靈活地與彼此互動是由對等互連服務處理嚴格互動會導致意外終止。
我們引入三種通訊協定作業模式。封閉的通訊協定是絕不會允許不明互動的情境相反地，使用開放式通訊協定 允許任何形式不明的互動最後， ajar 通訊協定僅支援一種不明方式的互動。

一窺 FIDL 的演化支援情形

深入探討此提案前，建議您先瞭解 FIDL 如何因應不斷演進的疑慮。

這個問題有兩個面向：來源相容性 (API) 和二進位檔相容性 (ABI)。

API 相容性旨在確保針對編寫的使用者程式碼在變更之前產生的程式碼，仍可根據系統產生的程式碼變更。舉例來說，使用者可以合理預期至 FIDL 程式庫 (例如定義新的 type MyNewTable = table {};) 不含會導致使用這個程式庫的現有程式碼無法編譯。

以下提供三種解決來源相容性問題的方法：

盡可能讓多個變更來源相容 (例如 RFC-0057：預設) 沒有帳號代碼)；
提供明確的保證 (例如 RFC-0024：必要來源) 相容性)；
提供版本管理 (例如 RFC-0083: FIDL 版本管理)。

此外，ABI 相容性的用途是為建構的程式提供互通性。比較與程式庫不同版本的差異舉例來說，兩個程式對資料表結構定義的不同理解，但仍能成功可讓您快速輕鬆地進行通訊

達成 ABI 相容性可分為三個部分：

靜態相容性的考量重點，在於能否達成資料的互通性例如，何時可以兩個使用相同資料表結構定義的兩個對等互連可以互通？
動態相容性假設所有資料類型都相容，且重點是開發人員擁有不同版本的通訊協定 (例如不同的方法)；
最後，偏離通訊協定的某些情況以及解決方法，就是瞭解再調整通訊方式 (也就是不同的文字

動態相容性特別適用於「局部彈性」為像是在大部分不變的情況下作業。在其他情況下，例如以網域 fuchsia.io2 表示 fuchsia.io1 必須調整模型「全球彈性」即為「通訊協定協議」類別中

我們在本 RFC 中特別探討的機制 (嚴格和彈性) 互動) 提升動態相容性世界的現況 (2)。

術語

提醒您，通訊協定。

兩個同業之間的通訊稱為「互動」。互動開始要求，並可能視需要回應。

要求和回應都是交易郵件，以標頭表示 (「交易標頭」) 後面，選擇性加上酬載。¹

系統會導向互動，並將兩個對等的「client」和「server」命名為。用戶端對伺服器的互動會在用戶端傳送至伺服器，如果反向存在回應 (如果有的話) 往上移動即可同樣的，我們介紹的是伺服器對用戶端的互動。

我們常常使用「射後不理」或「一種方式」作為無回應的用語用戶端發起的互動，以及「呼叫」或「兩種方法」等字詞，需要回應的互動 (一律在目前模型中啟動)。當伺服器啟動無回應互動的對等互連時，通常稱為事件²。

「通訊協定」是指一組互動。我們將工作階段定義為例如用戶端與伺服器之間通訊的通訊協定，也就是用戶端與伺服器之間的一系列互動。

發生應用程式錯誤時，會遵循錯誤語法。A 罩杯 transport error 是因核心錯誤 (例如寫入已關閉的管道)，或 FIDL 發生錯誤。

提振精神

Fuchsia 的核心原則是 updatable：套件經過特別設計會彼此獨立更新即使是的驅動程式也是二進位穩定版，確保裝置順暢更新至新版 Fuchsia 版本讓他們持續吸引現有司機上門FIDL 扮演核心角色讓整體團隊能夠輕鬆更新檔案是專門設計用來定義應用程式二進位檔介面 (ABI)，因此可為前瞻相容性和回溯相容性提供堅實基礎。

具體來說，我們要允許瞭解稍有不同理解的兩個同業以便安全地互通更棒的是，我們要強烈的靜態保證「compatible」

為確保編碼的彈性和保證，執行了許多工作以及解碼 FIDL 類型，這兩種類型稱為靜態相容性。我們在 2008 年 table 版面配置、union 版面配置，選擇明確 union 中等標準，導入了 strict 和 flexible版面配置修飾符，導入protocol序式雜湊降低 protocol 序的衝突機率雜湊化，並改進郵件標頭格式來證明未來趨勢

我們現在改用動態彈性和保證，也就是「動態」相容性。假設兩個對等互連項目都相容，亦即所有型別動態相容性讓這兩個對等互連項目成功互通，同時另外一個對等互連也因為非預期的互動而取消通訊。

設計

我們引進了彈性互動和嚴格互動的概念互動情形。很快地，就算不知道有不明分也一樣都是由對等互連人員妥善處理相反地，如果接收端不明導致該節點突然終止會很有幫助我們稱為互動的「嚴格程度」，指稱互動是否該是一種靈活或嚴格的互動。請參閱彈性與嚴格內容的語意互動情形。

如果不設定防護機制，就可能不小心以靈活的方式運用互動功能危害隱私權的行為：

比方說，算繪引擎的設計必須不斷演進。新的版本新增 flexible SetAlphaBlending(...); 與改用以舊版轉譯器為指定目標的新用戶端設定即可 (但大部分顯示仍然會繼續運作)。現在是關於一種特殊 PII 顯示模式 StartPIIRendering(); 版本較舊的轉譯器必須停止處理系統會忽略這則訊息，因此適合使用 strict 互動。
另一個例子是惡意對等點傳送各種訊息來查看瞭解一般來說，反思功能會帶來額外的效能。並有助於解決隱私權問題 ( 才能達成目標。根據原則，FIDL 會選擇禁止或需要使用者明確選擇加入。

因此，我們另外推出三種模式營運：

封閉式通訊協定是指不允許彈性互動的情況；表示他們經常收到彈性互動。
開放式通訊協定是指允許任何彈性互動的地方 (例如單向或雙向)。這類通訊協定具有最大的彈性。
ajar 通訊協定是允許彈性的單向互動模式 (消防的來電和事件)，但更有彈性的雙向互動功能已允許 (如果對等點不知道這件事，就無法發出方法呼叫方法)。

詳情請參閱「通訊協定語意」。

嚴格且彈性互動的語意

嚴格互動的語意相當簡單：當收到未知的要求，例如接收者未知的要求、對等互連突然終止工作階段 (透過關閉管道)。

彈性互動的目標，在於讓收件者能優雅地處理郵件未知的互動這麼做會對設計方向產生一些影響。

彈性互動的傳送者必須知道自己的請求可能會被忽略 (因為不被接收者理解)。

接收方必須能夠分辨這項要求彈性 (而非 ])，並據此採取行動

因為雙向互動需要收件者回覆寄件者，所以對接收不明請求的接收者而言，才能建構則傳回空值接收者必須傳達給寄件者表示系統無法理解該要求為符合這項規定是靈活的雙向互動，就是結果聯集 (請參閱 details)。

其符合以下語意：傳送者無法判斷接收方的要求是已知或未知。採用靈活的單方法互動時，FIDL 作者應謹慎以對其整體通訊協定的語意

值得注意的是，單向互動並不算是「盡力」。傳送者無法判斷同儕是否已經收到互動。然而，管道能提供排序保證，將具有確定性且已知互動透過嚴格的單向互動方式確保部分互動發生在彼此互動的情形例如，記錄通訊協定可能有「StartPii()」和「StopPii()」的嚴格互動可確保沒有對等互連可以忽略這些建議。

進一步討論如何在選擇嚴格且彈性的互動方式，另請參閱：

效能注意事項
安全性考量

開放、封閉和 ajar 通訊協定的語意

closed 通訊協定的語意有一些侷限性，僅支援嚴格的互動，也沒有彈性的互動方式這是 closed 通訊協定的編譯時間錯誤。有任何 flexible 互動。

ajar 通訊協定的語意允許嚴格的互動，以及一種方式靈活互動這是 ajar 通訊協定的編譯時間錯誤。任何 flexible 互動方式。

open 通訊協定沒有嚴格限制、彈性、一種方式和可讓您以兩種方式互動

進一步討論如何在選擇封閉式、ajar 或開放式通訊協定，另請參閱：

效能注意事項
安全性考量

變更語言

我們推出修飾符 strict 和 flexible，可將互動標示為嚴格或彈性


protocol Example {
    strict Shutdown();
    flexible Update(value int32) -> () error UpdateError;
    flexible -> OnShutdown(...);
};

根據預設，互動是彈性的。

使用格式指南時，建議您一律明確指出嚴格程度互動，也就是應為每個互動進行設定³。

我們推出修飾符 closed、ajar 和 open 來標記通訊協定封閉式、ajar (部分開啟) 或開放：


closed protocol OnlyStrictInteractions { ...
ajar protocol StrictAndOneWayFlexibleInteractions { ...
open protocol AnyInteractions { ...

在封閉式通訊協定中，無法定義任何彈性互動。已結案通訊協定只能組合其他封閉通訊協定。

在 ajar 通訊協定中，無法定義兩種彈性互動的方式。一個 ajar 通訊協定只能組合封閉式或 ajar 通訊協定。

(開放式通訊協定沒有任何限制)。

根據預設，通訊協定為公開狀態。

此提案的先前版本將 ajar 指定為預設值。不過，會導致 Openness 修飾符的預設值、ajar 或與不含明確修飾符的雙向方法宣告情形。這表示若通訊協定包含兩種方法，將無法在沒有修飾符的情況下進行編譯至少為通訊協定或方法擇一使用如下所示：預設值會以粗體顯示，而嚴格度的預設值會顯示在斜體。

視覺化：顯示開啟/ajar/封閉編譯組合的格線
同時
嚴格/彈性

為解決這個問題，我們將開放性的預設值從 ajar 改為開啟，可讓通訊協定以不使用修飾符的方式，通訊協定或方法

格式指南時，建議您一律明確指出模式一個通訊協定，也就是每個通訊協定都應設定它。[^default-debate]

傳輸格式變更：交易郵件標頭旗標

我們會修改交易郵件標頭設為：

交易 ID (uint32)
靜態標記 (array<uint8>:2，即 2 個位元組)
動態旗標 (uint8)
魔術數字 (uint8)
序數 (uint64)

例如，旗標位元組會分成兩部分，其餘標記是兩個位元組動態屬性會標記一位元組

動態標記位元組的結構如下：

位元 7，第一個 MSB「嚴格度位元」：嚴格方法 0，彈性方法 1。
位元 6 至 0，未使用，設為 0。

以下是「動態標記」使用方式的詳細說明：

我們在第三版交易郵件中新增了旗標標題。這些標記目的是為了「暫時用於低度幹擾」遷移。」例如在「嚴格」與「可延伸」階段中，使用一個位元聯集遷移。然而，目前沒有任何計畫因此需要一次使用這些標記這些標記的用意在於作為傳輸格式的一部分
傳送方需要嚴格程度位元向接收端 strict 互動 (在接收器不知道該互動的情況下) 互動。本案例的語意突然終止服務如果沒有這個嚴格度，傳送方之間的偏差而且接收者可能聽不到聲音以一個罐子為例 (或公開) 通訊協定和新加入的 strict StopSomethingImportant(); 呼叫互動模式如果沒有嚴格設定位元，接收器就必須猜測這些不明互動是嚴格或彈性的考量到本 RFC 希望達到的演進能力改善成果。因此當系統判定 FIDL 作者時，就會強制採用兩種嚴格互動方式持續擴充通訊協定

另請參閱在交易中插入嚴格程度位元 ID：替代表示法，以及互動模式位元代表替代表示法的未來可能需要來電

線路格式變更：結果聯集

結果聯集，目前有兩個變化版本 (通常是成功的 1) 回應，或錯誤回應的序 2) 擴展為使用第三個變化版本。序數 3，其中將採用新的列舉 fidl.TransportError，指出 "傳輸等級"發生錯誤。

以下為互動範例：

open protocol AreYouHere {
    flexible Ping() -> (struct { pong Pong; }) error uint32;
};

含有回應酬載：

type result = union {
    1: response struct { pong Pong; };
    2: err uint32;
    3: transport_err fidl.TransportError;
};

具體來說，如果彈性方法使用 error 語法的成功類型，錯誤類型會予以設定 (分別為一般 1 和 2)。否則，如果彈性方法不會使用 error 語法，也就是結果中的錯誤變化版本聯集 (通常 2) 會標示為 reserved。⁴

部分精確度：⁵

從應用程式的角度來看，我們選擇了 transport_err 這個名字。錯誤的來源應明確區別我們提供應用程式錯誤和「傳輸錯誤」也就是 FIDL 造成的錯誤編碼/解碼、FIDL 通訊協定錯誤、核心錯誤等「傳輸錯誤」是所有可能發生的錯誤這個架構 (包括多層軟體)
我們將 fidl.TransportErr 類型定義為嚴格的 int32 列舉，並加上單一子類 UNKNOWN_METHOD。此變數的值與 ZX_ERR_NOT_SUPPORTED；等於 -2：
```
type TransportErr = strict enum : int32 {
  UNKNOWN_METHOD = -2;
};
```
向用戶端顯示傳輸錯誤時，如果繫結可提供取得不明互動 transport_err (繫結) 的 zx.status 必須使用 ZX_ERR_NOT_SUPPORTED。不過，您不必繫結對應的不明互動 transport_err 到 zx.status 如何向客戶呈現錯誤

另一種做法是只使用 zx.status，並且一律使用 ZX_ERR_NOT_SUPPORTED 做為值表示不明方法，但此有兩個重大缺點
- 這需要程式庫 zx 的依附元件，但該程式庫可能無法直接使用大量程式庫這樣會較難在 IR，因為我們需要自動在 zx 上插入依附元件，或將在 IR 中輸入 int32，但產生的繫結會將其視為 zx.status。
- 不會定義繫結應如何處理 transport_err 值，不是 ZX_ERR_NOT_SUPPORTED。透過指定這種類型列舉，我們會針對收到無法辨識的 transport_err 值；即會視為或解碼錯誤
我們會參照「結果聯集」簡單易懂說明共用相同結構的聯集型別，例如三個序數，第一個變體不受限制 (成功類型可以是任何內容)，第二個變數必須是 int32、uint32 或其中的列舉，而第三個變數則是變數必須是 fidl.transport_err。

JSON IR 異動

我們在 JSON IR 中公開了互動的嚴格程度。實務上， #/definitions/interface-method 類型，然後將 strict 布林值新增為 ordinal、name、is_composed 等的同級資源。

我們在 JSON IR 中公開通訊協定模式。實務上，我們更新了 #/definitions/interface 類型，並新增含有 closed 成員的 mode 列舉， ajar 和 open 可做為 composed_protocols、methods 等的同層使用者。

繫結異動

我們希望讓 Google 能自動處理要求。舉例來說，繫結可以自動建構要求來指出要求為未知，這項做法很重要兩個要求都會提出接收到未知要求 (可能是因為，並可選擇以「要求未知」來回應或突然終止通訊。

隨時可能有疑慮

如果是彈性互動，繫結應呈現透過相同方式將結果聯集的 transport_err 變體傳送到用戶端顯示其他傳輸層級錯誤 (例如錯誤) 的機制 zx_channel_write 或解碼期間發生錯誤。《err》和《response》結果聯集的變化版本應以相同方式呈現給用戶端如果方法宣告為所以必須採用嚴謹的做法
- 舉例來說，在 Rust 繫結中，Result<T, fidl::Error> 的用途為會在呼叫中顯示其他傳輸層級錯誤，因此 transport_err 應該已摺疊成 fidl::Error。同樣地，在低階 C++ 繫結中 fit::result<fidl::Error> 是用來表示傳輸層級錯誤，因此 transport_err 應合併為 fidl::Error。response和 err 變體的表示方式與嚴格方法相同。於將 Result<Result<T, ApplicationError>, fidl::Error> 代表的 Rust 帶有錯誤語法的方法；如果不使用，則傳回 Result<T, fidl::Error> 錯誤語法，其中的 response 值為 T，err 值則是 ApplicationError。
- 如果是將錯誤折疊成 zx.status 的繫結，transport_err 值必須將 UNKNOWN_METHOD 轉換為 ZX_ERR_NOT_SUPPORTED。

有動態疑慮：

使用 zx_channel_write、zx_channel_call 或而動態標記的設定方式如下：
- 如要進行嚴格互動，將嚴格度位元 (bit 7) 必須設為 0，且必須設為 1 表示富有彈性的互動方式
- 接下來的 6 位元必須設為 0。
收到已知互動時：
- 繫結的運作方式目前不變。
- 具體來說，繫結不應驗證嚴格程度來或從嚴格互動改為彈性互動 (反之亦然)。
收到不明互動時 (例如未知的序數)：
- 如果互動非常嚴格 (如獲得嚴格限制標記所示)：
- 繫結必須關閉通訊 (即關閉管道)。
- 如果互動具有彈性 (如收到的嚴格度標記所示)：
- 針對封閉的通訊協定，繫結必須關閉管道。
- 如果互動為單向 (交易 ID 為零)：
  - 繫結必須向應用程式引發這個未知互動 (詳細資料 )。
- 如果互動方式有兩種 (交易 ID 不是零)：
  - 如為 ajar 通訊協定，繫結必須關閉管道。
  - 針對開放式通訊協定，繫結必須將這項未知互動提高給應用程式 (請見下方說明)
- 進一步瞭解如何引發不明互動：
  - 如果互動是兩種方式，繫結必須透過傳送結果聯集，同時選取第三個變化版本第 fidl.TransportErr 個，共 UNKNOWN_METHOD 個。這項操作必須在則會引發不明互動。
  - 繫結應向應用程式引發未知的互動，叫用之前註冊的處理常式 (或類似名稱)。
  - 建議對繫結使用要求註冊未知互動處理常式，避免在「預設行為」中建構可可能遭誤解繫結可提供「免人工管理處理常式」或類似，但建議明確使用
  - 繫結「可」選擇為應用程式提供關閉處理不明互動的狀況

如果不明訊息包含控制代碼，伺服器就必須關閉系統傳送的訊息要求。伺服器必須關閉收到訊息中的所有控制代碼變更前：

關閉管道時，如果採用嚴格方法，隨機性參數封閉式通訊協定，或 ajar 通訊協定的彈性雙向方法
回覆訊息 (如果在開啟的情況下有彈性的雙向方式) 通訊協定
通知未知方法呼叫的使用者程式碼 (在採用彈性參數的情況下) 使用開放式或 ajar 通訊協定的單向方法。

同樣地，當用戶端收到含有控點的不明事件時，用戶端必須關閉收到訊息中的控制代碼。用戶端必須全部關閉以下程式碼會發生這個問題：

關閉管道或封閉式通訊協定
在使用 Open 或 ajar 通訊協定

一般來說，在處理不明互動時，運算的順序如下所示。

關閉收到訊息中的控點。
如果適用，請關閉管道或傳送「UNKNOWN_METHOD」回覆。
將不明互動提升給未知互動處理常式或報表發生錯誤。

在非同步環境中，可能同時有多個執行緒嘗試收發訊息時，可能無法實際做法，在回報未知方法前確認管道已關閉錯誤。因此，在檢舉就會引發錯誤。不過中所述的可復原的未知互動，必須先關閉控點並回覆 (如適用)，再派出不明人員互動處理常式

這個 RFC 的舊版本未指定關閉控點之間的順序接收訊息、回應未知的雙向方法，以及回報不明與使用者之間的互動

相容性的影響

ABI 相容性

將互動從 strict 改為 flexible，或將互動從 flexible 變更為 strict 與 ABI 不相容

變更通訊協定模式 (例如從 closed 變更為 ajar) 並非 ABI 相容。雖然看似限制較嚴格的模式限制較少的模式可能與 ABI 相容，實際上並非同時定義傳送端與接收端的通訊協定 (啟動後清除) 和事件)。

所有變更都可以採用初步轉換。修飾符可以 versionned。

來源相容性

將互動從 strict 改為 flexible，或將互動從 flexible 變更為 strict 可能與原始碼相容建議繫結可以提供相同的 API 無論互動是否嚴格錯誤 API。

變更通訊協定模式 (例如從 closed 變更為 ajar) 不會來源相容。建議繫結以專供其提供的 API 使用會因通訊協定模式而異舉例來說，封閉式通訊協定並不需要以提供「未知的方法」處理常式，因此建議您不要提供這類這個處理常式就會使用，不再使用

與平台版本管理的關係

如「 RFC-0002，我們「變更 ABI 修訂版本」每次平台對語意回溯不相容的變更時 Fuchsia 系統介面。」

我們之所以能達成這項目標可更新目標是建立新的 ABI 修訂版本。由於彈性互動功能以回溯相容的方式運作這項功能有助於改善她們可以更新的是 Fuchsia 的可更新性，

實作

我們可以想像在一個世界上，繫結只會將這樣可確保通訊提早終止，就像對等互連發生其他錯誤或錯誤。
考量到 FIDL 的發展重要性，第一要務，這並不是理想情況因此需要繫結遵循這項規格。
為符合繫結規格，繫結「必須」實作更嚴格且彈性的互動語義，還有三種通訊協定
因此，我們將詳細說明繫結規格的異動。這是 ABI 破壞，也是線路格式的主要發展涵蓋「靜態」兩個部分和「動態」疑慮。

這個 RFC 的舊版本呼叫了用於限制不明狀態的推出作業產生新奇的數值不過，如先前所述由於標頭位元用於表示嚴格度先前未使用/保留，以及電線格式只會針對靈活的兩種方法變更，且只能採用通訊協定我們會採用兩階段推出策略，而非變更神奇數字表示我們支援不明互動，但設定了預設修飾符新增至 closed 和 strict，並將這些修飾符明確新增至現有的 FIDL 檔案，然後將預設值變更為 open 和 flexible。

效能注意事項

不會影響 closed 個通訊協定。進行封閉式通訊協定時，不需這麼做檢查嚴格度位元，如繫結一節。

對 ajar 和 open 通訊協定的影響較小：

處理不明互動的方式與處理已知互動類似系統會叫用預先註冊的處理常式，然後執行應用程式程式碼。
此外，如果是兩種未知互動 (只有 open) 這些通訊協定) 則是由繫結建構及傳送回應。

我們預期效能考慮因素極少需要，通訊協定模式和通訊協定模式的選擇，大部分都是以安全措施注意事項

人體工學

這讓 FIDL 變得更加複雜，但要解決相當重要的需求但這次的發展一直都相當驚人

回溯相容性

這項功能無法回溯相容，必須進行虛遷移。

安全性考量

新增向同類應用程式傳送不明要求的功能 (例如：彈性互動) 開啟了安全疑慮的大門。

針對特別敏感的通訊協定，演變問題可能缺乏嚴謹的互動，因此較傾向於使用 closed 通訊協定。應該有多數的內弓 Fuchsia 採用 closed 通訊協定 (例如 fuchsia.ldsvc)。

考慮 ajar 或 open 通訊協定時，有兩個問題 FIDL 作者需要考量的事項：

惡意對等點會以大量承載傳送未知的要求。(與會優先使用能處理大量工作負載的flexible型別未知酬載)。如大小中所述具有 ABI 影響的其他功能必須讓 FIDL 作者擁有控制權，並會在日後合作中解決。
打開通訊協定探查，瞭解同儕進行檢查都是在不知情的情況下實作，然後設法入侵找到的方法的訊息。如果實作會提供比預期更多的方法。例如，假設使用者打算會公開父項通訊協定，但會將子項通訊協定父項。請注意，受彈性互動無法改變攻擊媒介但攻擊者可能較容易遭人利用多個序數，而無須重新連線可能非常昂貴)。
在選擇 ajar 與 open 通訊協定之間取得平衡時請想想同儕無法判斷反之，如果是由系統處理或忽略，如果是兩種未知互動 (即 open 通訊協定允許)，處理對等互連揭露無法從而發掘出實用資訊發送給惡意人士

隱私權注意事項

開放通訊協定探查可能會導致隱私權疑慮。如先前所述「安全性考量」一節中，表示這類威脅不會因此 RFC 而變更，但攻擊者更容易被利用。

測試

在這個 RFC 中，開發全新功能集的關鍵在於確保所有繫結都遵循相同的規格，為此，您需要能夠以測試 (例如「傳送此要求，以正確的交易 ID 回覆，但有誤序數，預期傳送者管道關閉。」我們的經驗豐富專注於能流暢表達規格會導致測試增加。因此可以提高符合該規格的所有繫結法規遵循程度，提升迴歸防護機制

我們也會比照編碼和解碼作業的流程是在 GIDL 的開發階段：從寫作開始測試、盡可能多練習繫結，歸納出可以透過宣告式測試來測試的項目。雖然我們也希望打造出與 GIDL 類似的工具，且我們的努力朝目標邁進並可能改為選擇以手語撰寫的測試結果。

說明文件

我們會針對這項功能提供詳盡的說明文件。規格說明側：

FIDL API Rubric 中的其他項目將附加了通訊協定的演變

針對特定譯文語言使用這項功能，我們預期每次單一繫結來更新說明文件，並提供實際範例。

缺點、替代方案和未知

缺點：訊息大小上限因 ABI 影響而受到 ABI 的影響

處理不明問題的問題，像是目前已知的未知酬載與 flexible 類型或這裡所導入的不明互動互動時，對等點預期讀取的訊息大小上限為 ABI 的影響。沒有這項限制的明確說明而非靜態驗證

目前還沒有管道透過向量化讀取功能，也無法但會進行部分讀取如此一來，系統就能將郵件傳送給符合要求的同業所有需求 (例如靈活的互動方式，在預期同業時) 以及導致通訊失敗，因而破壞 ABI。如果相關訊息是空間過大，無法讀取訊息。 1KiB，超過此上限的新訊息一律不會讀取，與此同時，兩人之間的通訊即會取消。

隨著這項靈活互動的引進，提高這是因為 flexible 類型所致。

未來的發展方向包括：

以向量化的管道讀取，例如：接收者僅讀取郵件標頭再決定是否讀取郵件的其他部分酬載或捨棄該訊息 (也會需要新 syscall)。
將訊息的大小上限設為通訊協定的明確屬性。可能使用了預先定義的大小類別，例如 small、medium、large、或 unbounded。

替代做法：與指令模式比較

指令模式非常實用可讓用戶端批次處理伺服器處理的多項要求。這個執行指令模式來實現演變性用於 RFC 1919 的說明。

例如：

open protocol AnOpenProtocol {
    flexible FirstMethod(FirstMethodRequest) -> (FirstMethodResponse);
    flexible SecondMethod(SecondMethodRequest) -> (SecondMethodResponse);
};

使用下方封閉通訊協定即可約略值，即立即設定 FIDL 功能，如此才有能力同等程度的進化

closed protocol SimulateAnOpenProtocol {
    strict Call(Request) -> (Response);
};

type Request = flexible union {
    1: first FirstMethodRequest;
    2: second SecondMethodRequest;
    ...
};

type Response = flexible union {
    1: first FirstMethodResponse;
    2: second SecondMethodResponse;
    ...
    n: transport_err zx.status;
};

因此，指令模式方法並不理想。

由於我們必須將每個要求與聯集中的回應進行比對，執行「比對配對」的語法進而導致語法位置。

運作不穩的伺服器可能會以 SecondMethodResponse 回應 FirstMethodRequest，我們也失去類型安全。能爭論這種聰明絕頂繫結可能會留意到這個模式，也許是使用 @command 屬性，和我們現在為方法採用的人體工學。

在電線層級，命令模式會強制「兩種方法鑑別器」/ 排序交易郵件標頭中的序數 (識別 Call 是互動)，我們也有聯集序數 (識別選取聯集的變化版本，意即：1 為 FirstMethodRequest，2 代表 SecondMethodRequest)。

同樣地，如果所有方法都遵循指令模式例如「所有方法」因此不需要交易郵件標頭中的序數基本上，彈性通訊協定來「編譯至」使用指令。聯集的線格式需要計算位元組和控點，並需要透過符合規定的解碼器驗證這些計數。這是兩個前端的問題：

交易郵件標頭允許的嚴重性 (無說明有效酬載，如果可以，請解碼) 。這項彈性與簡便性適用於低階用途，亦即以 FIDL 輪播的平台。
組合模型沒有「通訊協定分組」的意義。這個是十分強大的功能，因為我們可以透過連結。我們會盡可能使用結構化組成 (例如 compose 條理分明，也能因應動態組成 (例如服務探索)。如果我們看到的視角是「全部編譯為聯集」我們採用的分組

最後，某些 FIDL 作者都希望「自動批次處理要求」舉例來說， fuchsia.ui.scenic 圖書館因地貌而聞名請在 fuchsia.ui.scenic/Session.Enqueue 方法中使用指令模式但是，提供了「自動批次處理要求」功能是危險功能因為如何處理在單一單位中處理多個指令的語意但在應用程式之間往往有很大的差異該如何處理未知的指令？要如何處理失敗的指令？指令應如下所示忽略、停止執行，導致取消並復原？即使是 RDBM 系統的設計是以「批次工作單元」的概念為主通常會發生提供多種批次處理模式 ([隔離模式) levels)(https://en.wikipedia.org/wiki/Isolation_(database_systems))).滿足壓力明白，FIDL 並沒有支援「自動批次處理要求」的計劃。

從根本上來看，在表面上則可能看起來很嚴格彈性互動與指令模式相同但提供不同的特殊語義

替代方法：通訊協定協商

什麼是通訊協定協商

通訊協定交涉是廣泛的術語，會說明適用於同業的技術組合互動來逐步建立彼此的情境因此能夠以更快、更快、更有效率的方式進行通訊。

例如，試想隨機撥打電話號碼。也許同業「所以，然後這麼說？」您從沒有與其他同業的背景資訊轉變成同業以及識別身分我們可以繼續「喔，依此類推。對嗎？」鑒於現今的行銷呼叫蓬勃發展，您現在很可能「這場通話的目的是什麼？你是誰？」依此類推。兩個對等互連項目你也不太能發現彼此的身分和能力

觀眾能理解哪些資料元素？舉例來說，如要向同業人員指出理想的資料表，請務必小心，以免對等點產生大量複雜資料，只有在收到時才需要忽略。
同業支援哪些方法？在算繪引擎中，您可以會詢問是否提供 Alpha 混合功能與轉譯器的互動 (可能透過傳送不同內容)。
該使用哪些效能特性？一般而言緩衝區空間，或是系統能對其發出呼叫的頻率 (假設配額)。

每種種類需要的解決方案略有不同基本上是轉換互動模型的抽象說明 (例如「也就是對等點能理解的一組方法」) 轉換成可以交換的資料。

如要順利解決通訊協定的協商問題，第一步是提供一種方法說明這些概念 (「通訊協定」、「方法 foo 的回應類型」)。且因為同業一開始使用缺乏情境的世界但他們不知道彼此有關，而且必須假設他們對這些概念的說明通常會依賴結構性質。例如，說出「回應類型為 MyCoolType」無意義，且會使但說「回覆類型為 struct { bool; }」持續且不須提供背景資訊

通訊協定協商與嚴格靈活互動之間的關係

這個 RFC 中，嚴格且彈性的互動方式提供了部分 Wiggle 房間您可以視需求移除方式多到幾個要求都行。可是，濫用相關能力的力量會提升是一種突如其來的通訊協定，且網域難以從形狀上理解這與長期下來都有欄位數量不一，因為現在這些欄位代表一種「匯總結構」是綜合考量多組需求而隨時改變的需求。

在合約通訊協定的協商中，如果妥善運用，就能... 減少版本管理負擔，並在一些動態選項 (協商) 之後採用更簡潔且嚴謹的通訊協定 (可能是 closed 通訊協定)。

兩種演化技術都有所及之處，而就是「演化」的工具箱

替代做法：在交易 ID 中加上嚴格度位元

使用交易 ID 傳達嚴格和彈性互動都有一項重要缺點部分交易 ID 都是由核心產生，因此 zx_channel_call 會將前四個以訊息位元組表示的交易 ID 為 zx_txid_t 類型。更多包裝將資訊傳入交易 ID 可強化耦合這並不適合透過改為標頭旗標，使用 zx_channel_call 的 FIDL 程式碼仍可繼續除了 ID 以外，也會使用標頭中的所有內容

替代做法：互動模式位元

這個 RFC 的較舊版本稱為新增「互動模式」比區分出兩種互動方式，且預計將擴大與較複雜的互動，例如終端機互動)。

如果互動模式位元與也就是交易識別碼中提供的資訊：一種互動方式零交易 ID，兩種互動方式屬於非零交易或 ID。因為資訊冗餘，讓我們擁有使用備援位元的不同子集來實作（如繫結）判斷訊息的處理方式這反過來讓惡意進出大門撰寫訊息，並以不同面向來解讀訊息有些人會將 Cloud Storage 視為檔案系統但實際上不是

雖然我們的目標是讓以及展開互動模式，需要進行這兩項變更我們更傾向於繪製這種設計再進行討論。

替代做法：命名

正因為 RFC 不斷改進，很多人針對如何正確命名新的概念在此總結一下部分討論內容。

為可能為「未知」的互動劃定明確點有些需要「已知」：

選擇了 open 和 closed 個原始名稱。
(none) 和 required 的方式必須是由對等互連人員實作方法。否則通訊協定就會終止
入圍者： flexible和strict借用 RFC-0033：處理欄位和嚴格程度。

如要區分一律無法接收不明互動的通訊協定，能夠接收一種未知互動方式的通訊協定，這些通訊協定來自以下通訊協定：可以同時接收兩種互動：

選擇了static、standard、dynamic 個原始名稱。有點缺點「static」和「動態」就是我們使用「靜態」一詞和「動態」請參閱 FIDL 的線路格式和傳訊層面。適用對象其中一部分的 RFC 所指的「動態疑慮」編碼器-解碼器架構「動態」的定義相較於「動態通訊協定」
strict、(none) 和 flexible 都是從 RFC-0033 借用。
使用 sealed 取代 static，強調通訊協定無法就可以輕鬆展開
使用 hybrid 或 mixed 取代 standard。
入圍者： closed、ajar和open。不使用開放式和封閉式因此可以放在通訊協定修飾符上 ajar 的定義則確實「部分開放」也就是也就是要描述的概念是的，都擔心自己有點詭異然後轉化成它

既有藝術品和參考資料

(如內文中所述)。

令人困惑的是，訊息而不是訊息) 是指 FIDL 的編碼形式值。↩
對於 fidlc 和 JSON IR 愛好者，請注意編譯器的內部人員會以 maybe_request_payload 的形式將事件表示等於 nullptr，maybe_response_payload 等於 present。從模型中移除但我們將此酬載稱為請求伺服器對用戶端的方向必須對齊組成模型變更 fidlc 和 JSON IR。這不在此 RFC 涵蓋範圍內，但需註記提供完整資訊↩
我們建議使用自由文法和風格指南執行 YAML 檔案同時，為了達到這個設計，我們要同時取得不僅能以更平易近人的方式吸引新觀眾，針對 Fuchsia 制定非常明確的 (及具體詳細) 標準平台。 ↩
值得注意的是，將 error 加入 flexible 互動可以做為軟體式 ABI 相容變更。↩
我們後來重新命名 transport_err 和 TransportErr 分別設為 framework_err 和 FrameworkErr詳情請見詳情請參閱 https://fxbug.dev/42061151。↩