ios - GCD dispatch_io API 用于 iOS 上的网络 : discouraged?

Question

Apple 的 documentation说:

In iOS, POSIX networking is discouraged because it does not activate the cellular radio or on-demand VPN. Thus, as a general rule, you should separate the networking code from any common data processing functionality and rewrite the networking code using higher-level APIs.

该文档没有提到来自 GCD 的 dispatch_io API，因此不清楚它们是否在 iOS 上激活 radio 。事实上，尚不清楚“特殊调味料”是在打开连接的代码中，还是在对其进行读写的代码中。

如果我使用 POSIX API 连接套接字并将其传递给 dispatch_io_create 会怎样？如果我使用 CFStream API 创建套接字、提取文件描述符并将其传递给 dispatch_io_create 会怎样？这些方法中的哪一个可以使网络在 iOS 上正常工作？两个都？都没有？

Answer 1

我没有测试过，但我的猜测是所有 VPN-on-demand 和 Cellular-radio 魔法都发生在启动/设置/连接打开时，因为这是唯一真正有意义的事情。因此，我希望您使用 CFSocketGetNative 和使用 dispatch_io 挖掘文件描述符的方法可以正常工作，至少在其中一个连接断开之前(假设 TCP/有状态连接)。从断开的连接中恢复的 AFAICT 无论如何都没有内置到 CFSocket/CFNetworkStream 中，所以它可能是六比一的......

我已经阅读了一些关于 iOS 新的多路径 TCP 实现的含糊新闻(听起来像是重新访问了链接绑定(bind))，目前还不清楚这是否适用于第 3 方应用程序，但我认为是这样的方式:要么多路径支持在协议(protocol)栈中(因此作为单个套接字/文件描述符抽象给应用程序开发人员)并且将对任何 TCP 上的第 3 方应用程序开发人员透明地工作套接字，或它依赖于一些更高级别的用户空间组件来处理/聚合多个底层连接为一个，并将迫使开发人员使用更高级别的 API。如果您想要 VPN-on-demand 和 cell-radio 功能，您已经必须使用更高级别的 API 来设置连接，所以这对您来说似乎也不重要方式。

如果您的目标只是让一个异步 I/O session 由 block 提供服务，那么最安全的操作过程(考虑到这些东西在文档中似乎有点不明确)似乎是使用基于 runloop 的 API 并拥有回调调用一个 block 。如果你担心你的网络 I/O 和主运行循环之间的交互，你总是可以用它自己的运行循环假脱机后台线程并在那里安排你的 I/O。从过去用这两个 API 完成 I/O 的经验来看，我希望 runloop 方法在性能方面在功能上等同于在常见情况下使用 dispatch_io API(即它不会明显变慢除非你正在做一些真的高吞吐量或真的闲聊的事情。)

FWIW，如果将此问题发布到 Apple 的开发者支持板上，可能更有可能获得权威响应(但也可能不会。)