我正在研究一个围绕CoreBluetooth的简单包装器，将任何数据发送到任何设备。
在开发过程中，我在框架中遇到了很多错误，它们非常烦人，为了使我的包装器稳定，我不得不缩短一些可靠性功能。
目前我正致力于从外围设备发送数据。
好的，所以我有以下案例：
- 客户要求动态特征的价值
- 我在服务器端获得回调 - 外围设备：didReceiveReadRequest：。
注意：我需要在此方法中响应此CBATTRequest - 我无法将其存储在其他位置并以异步方式响应它。 （我只是放了一些块“@ PrepareToReceiveValue”，它将被忽略在中央端。所有发送都在队列中完成。）
- 为了为各种设备提供数据，我构建了一个带有BTMessage的队列。 （因此对于readRequest我创建消息并将其添加到发送队列。如果块发送失败 - 我将从外围管理器获得有关readyToUpdateSubscribers的回调，并将要求队列重新发送失败的块）
- 因此，当我立即请求大量动态特征值并同时从外设向中心发送数据时，它有时会冻结发送进度并导致断开连接。
经过多次测试，我发现它完全是关于传输队列的：
如果传输队列已满，您将收到读取请求 - 它只是不会响应它。
所以我有潜在的不稳定系统状态：
- 外围设备正在向某个中心发送数据。
- 在我的发送方法中，updateValue：forCharac ...返回NO，因为传输队列已满。
- 此时中央请求特性和外围设备的动态值：didReceiveReadRequest：调用将被添加到当前的runloop。
- 从发送方法返回后，它将使external：didReceiveReadRequest：方法出列并响应此请求将无效（传输队列已满）。
- 所以在这种情况下，responseToRequest：会被忽略，就像我根本没有调用它一样。
- 在我回复请求之前，CoreBluetooth将无法发送/接收任何数据。这就是冻结任何发送/接收进度同时断开连接的原因。
- 正如我之前提到的 - 我必须以适当的方法回应请求 - 否则它也将无效。 （我之所以这么说是因为我已经尝试将这些请求放在数组中，如果队列已满，并在它有一些空间但没有运气时回复它们。）
我在等待您的提案/建议如何解决此问题，我们将不胜感激。