我正在研究一个围绕CoreBluetooth的简单包装器,将任何数据发送到任何设备 . 在开发过程中,我在框架中遇到了很多错误,它们非常烦人,为了使我的包装器稳定,我不得不缩短一些可靠性功能 .

目前我正致力于从外围设备发送数据 .

好的,所以我有以下案例:

  • 客户要求动态特性的值

  • 我在服务器端获得回调 - peripheral:didReceiveReadRequest: .

Note :我需要在此方法中响应此CBATTRequest - 我无法将其存储在其他位置并以异步方式响应它 . (我只是放了一些块“@ PrepareToReceiveValue”,将在中央端忽略 . 所有发送都在队列中完成 . )

  • 为了为各种设备提供数据,我构建了一个包含BTMessage的队列 . (因此对于readRequest我创建消息并将其添加到发送队列 . 如果块发送失败 - 我将从外围管理器获得有关readyToUpdateSubscribers的回调,并将要求队列重新发送失败的块)

  • 因此,当我立即请求大量动态特征值并同时从外设向中心发送数据时,它有时会冻结发送进度并导致断开连接 .

经过多次测试后,我发现它完全与发送队列有关:如果发送队列已满,您将收到读取请求 - 它只是不响应它 .

所以我有潜在的不稳定系统状态:

  • 外围设备正在向某个中心发送数据 .

  • 在我的发送方法中,updateValue:forCharac ...返回NO,因为传输队列已满 .

  • 此时中央请求特性和外设的动态值:didReceiveReadRequest:调用将被添加到当前的runloop .

  • 从发送方法返回后,它将使external:didReceiveReadRequest:方法出列并响应此请求将无效(传输队列已满) .

  • 所以在这种情况下,responseToRequest:会被忽略,就像我根本没有调用它一样 .

  • 在我回复请求之前,CoreBluetooth将无法发送/接收任何数据 . 这就是冻结任何发送/接收进度同时断开连接的原因 .

  • 正如我之前提到的 - 我必须以适当的方法回应请求 - 否则它也将无效 . (我说这是因为我试图将这些请求放在数组中,如果队列已满,并在它有一些空间但没有运气的情况下响应它们) .

我在等待你的建议/建议如何解决这个问题,任何帮助将不胜感激 .