Se um serviço BLE contém múltiplas características de notificação nas quais um cliente GATT manifestou interesse, o protocolo BLE oferece alguma garantia sólida sobre a ordem em que os clientes GATT recebem os valores atualizados? Separadamente, há algum requisito em nível de protocolo sobre a ordem em que o cliente GATT entrega os dados recém-recebidos ao aplicativo?
Por exemplo: Digamos que o aplicativo altere os valores de duas características separadas no servidor GATT em rápida sucessão entre eventos de conexão durante o período de "silêncio". Durante o próximo evento de conexão, suponha que haja tempo e largura de banda suficientes para o servidor GATT transmitir totalmente ambos os valores de característica atualizados para o cliente GATT.
O protocolo BLE exige que o servidor GATT transmita os valores recém-alterados na ordem em que o aplicativo os alterou?
Além disso, o protocolo BLE exige que o cliente GATT preserve a ordem desses valores recém-alterados ao entregá-los ao aplicativo?
As pilhas BLE sobre as quais estou raciocinando suportam Bluetooth 5.0, mas também seria bom saber se algo disso mudou em relação às versões anteriores. Quaisquer citações específicas do próprio padrão do protocolo seriam muito úteis!
A resposta a todas estas perguntas acima é talvez surpreendentemente “Não aplicável”. Todo o conceito de uma biblioteca de software/sdk/api implementando a parte "principal" do GATT escrita por uma pessoa e depois tendo um aplicativo separado escrito por outra pessoa utilizando esta biblioteca/sdk/api simplesmente não existe quando você lê o padrão. O padrão Bluetooth é apenas um padrão de protocolo, ou seja, dita os requisitos de como dois dispositivos se comunicam entre si, e não de como um aplicativo é estruturado e implementado internamente. Consulte o diagrama de pilha de protocolos do capítulo GATT, seção 2.1 na especificação principal do Bluetooth (atualmente versão 5.4):
Como você pode ver, GATT é o perfil da “aplicação” e ATT é o protocolo que sua aplicação fala. Se você possui uma biblioteca de software que gerencia filas internamente, envia comandos/notificações para o thread correto, etc. para facilitar seu trabalho, então isso não faz parte do padrão Bluetooth e qualquer erro estúpido de design nesta biblioteca limita o uso do protocolo /profile para o desenvolvedor do aplicativo final deve ser visto como um "recurso ausente" do que como uma violação de protocolo.
Em algumas ocasiões, o padrão sugere alguns detalhes de implementação permitidos. No capítulo ATT, você pode ler, por exemplo, "Em um portador ATT não aprimorado, as notificações recebidas, mas que não podem ser processadas devido a buffer overflows, serão descartadas. Portanto, essas PDUs devem ser consideradas não confiáveis".
Para responder a esta pergunta, farei as mesmas suposições do padrão, ou seja, que a aplicação tenha acesso direto para enviar notificações GATT como pacotes ATT sempre que desejar para a camada inferior (L2CAP) e que o cliente GATT receba diretamente notificações ATT em na mesma ordem em que são recebidos da camada inferior (L2CAP).
Nem o protocolo ATT nem o padrão de perfil do GATT mencionam nada sobre a entrega solicitada quando se trata de notificações. Em vez disso, ao raciocinar sobre a entrega ordenada, o protocolo subjacente normalmente é o que é levado em consideração.
No Bluetooth 4.0-5.1, existia apenas o "portador ATT não aprimorado", que é um canal L2CAP fixo que entrega dados em ordem. Assim, você pode, pelo menos no nível do protocolo, esperar a entrega solicitada. O perfil HID, por exemplo, assume mais ou menos a entrega solicitada. Caso contrário, as teclas digitadas poderão terminar na ordem incorreta.
No Bluetooth 5.2, foram introduzidos "portadores ATT aprimorados", para permitir mais de uma transação ATT simultânea (uma por canal de comunicação), com o objetivo de acelerar situações quando vários "aplicativos" em execução no mesmo dispositivo conversam com o mesmo dispositivo remoto . Observe que apenas uma solicitação de leitura ou uma solicitação de gravação poderia ser executada por vez e a próxima deverá ser enviada quando a resposta da anterior for recebida. Se ambos os dispositivos suportarem esse recurso e você tiver aberto vários portadores ATT para o mesmo dispositivo, não será possível assumir nenhuma ordem específica de entrega de notificações ao outro dispositivo se elas forem enviadas por meio de portadores ATT separados, pois eles têm seu próprio controle de fluxo. Portanto, se você precisar de entrega solicitada, basta usar o mesmo portador ATT para essas notificações.
Na prática, todas as bibliotecas de software que implementam o GATT que conheço nunca reordenam notificações pertencentes à mesma característica. No Android, por exemplo, o mecanismo Binder é usado como camada IPC entre o daemon Bluetooth e cada aplicativo. Aqui, o retorno de chamada invocado quando uma notificação é recebida para um objeto BluetoothGatt específico não será chamado novamente até que uma invocação de método anterior para o mesmo objeto BluetoothGatt seja retornada.
No entanto, no Windows, da última vez que verifiquei, toda vez que você começa a ouvir notificações, um novo thread é gerado no qual seu manipulador de eventos será executado sempre que uma notificação for recebida. Como você só pode especificar a escuta de uma característica ao ouvir notificações, será necessário configurar dois ouvintes separados se tiver duas características e, portanto, dois threads serão iniciados, cada um manipulando cada característica. E com dois threads é impossível sincronizar a ordem das notificações entregues, pois ambos os threads podem ser executados simultaneamente em dois núcleos de CPU diferentes. Este é um daqueles erros de design "burros" na minha opinião que limita o uso.
Então, como sugestão, se você precisa de garantias de que as notificações serão entregues e processadas na mesma ordem em que são emitidas, use uma única característica e normalmente você estará bem.