| RFC-0062：方法無法使用 | |
|---|---|
| 狀態 | 已遭拒 |
| 區域 |
|
| 說明 | 宣告介面方法時，如果可能需要的句柄或位元組數量超過 Zircon 管道訊息允許的數量上限，則應視為錯誤。 |
| 作者 | |
| 提交日期 (年-月-日) | 2018-07-19 |
| 審查日期 (年-月-日) | 2018-09-11 |
拒絕理由
這項 FTP 遭到拒絕，因為我們認為設下硬性限制過於嚴厲。types.h 檔案包含 ZX_CHANNEL_MAX_MSG_BYTES 和 ZX_CHANNEL_MAX_MSG_HANDLES 的定義，可供實作者檢查，並用於限制資源耗用量。
討論的可能方向是基於註解的限制 (目前我們有 [MaxHandles] 和 [MaxBytes] 屬性)。
在某些用途中，我們需要使用語言表達可能無界限的訊息 (大小或句柄)。通常，這類訊息會以動態方式組合，以符合底層傳輸的要求 (例如最佳化傳輸量，或配合舊版用戶端)。
摘要
宣告介面方法時，如果可能需要的句柄或位元組數量超過 Zircon 管道訊息允許的數量上限，則應視為錯誤。
您可以輕鬆宣告在單一 Zircon 管道訊息中無法傳送的 FIDL 類型。開發人員應避免定義可能導致非預期的執行階段錯誤的類型。
由於我們預期 FIDL 資料會使用其他傳輸方式，例如共用記憶體、持續性儲存空間和網路，因此限制是針對介面方法，而非類型。
提振精神
邊緣情況很難測試，也難以推論。在特殊情況下，如果無法傳送 FIDL 訊息，就可能會公開 FIDL 服務中未經測試的部分。可能會接觸到不受信任的程式碼。
舉例來說，在 fuchsia.sys 中，目前 FlatNamespace 可包含任意數量的句柄。LaunchInfo 可能包含 FlatNamespace。Launcher.CreateComponent() 的呼叫可能會遭到蓄意或意外的操控，導致呼叫成功，但當 appmgr 將提供的 LaunchInfo 傳遞至 Runner.StartComponent() 時，提供的其他句柄會阻止訊息成功編碼。
設計
這會修改 FIDL 編譯器，但不會修改 FIDL 語言、繫結或線路格式。
FIDL 前端編譯器現在會追蹤代表訊息所需的句柄和位元組數量。目前 Zircon 管道訊息最多只能包含 64 個句柄。如果定義的任何方法可能需要超過 64 個句柄才能編碼其要求或回應，編譯器應會列印錯誤並失敗。目前 Zircon 管道訊息最多只能包含 64k 位元組。如果定義的任何方法可能需要超過 64k 位元組才能編碼要求或回應，編譯器應會顯示錯誤並失敗。
有兩種主要模式會違反這項限制：含有句柄的遞迴型別，以及句柄的無限向量 (或含有這些向量的型別)。避免這些問題的方法相當簡單。
說明文件和範例
FIDL 文件應記錄這項限制條件，並確保所有範例皆有效。編譯器產生的錯誤訊息應清晰易懂且實用。
回溯相容性
這會破壞 FIDL 原始碼相容性。許多現有的介面 (例如上述的 FlatNamespace) 無法限制可能需要的句柄或位元組數量。這些介面必須加強。
成效
這應該不會對效能造成直接影響。如果某些介面和類型確實想要支援任意數量的句柄或位元組，但實際上從未運作，則可能需要變更。
安全性
這項異動可減少應用程式發生的意外行為，並減少未經測試的行為，進而提升安全性。
測試
fidlc 編譯器應取得一些新測試，確保其對句柄計數的計算結果正確無誤。
缺點、替代方案和未知事項
這可向 Fidl 介面作者公開 Zircon 管道 IPC 機制的其他詳細資料。這似乎是公平的取捨，因為目前使用這些介面的使用者都需要瞭解這些取捨。
我們可以要求所有字串和向量都具有明確的邊界。這會鼓勵介面作者設計可在 Zircon 管道中安全使用的類型，但可能會限制 FIDL 類型在其他媒體上的彈性。
雖然句柄的唯一傳輸方式是管道訊息，但也有其他傳輸方式可用於 FIDL 編碼位元組，例如 VMOs、網路通訊端和持續性儲存空間。即使某些類型無法透過 zircon 管道傳輸，還是可以允許這些類型選擇不採用此限制 (例如使用屬性)。
在對位元組長度施加這項限制之前，不妨考慮在 FIDL 語言中加入其他機制 (分頁 / 串流 / 等)。
既有技術與參考資料
不明