Bluetooth Core Spec V4.0 Vol。 3 G部分4.9.3 状态，对于使用响应写入特征值，使用属性协议写请求过程。
蓝牙核心规范V4.0第3卷第F部分第3.3.2节描述，
一旦客户端向服务器发送请求，该客户端将不会向同一服务器发送其他请求，直到收到响应PDU为止。
我想在使用CoreBluetooth的iOS应用中使用响应编写多个值。我是否必须自己管理此规范？或者我可以简单地使用- writeValue:forCharacteristic:type一次写入所有值，并且iOS管理每个请求仅在前一个请求被处理后发送？
我猜不出iOS会管理它，因为根据蓝牙核心规范V4.0第3卷第F部分第3.4.5.2节 写入响应不包含链接到书面特征。但是，- peripheral:didWriteValueForCharacteristic:error方法表明iOS会以某种方式跟踪响应所链接的特征。
有人可以确认或否认吗？
答案 0 :(得分：2)
在与CB交易时，我认为你不必担心ATT / GATT。原因是许多使用CB的人无法访问Bluetooth Core 4.0规范，他们也不希望阅读它们。
CB知道如何关联该特性的原因是该协议规定每个命令和响应是成对的。发送命令时，您将收到回复。
因此您可以多次使用writeValue，CB将为您正确排队调用，即它将在下一次写入之前等待ATT层的响应。并且委托回调保证与执行写入的顺序相同。
答案 1 :(得分：1)
我能够用响应＆＃34;写出多个请求。即
[self peripheral] writeValue：valueToWrite forCharacteristic：dataPointCharacteristic type：CBCharacteristicWriteWithResponse];
在一起 - 实际上我发送了其中的14个 - 并且所有人在延迟之后回复了回复。但是 - 写入响应不包含写入特征的数据 - 即 - 只有特征内的值在响应中无效。
似乎接近音符＆＃34;根据蓝牙核心规范V4.0第3卷第F部分第3.4.5.2节，写入响应不包含指向书面特征的链接＆＃34;一个区别是只有[characteristc值]不正确 - 但是ios在内部处理了排序。因此，使用写响应（即BLE确认）来连接排序逻辑以处理下一步执行的一系列步骤似乎是不可行的。
所以 - 外卖是 - 如果你问BLE＆＃34; writeWithReponse＆＃34;消息＆＃34;做任务＃1＆＃34;对于外围设备，来自外围设备的BLE响应是＆＃34; OK！＆＃34;。响应并没有告诉您外围设备收到了消息＆＃34; Do Task＃1＆＃34;但相反的是 - 是的，我得到了你说的话。我懒得重复你发给我的确切命令：）