ios - Central 正在为 Peripheral 的写请求获取错误响应，响应有点晚

Question

我一直在使用 CoreBlueTooth 框架在 BTLE iOS 设备之间进行通信，但我看到了一个奇怪的行为。这是我正在做的:

1. iOS 设备 1(外围设备):公开可写特性。
2. iOS 设备 2(中央):扫描可写特征并将数据写入其中。
3. iOS 设备 1(外围设备):接收写入请求。等待一段时间以确认收到数据。
4. iOS 设备 2(中央):获取以下委托(delegate)的回调并收到上述错误。

问题:如果我在几秒钟内通过调用 API [iPeripheral respondToRequest:iRequest withResult:iStatus] 响应写请求，那么一切正常，我在 Central 上获得成功.但是如果我花一些时间，即使我的 Peripheral 没有响应写入请求，我也会收到错误响应。

这是几秒钟内的某种连接丢失还是已知的 CB 框架行为，您知道吗？

- (void)peripheral:(CBPeripheral *)iPeripheral didWriteValueForCharacteristic:(CBCharacteristic *)iCharacteristic error:(NSError *)iError 

Error Domain=CBErrorDomain Code=0 "Unknown error." UserInfo=0x183a6d70 {NSLocalizedDescription=Unknown error.}

我的 Central 和 Peripheral 都在 iOS 7.0 上运行。

Answer 1

当我的代码出现死锁并且无法及时响应时，我也观察到了这个问题;-) 我观察到的方式是，如果请求未在10 秒。我还没有找到改变这一点的方法，但从协议(protocol)的角度来看这是有意义的。

在低功耗蓝牙中，中央节点一次只能发送一个特征值写入请求。发送此请求后，除非第一个请求得到响应，否则它不能发送不同的写入请求。因此，始终尽快响应请求至关重要。

在评论中，您提到您正在等待用户输入来影响您要发送到中央的结果代码。如果用户在 UI 中确认应该开始操作，我猜是“成功”，如果用户拒绝，则为错误代码。这不是设计基于 LE 的协议(protocol)的方式。这就像从另一端阻塞 UI 线程直到操作完成。在阻止操作(等待用户输入)完成之前，您实际上是在阻止 BT 通信。

另一种设计是向另一部手机发送写入请求，并立即以“成功”错误代码进行响应，以指示已收到请求并显示弹出窗口。然后，将带有用户选择的特征值指示从外设发送到中央。

如果您的目标是 iOS 6，有一个小警告:在许多情况下，指示效果不佳(重入错误等，最好不要碰它们)。在那里，您应该从您的中心发送一个读取请求，并在该读取请求中返回用户的选择(如果它已经可用)。同样，在给出答案时不要阻塞，如果答案尚未准备好，则发回“用户仍在选择”值。

单一规则:尽快回复请求。 Bluetooth LE 就是这样工作的。