Problema de queue de transmisión periférica

Estoy trabajando en un simple contenedor alnetworkingedor de CoreBluetooth para enviar cualquier dato a cualquier dispositivo. Durante el desarrollo encontré muchos errores en el marco, resultaron muy molestos y para hacer que mi envoltura se mantuviera estable, tuve que acortar algunas de las funciones de confiabilidad.

Por ahora estoy trabajando en enviar datos desde periféricos.

Ok, entonces tengo el siguiente caso:

  • El cliente pregunta por el valor de la característica dinámica
  • Recibo una callback en el lado del server – periférico: didReceiveReadRequest :.

Nota : Necesito responder a este CBATTRequest en este método: no puedo savelo en otro lugar y responder de forma asíncrona. (Acabo de poner un fragment @ "PrepareToReceiveValue" que se ignorará en el lado central. Todo el envío se realiza en queue).

  • Para proporcionar datos para varios dispositivos, construí una queue con BTMessage en ella. (Por lo tanto, para readRequest, creo el post y lo agrego a la queue de envío. Si el envío de fragments no funciona, recibiré una callback del administrador periférico sobre readyToUpdateSubscribers y solicitaré la queue para volver a enviar el fragment fallido)
  • Entonces, cuando estoy solicitando de inmediato una gran cantidad de valores característicos dynamics y enviando datos de periférico a central simultáneamente, a veces se congela el envío del progreso y conduce a la desconnection.

Después de varias testings, descubrí que todo se trataba de transmitir queue: si la queue de transmisión está llena y recibirás una request de lectura, simplemente no responderá.

Entonces tengo un estado potencial inestable del sistema:

  1. Peripheral está enviando datos a alguna central.
  2. En mi método de envío updateValue: forCharac … devuelve NO porque la queue de transmisión está llena.
  3. En este momento, las centrales solicitan valor dynamic para la característica y periférico: didReceiveReadRequest: la invocación se agregará al actual runloop.
  4. Después de regresar del método de envío, se desclavará el método periférico: didReceiveReadRequest: método y responder a esta request no tendrá ningún efecto (la queue de transmisión está llena).
  5. Entonces, en este caso, answerToRequest: se ignora como si no lo hubiera invocado en absoluto.
  6. CoreBluetooth no podrá enviar / recibir ningún dato hasta que responda a la request. Esa fue la razón para congelar cualquier progreso de envío / recepción con la desconnection concomitante.
  7. Como mencioné antes, debo responder a la request en el método apropiado; de lo contrario, tampoco tendrá efecto. (Lo digo porque he intentado poner esas requestes en array si la queue está llena y responder a ellas cuando tenga espacio pero sin suerte).

Estoy esperando sus propuestas / sugerencias para resolver este problema, cualquier ayuda sería apreciada.