我没有对其进行测试,但我的猜测是所有按需 VPN 和蜂窝无线电的魔法都发生在启动/设置/连接打开时间,因为这真的是唯一真正有意义的事情。因此,我希望您使用CFSocketGetNative
和使用挖掘文件描述符的方法dispatch_io
可以正常工作,至少直到其中一个连接断开(假设 TCP/有状态连接)。从断开的连接中恢复的 AFAICT 无论如何都不是内置CFSocket/CFNetworkStream
的,所以它可能是六对一的......
我已经阅读了一些关于 iOS 的新多路径 TCP 实现的模糊新闻(听起来像是重新访问了链接绑定),目前还不清楚这是否适用于 3rd 方应用程序,但我是这样想的:要么多路径支持在协议栈中(因此被抽象为应用程序开发人员作为单个套接字/文件描述符)并且将对任何TCP 套接字上的第 3 方应用程序开发人员透明地工作,或者它依赖于一些更高级别用户级组件将多个底层连接处理/聚合为一个,并将迫使开发人员使用更高级别的 API。你已经如果您想要 VPN-on-demand 和 cell-radio 功能,则必须使用更高级别的 API 来建立连接,所以看起来这对您来说都无关紧要。
如果您的目标只是让块为异步 I/O 会话提供服务,那么似乎最安全的操作过程(鉴于这些东西在文档中似乎有点未指定)是使用基于 runloop 的 API 并进行回调调用一个块。如果你担心网络 I/O 和主 runloop 之间的交互,你总是可以使用它自己的 runloop 建立一个后台线程并在那里安排你的 I/O。从过去使用这两种 API 完成 I/O 来看,我希望 runloop 方法在性能方面在功能上等同dispatch_io
于在常见情况下使用 API(即,除非您正在做一些非常高的事情,否则它不会明显变慢-吞吐量或真的很健谈。)
FWIW,如果将这个问题发布到 Apple 的开发者支持委员会,这个问题可能更有可能获得权威的回应(但也可能不会。)