| 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 的数据。 如果定义了任何可能需要超过 64k 字节来编码其请求或响应的方法，编译器应打印错误并失败。
有两类主要模式违反了此限制：具有句柄的递归类型和无界句柄向量（或包含它们的类型）。 避免这些问题的方法相当简单。
文档和示例
FIDL 文档应记录此限制，并确保所有示例均有效。 编译器生成的错误消息应清晰且实用。
向后兼容性
这会破坏 FIDL 源兼容性。
许多现有接口（例如上述 FlatNamespace）无法限制可能需要的句柄数或字节数。这些接口必须收紧。
性能
不应有直接的性能影响。 如果确实要支持任意数量的句柄或字节，可能需要更改某些接口和类型，但无论如何，这些接口和类型都无法正常运行。
安全
此变更可减少应用将遇到的意外的、未经充分测试的行为，从而提高安全性。
测试
fidlc 编译器应获得一些新测试，以确保其句柄数计算正确无误。
缺点、替代方案和未知因素
这会向 FIDL 接口作者公开 Zircon 渠道 IPC 机制的一些其他详细信息。 这似乎是一个合理的权衡，因为目前使用这些接口的任何人都需要了解这些权衡。
我们可以要求所有字符串和向量都具有明确的边界。 这会促使接口作者设计可在 Zircon 渠道中安全使用的类型，但可能会限制 FIDL 类型在其他媒体中的灵活性。
虽然句柄的唯一传输方式是频道消息，但 FIDL 编码字节还有其他传输方式，例如 VMO、网络套接字和持久性存储。 即使某些类型永远无法通过 Zircon 渠道传输，允许这些类型选择退出此限制（例如通过属性）也可能很有用。
在对字节长度施加此限制之前，不妨考虑将其他机制（分页/流式传输等）纳入 FIDL 语言中。
在先技术和参考资料
未知