| RFC-0099：導入 `zx_socket_set_disposition` | |
|---|---|
| 狀態 | 已接受 |
| 領域 |
|
| 說明 | 引入 `zx_socket_set_disposition`，以復原作業取代 `zx_socket_Shut`。 |
| 問題 | |
| 毛皮變化 | |
| 作者 | |
| 審查人員 | |
| 提交日期 (年-月-日) | 2021-05-06 |
| 審查日期 (年-月-日) | 2021-06-03 |
摘要
導入 zx_socket_set_disposition 以取代 zx_socket_shutdown。而
syscall 藉由允許反轉關機作業來延伸舊資料。
導入 ZX_RIGHT_MANAGE_SOCKET，並在新的 syscall 中要求此項目。新上榜
透過 zx_socket_create 建立的帳號代碼會顯示這項權利。
提振精神
透過可復原作業取代關機的動機
我們準備了精密的 Fdio 狀態機器 未連線的串流網路通訊端不得接受寫入。狀態機器 具有本機狀態，難以傳播至其他伺服器中重複的通訊端 程序和遠端狀態 (Zircon 通訊端上的使用者信號) 輸出本機狀態這些體操是必要的 建立「開放」，因此必須防止透過外部 代表與「已連線」(也能透過外部方式)。
要求新正確內容的動力
Zircon 通訊端這次關閉已太寬鬆。自 Zircon 插座 帳號代碼可複製 (實際上) 是複製 權限可以變更所有帳號代碼的通訊端狀態。此問題已經發生 更加嚴重。
完整的實作範例
以反向操作取代通訊端關閉，同時禁止 啟動它並允許實施網路堆疊實作的無特殊權限控制代碼 才能完全驅動通訊端狀態
通訊端一開始可以關閉，再對用戶端執行，移除 不需要在 fdio 中提到的狀態追蹤
通訊端關閉可由用戶端啟動的網路堆疊完全中介 FIDL 呼叫，消除現今存在的競爭狀況 (例如 https://fxbug.dev/42140031).
設計
在 FIDL 中定義 ZX_RIGHT_MANAGE_SOCKET：
延長 bits rights：
library zx;
bits rights : uint32 {
MANAGE_SOCKET = 0x00100000;
};
在 rights.md 中記錄 ZX_RIGHT_MANAGE_SOCKET：
附加至資料表：
| 右 | 推論的權限 |
|---|---|
| ZX_RIGHT_MANAGE_SOCKET | 允許透過 zx_socket_set_disposition 變更通訊端處理方法 |
在 FIDL 中定義 zx_socket_set_disposition
新增至 protocol socket：
library zx;
protocol socket {
/// Set disposition of writes.
socket_set_disposition(handle:<SOCKET, rights.MANAGE_SOCKET> handle, uint32 disposition, uint32 disposition_peer) -> (status status);
}
「/reference/syscalls/socket_set_disposition.md」中的文件 zx_socket_set_disposition
說明
zx_socket_set_disposition 會設定
zx_socket_write 會呼叫通訊端控制代碼及其對等點。
可使用的有效處理標幟：
ZX_SOCKET_DISPOSITION_WRITE_DISABLED - 停用指定的寫入功能 通訊端端點設定完成後，寫入指定通訊端端點的作業就會失敗 與 ZX_ERR_BAD_STATE。從指定的通訊端端點讀取資料 成功直到用盡指定通訊端端點中緩衝的所有資料。 之後因 ZX_ERR_BAD_STATE 失敗。
ZX_SOCKET_DISPOSITION_WRITE_ENABLED - 啟用指定的寫入功能
通訊端端點設定完成後，即可從指定的通訊端寫入及讀取資料
端點的行為會與 zx_socket_write 中指定的值相同
zx_socket_read。
無法在通訊端指定 ZX_SOCKET_DISPOSITION_WRITE_ENABLED
含有緩衝資料的端點這麼做
zx_socket_set_disposition 會傳回 ZX_ERR_BAD_STATE，且沒有任何動作
。
無法同時指定 ZX_SOCKET_DISPOSITION_WRITE_DISABLED 和
disposition 或 disposition_peer 中的 ZX_SOCKET_DISPOSITION_WRITE_ENABLED；
這樣會導致 zx_socket_set_disposition
ZX_ERR_INVALID_ARGS，且不採取任何動作。
報酬率
zx_socket_set_disposition() 會在成功時傳回 ZX_OK。
錯誤
ZX_ERR_BAD_HANDLE 帳號代碼不是有效的帳號代碼。
ZX_ERR_BAD_STATE disposition 或 disposition_peer 則包含 ZX_SOCKET_DISPOSITION_WRITE_ENABLED 和 handle 是指通訊端 特定通訊端端點的緩衝資料
ZX_ERR_WRONG_TYPE 處理常式不是通訊端控制代碼。
ZX_ERR_ACCESS_DENIED 帳號代碼沒有 ZX_ERR_ACCESS_DENIED。
ZX_ERR_INVALID_ARGS disposition 或 disposition_peer 包含標記 或標記的組合無效
遷移
實作完畢後，zx_socket_shutdown 的現有用法會替換為
呼叫 zx_socket_set_disposition 的對等呼叫。在必要的 ABI 轉換後
完成，zx_socket_shutdown 和相關選項將遭到移除。
實作
應在通訊端調度器內完全實作。
成效
這項異動對成效沒有實質影響。
人體工學
這項異動對人體工學沒有實質影響。
回溯相容性
此變更可回溯相容，因為未使用新的 API 的用戶端 都不受影響
安全性考量
這項變更可簡化 Fdio 程式碼，進而提升安全性。這個 否則不會對安全性產生實質影響。
隱私權注意事項
這項異動對隱私權沒有任何實質影響。
測試
系統將使用 Syscall 的單元測試來測試此功能，並藉由取代 並確保使用新機器的 Fdio 狀態機器
說明文件
zx_socket_write和zx_socket_read將設為
已更新為參照 zx_socket_set_disposition，而非
zx_socket_shutdown。
其他說明文件將按照實作一節的說明更新。
缺點、替代方案和未知
您可將新標記新增至 zx_socket_shutdown，而非新的 syscall，
因此可反轉行為這麼做的好處是
加入新的字詞 (討論) 並不是那麼好的
行為繼續使用 zx_socket_shutdown 的主要缺點是
接受的標記並不直覺ZX_SOCKET_SHUTDOWN_READ 不會
會處理容器上所說的內容 (不允許對等寫入，而不允許)
讀取)。
「取消關機」的行為如果有資料，會指定為產生錯誤 在通訊端中指定的方向。您也可以選擇允許 作業才能成功執行而是會選取較嚴格的選項 以及防止非預期的結果
您可使用現有的資產，不必建立新的權利。問卷調查： 現有權利表明，現有權利皆不符合此用途 確認是否屬於此情況
單靠這項設計無法完全解決串流的狀態傳播問題 通訊端。取代此提案是更全面的方法 試圖徹底消除 fdio 串流通訊端狀態機器。如此 提案也一定會包含此提案
既有藝術品和參考資料
串流通訊端語意已完全由其在其他 Pod 中的行為定義 並區分連線通訊端和作業系統 可能發生未連線的情況