iOS10 中的多点连接错误 "Send BINDING_REQUEST failed"
Multipeer Connectivity Error "Send BINDING_REQUEST failed" in iOS10
我在 iOS 10 中的 MPC 应用程序中看到以下错误,我正在寻求一些帮助来解释这些错误。对等点连接后,会弹出以下几个错误。对等点最终连接起来,但它比 iOS 9 慢(似乎导致错误消息的事件发生在主线程上)。当 运行 on an iOS < 10.
时,这些错误不会出现在应用程序中
[ViceroyTrace] [ICE][ERROR] Send BINDING_REQUEST failed(C01A0041).
Not in connected state, so giving up for participant [47CD8292] on channel [0].
如有任何意见,我们将不胜感激!
the reason and meaning of the error
NAT
为了解释错误的原因和含义,我们还得从NAT说起(熟悉的可以跳过这部分)。
NAT 是一种为 同一本地网络 中的多个设备映射相同 'global' IP 地址的方法,即多个设备共享相同的地址(可能在不同的时间, 可能使用不同的端口 -- NAPT), 这样我们可以节省大量 'global' 地址并缓解 ipv4 地址的耗尽。也正因如此,设备的本地地址只能在局域网内使用,不能在外网使用。要发送到外部的数据报将通过 NAT 设备(通常是路由器),它将报头中的地址修改为全局地址。还有一点是不同局域网中的设备可能使用相同的IP地址。
|
| /------------ 'Global'
X1':x1'|/ Address
+------------+
| NAT |
+------------+
|
| /------------ Local
X:x |/ Address
+--------+
| |
| Agent |
| |
+--------+
ICE
现在,我们想让对等点直接通信,所以我们必须知道对等点的地址。但是我们知道,NAT的使用使得设备的地址只是一个本地地址,无法在Internet之外使用,无法使用它进行通信。
ICE 的目的是发现对等点应该使用哪个地址与其他对等点直接通信。
收集候选人地址
第一阶段收集候选人地址:
- 其接口地址
- NAT public 端的翻译地址(服务器反射候选)
- (可选):TURN 服务器上的地址(中继候选人)
为了获得public端地址,设备将发送'Binding request'到public服务器(称为STUN服务器,局域网外),服务器发回地址称为'Binding response'.
连接检查
当设备拥有它们所拥有的地址时,它们将通过信令通道发送给其他对等点。当对等方(我们称之为'R')从我们的设备(我们称之为'L')接收到地址列表时,R 将收集自己的地址并响应自己的列表。在此过程结束时,它会产生 候选对 。
为了查看哪些对有效,每个代理安排了一系列带有 'Binding request' & 'Binding response' 的 CHECKS。
L R
- -
STUN request -> \ L's
<- STUN response / check
<- STUN request \ R's
STUN response -> / check
结论
所以总而言之,可能的原因在更多细节之前:
- 无法连接到 STUN 服务器;
- 测试地址对时正常失败;
建议:
- 查看有关 ICE 阶段的信息,了解 ios10 和其他 ICE 实现的差异。
- This thread是一些关于mpc的bug的讨论,希望对你有所启发。
参考:
我在 iOS 10 中的 MPC 应用程序中看到以下错误,我正在寻求一些帮助来解释这些错误。对等点连接后,会弹出以下几个错误。对等点最终连接起来,但它比 iOS 9 慢(似乎导致错误消息的事件发生在主线程上)。当 运行 on an iOS < 10.
时,这些错误不会出现在应用程序中[ViceroyTrace] [ICE][ERROR] Send BINDING_REQUEST failed(C01A0041).
Not in connected state, so giving up for participant [47CD8292] on channel [0].
如有任何意见,我们将不胜感激!
the reason and meaning of the error
NAT
为了解释错误的原因和含义,我们还得从NAT说起(熟悉的可以跳过这部分)。
NAT 是一种为 同一本地网络 中的多个设备映射相同 'global' IP 地址的方法,即多个设备共享相同的地址(可能在不同的时间, 可能使用不同的端口 -- NAPT), 这样我们可以节省大量 'global' 地址并缓解 ipv4 地址的耗尽。也正因如此,设备的本地地址只能在局域网内使用,不能在外网使用。要发送到外部的数据报将通过 NAT 设备(通常是路由器),它将报头中的地址修改为全局地址。还有一点是不同局域网中的设备可能使用相同的IP地址。
|
| /------------ 'Global'
X1':x1'|/ Address
+------------+
| NAT |
+------------+
|
| /------------ Local
X:x |/ Address
+--------+
| |
| Agent |
| |
+--------+
ICE
现在,我们想让对等点直接通信,所以我们必须知道对等点的地址。但是我们知道,NAT的使用使得设备的地址只是一个本地地址,无法在Internet之外使用,无法使用它进行通信。 ICE 的目的是发现对等点应该使用哪个地址与其他对等点直接通信。
收集候选人地址
第一阶段收集候选人地址:
- 其接口地址
- NAT public 端的翻译地址(服务器反射候选)
- (可选):TURN 服务器上的地址(中继候选人)
为了获得public端地址,设备将发送'Binding request'到public服务器(称为STUN服务器,局域网外),服务器发回地址称为'Binding response'.
连接检查
当设备拥有它们所拥有的地址时,它们将通过信令通道发送给其他对等点。当对等方(我们称之为'R')从我们的设备(我们称之为'L')接收到地址列表时,R 将收集自己的地址并响应自己的列表。在此过程结束时,它会产生 候选对 。 为了查看哪些对有效,每个代理安排了一系列带有 'Binding request' & 'Binding response' 的 CHECKS。
L R
- -
STUN request -> \ L's
<- STUN response / check
<- STUN request \ R's
STUN response -> / check
结论
所以总而言之,可能的原因在更多细节之前:
- 无法连接到 STUN 服务器;
- 测试地址对时正常失败;
建议:
- 查看有关 ICE 阶段的信息,了解 ios10 和其他 ICE 实现的差异。
- This thread是一些关于mpc的bug的讨论,希望对你有所启发。
参考: