| 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 语言。
在先技术和参考文档
未知