LaC*_*LaC 5 sockets grand-central-dispatch ios
Apple的文档说:
在iOS中,不鼓励POSIX网络,因为它不会激活蜂窝无线电或按需VPN.因此,作为一般规则,您应该将网络代码与任何常见的数据处理功能分开,并使用更高级别的API重写网络代码.
该文档未提及dispatch_ioGCD中的API,因此不清楚它们是否在iOS上激活了无线电.事实上,尚不清楚"特殊酱"是否在打开连接的代码中,或者在读取和写入的代码中.
如果我使用POSIX API连接套接字并将其传递给该dispatch_io_create怎么办？如果我使用CFStream API创建套接字,提取文件描述符并将其传递给dispatch_io_create？哪些方法可以使网络在iOS上正常运行？都？都不是？
我还没有测试过它，但我的猜测是，所有 VPN 点播和蜂窝无线电魔法都发生在启动/设置/连接打开时，因为这确实是唯一真正有意义的事情。CFSocketGetNative因此，我希望您使用 和 using挖掘文件描述符的方法dispatch_io会工作得很好，至少直到其中一个连接被破坏（假设 TCP/有状态连接）。从断开的连接中恢复的 AFAICT 无论如何都没有内置CFSocket/CFNetworkStream，所以它可能是六比一......
我读过一些关于 iOS 即将推出的新多路径 TCP 实现的模糊新闻（听起来像是重新审视链接绑定），目前还不清楚这是否适用于第 3 方应用程序，但我是这样认为的：多路径支持位于协议栈中（因此被抽象为应用程序开发人员作为单个套接字/文件描述符），并且将在任何TCP 套接字上对第三方应用程序开发人员透明地工作，或者它依赖于某些更高级别的用户态组件来处理/聚合多个底层连接到一个，并将迫使开发人员使用更高级别的 API。如果您想要 VPN 点播和蜂窝无线电功能，您就必须使用更高级别的 API 来设置连接，因此看起来这对您来说并不重要。
如果您的目标仅仅是让块提供异步 I/O 会话服务，那么最安全的做法似乎是使用基于 runloop 的 API 并进行回调调用（考虑到这些内容在文档中似乎未指定）一个块。如果您担心网络 I/O 和主运行循环之间的交互，您始终可以使用自己的运行循环来假脱机后台线程并在那里调度 I/O。从过去使用这两个 API 完成 I/O 的情况来看，我希望 runloop 方法在性能方面、功能上等同于dispatch_io在常见情况下使用 API（即，除非您正在做一些非常高的事情，否则它不会明显变慢） - 吞吐量或确实健谈。）
FWIW，如果将这个问题发布到苹果开发者支持委员会，可能更有可能获得权威答复（但也可能不会。）
| 归档时间： |
|
| 查看次数： |
1533 次 |
| 最近记录： |