| 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 编码字节的传输方式，例如 VMO、网络套接字和永久性存储空间。 允许某些类型（例如，通过属性）选择退出此约束条件可能很有用，即使这些类型永远无法通过 zircon 通道进行传输。
在对字节长度施加此限制之前，建议您考虑将其他机制（分页/流式传输等）整合到 FIDL 语言中。
早期技术和参考资料
未知