| 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,000 個位元組。編譯器應輸出錯誤，如果定義的任何方法都可能需要超過 64,000 個位元組來對要求或回應進行編碼，該方法就會失敗。
這類限制有兩種主要模式：遞迴類型包含控點和無界限向量 (或包含這些代碼的類型)。避免這些情況
說明文件與範例
FIDL 說明文件應記錄這項限制，並確保所有範例均有效。編譯器產生的錯誤訊息應清楚明確，且實用。
回溯相容性
這會破壞 FIDL 來源相容性。許多現有介面 (例如上述的 FlatNamespace) 無法限制可能需要的控制代碼或位元組數。這些介面都必須強化。
效能
成效應該不會直接受到影響。 如果介面和類型確實想支援任意數量的控點或位元組，您可能必須變更某些介面和類型，但這些介面和類型永遠無法發揮作用。
安全性
這項變更可減少應用程式將遇到非預期且未經測試的行為，進而提升安全性。
測試
fidlc 編譯器應進行一些新的測試，確保其計算次數正確無誤。
缺點、替代方案和未知
這會向 FIDL 介面作者公開 Zircon 管道處理序間通訊 (IPC) 機制的一些其他詳細資料。看來存在這項缺點，因為目前使用這些介面的人都必須瞭解這些取捨。
我們可以要求所有字串和向量都必須有明確的邊界。這可鼓勵介面作者設計可以安全地在 Zircon 管道中使用，但可能會限制其他媒體 FIDL 類型的彈性。
雖然控制代碼的唯一傳輸方式是管道訊息，但還有其他 FIDL 編碼位元組傳輸方式，例如 VMO、網路通訊端和永久儲存空間。雖然某些類型無法透過 Zircon 管道傳送，但允許某些類型選擇不採用這項限制 (例如具有屬性) 可能很有幫助。
因此，建議您先將其他機制整合到 FIDL 語言 (分頁/串流等) 中，再針對位元組長度強制執行此限制。
先前的圖片和參考資料
不明