| 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 管道訊息最多只能包含 64 KB。 如果定義的任何方法可能需要超過 64 KB 的位元組來編碼要求或回應，編譯器應會列印錯誤並失敗。
有兩種主要模式會違反這項限制：具有控制碼的遞迴型別，以及控制碼的不受限向量 (或包含這些項目的型別)。避免這些情況相當簡單。
說明文件和範例
FIDL 文件應記錄這項限制，並確保所有範例都有效。編譯器產生的錯誤訊息應清楚實用。
回溯相容性
這會破壞 FIDL 來源相容性。許多現有介面 (例如上述的 FlatNamespace) 無法限制可能需要的控制代碼或位元組數量。這些介面必須嚴格把關。
效能
這項異動不會直接影響成效。 如果真的想支援任意數量的控制代碼或位元組，但無論如何都不會運作，可能需要變更某些介面和型別。
安全性
這項變更可減少應用程式中未經測試的意外行為，進而提升安全性。
測試
fidlc 編譯器應進行一些新測試，確保控制代碼計數的計算結果正確無誤。
缺點、替代方案和未知事項
這會向 FIDL 介面作者公開 Zircon 管道 IPC 機制的其他詳細資料。目前使用這些介面的使用者必須瞭解這些取捨，因此這似乎是合理的取捨。
我們可能會要求所有字串和向量都必須有明確的界限。這會鼓勵介面作者設計可在 Zircon 通道安全使用的型別，但可能會限制其他媒體的 FIDL 型別彈性。
雖然控制代碼的唯一傳輸方式是管道訊息，但 FIDL 編碼位元組還有其他傳輸方式，例如 VMO、網路插座和永久儲存空間。即使某些型別永遠無法透過 Zircon 管道傳輸，允許這些型別退出這項限制 (例如使用屬性) 可能還是很有用。
在對位元組長度施加這項限制之前，或許可以考慮將其他機制併入 FIDL 語言 (分頁 / 串流 / 等)。
既有技術和參考資料
不明