Protocolo MQTT | Publish/Subscriber (parte – 02)

Olá leitor, vamos dar continuidade a nossa série de postagens sobre o protocolo MQTT (Message Queue Telemetry Transport). Agora familiarizados sabemos que o MQTT é um protocolo de rede para troca de mensagens. Aprendemos ainda que o protocolo este que tem no recurso Publish/Subscriber – modelo de aplicação e assinatura, um importante meio onde publicador e assinante interage sem que um necessariamente tenha conhecimento do outro.

Em nossa publicação anterior ‘Protocolo MQTT | Publish/Subscriber (parte – 01)’, destacamos o message broker, uma espécie de servidor capaz de gerir as publicações, as subscrições e os inúmeros clientes. Ao longo de nossas postagens temos explicitado o broker como um servidor, e o fazemos para um melhor entendimento do leitor, e também por ser essa a sua função, receber e atender as requisições do publish/subscriber respectivamente. Entretanto, o broker pode e deve ser entendido como um canal de distribuição capaz de garantir a comunicação entre os dispositivos e as interfaces que podem ser web e até mesmo interface de outros dispositivos.

Assim, conforme mencionado acima, ao broker cabe receber, enfileirar e disparar as mensagens recebidas dos publicadores para os assinantes. O publicador por sua vez tem a responsabilidade de se conectar ao broker e publicar as mensagens, e ao assinante cabe também se conectar ao broker, no entanto, recebe dele somente as mensagens que tem interesse.

MÉTODO PUBLISH/SUBSCRIBER DO MQTT

O disposto na sessão anterior sobre o modelo publish/subscriber, evidencia em termos práticos o motivo pelo qual o desacoplamento do padrão pub/sub é considerado um ponto forte, visto que a interação com o broker pode se dar de forma independente. Note ainda que ambos, publicador e assinante comunicam-se com o broker, no entanto, essa comunicação não ocorre ou não se efetiva ao mesmo tempo, desse modo essa comunicação classifica-se como assíncrona.

Por ser um protocolo de mensagem assíncrono o MQTT elimina o problema comum aos protocolos de comunicação síncrona, como o HTTP, por exemplo, problemas de baixa escalabilidade e de alta latência. Novamente, para o mundo de IoT o MQTT se mostra cada vez mais viável. É válido lembrar inclusive, que, a força desse protocolo reside em sua simplicidade. Assim, esta simplicidade junto a outras características compreendem um atrativo também para aplicações de alta capilaridade, ou seja, de grande abrangência e baixa disponibilidade, que contam com restrição de banda de comunicação, de memória e processamento, localizações remotas e também aplicações mobile.

Com efeito, não apenas as aplicações de IoT se beneficiam do MQ Telemetry Transport, mas também aplicações M2M (Machine to Machine) ou em português, Máquina a Máquina, cujo conceito em termos simples é a tecnologia que possibilita que sistemas se comuniquem com outros dispositivos que possuem a mesma habilidade. Basicamente o M2M usará um dispositivo que funcionará como um sensor para capturar informações de um dado evento, como temperatura, nível de estoque, qualidade da água, etc. Estes dados capturados são enviados por uma rede, para uma aplicação – programa de computador, que registrará e processará tais informações transformando-as em dados úteis.

Em suma, o MQ Telemetry Transport será sempre uma boa opção quando se busca confiabilidade onde há limitação de recursos, e algum nível de garantia de entrega de mensagens, além da possibilidade de acesso externo sem que seja necessário recorrer ao síncrono HTTP.

E não apenas pelos motivos citados acima, mas o protocolo MQTT será sempre bem aceito também em decorrência do já citado modelo de troca de mensagens publish/subscriber com o seu desacoplamento de aplicações; transporte de mensagens sem ter que se preocupar com o conteúdo da mesma; desenvolvimento com base na pilha TCP/IP que possibilita seu uso para uma conexão básica de rede; mecanismos de aviso aos interessados sobre a perda de conexão de um cliente;  cabeçalho simples de apenas de 2 bytes e três níveis de QoS (Quality of Service) em português, qualidade de serviço para entrega de mensagens.

QoS PARA ENTREGA DE MENSAGENS

Na sessão ‘MÉTODO PUBLISH/SUBSCRIBER DO MQTT’ desta postagem, relembramos a importância do broker como um centralizador das informações e um importante centro de distribuição que tem a função essencial de garantir a comunicação entre os dispositivos e suas interfaces.

Entretanto, a conexão do cliente com o broker originalmente realizada via TCP/IP pode opcionalmente requerer a autenticação do mesmo junto aos protocolos de criptografia SSL (Secure Socket Layer) e TLS (Transport Layer Security), SSL/TLS, ou simplesmente como é popularmente conhecido certificado SSL. A verdade é que todo processo de conexão estabelecido deve estabelecer também um padrão de confiabilidade com um certo nível de garantia de entrega de mensagens como ressaltamos anteriormente, bem como de qualidade de serviço – QoS (Quality of Service), a saber.

Neste contexto de qualidade de serviço o MQTT dispõe de três nívei de QoS para entrega de publicações para o cliente, a saber: “no máximo uma vez – at most once”; “pelo menos uma vez – at least once” e “exatamente uma vez – exactly once”. Em síntese isso significa que quando um cliente MQTT enviar uma solicitação ao broker para criar uma assinatura, a solicitação será enviada pelo menos com qualidade QoS = 0, ou seja,  at most once.

QoS = 0 (at most once) – no máximo uma vez: também denominado de “best effort”, melhor esforço. É o modo de transferência mais rápido, às vezes chamado de “fire and forget”. Neste nível a mensagem será entregue pelo menos uma vez e não será armazenada, podendo ser perdida em caso de queda de conexão seja esta perda por falha do servidor ou desconexão por parte do cliente.

É importante ressaltar ainda que quem envia a mensagem não contempla a obrigação de armazena-la para futuras retransmissões. Assim, se o cliente estiver desconectado no momento em que o servidor receber a publicação, esta poderá ser descartada.

NÍVEIS DE QUALIDADE DE SERVIÇO

QoS = 0 (at most once) – no máximo uma vez: também denominado de “best effort”, melhor esforço. É o modo de transferência mais rápido, às vezes chamado de “fire and forget”. Neste nível a mensagem será entregue no máximo uma vez e não será armazenada, podendo ser perdida em caso de queda de conexão, seja esta perda por falha do servidor ou desconexão por parte do cliente.

É importante ressaltar ainda que quem envia a mensagem não contempla a obrigação de armazená-la para futuras retransmissões. Assim, se o cliente estiver desconectado no momento em que o servidor receber a publicação, esta publicação poderá ser descartada.

QoS = 1 (at least once) – pelo menos uma vez: neste nível haverá confirmação de entrega da mensagem e ela será entregue pelo menos uma vez. Ao contrário do que acontece no nível zero, a mensagem será armazenada localmente no emissor e no receptor até que seja processada e a entrega confirmada.

Este nível se adequa a situações em que uma fila de mensagens contendo a mesma mensagem é formada, o que pode ocorrer em função de um atraso na chegada da confirmação do recebimento. Além do mais, se o receptor da mensagem for um broker, obviamente a mensagem será publicada para os assinantes, como no nosso exemplo do canal do YouTube da MasterWalker Shop, na parte – 01 dessa postagem sobre o publish/subscriber. No entanto, se o receptor for um cliente, a mensagem será entregue a aplicação do assinante.

O receptor enviará uma mensagem de confirmação ao emissor, logo a exclusão da mesma, enquanto que do lado do emissor a mensagem será excluída após o recebimento da confirmação de entrega da mensagem.

QoS = 2 (exactly once) – exatamente uma vez: A garantia de que a mensagem será entregue exatamente uma vez, faz desse nível o mais seguro e consequentemente o modo de transferência mais lento. A mensagem será obrigatoriamente armazenada no emissor e receptor até que seja processada. Neste nível haverá confirmação nos dois sentidos para exatamente tudo que trafega na rede, e quando não há por parte do receptor confirmação de recebimento, a mensagem será enviada novamente com o sinalizador DUP configurado até que uma confirmação seja recebida.

É interessante observar que o receptor poderá processar a mensagem em qualquer uma das fases, no entanto, somente o fará uma vez, e a mensagem não deverá ser processada novamente. E tal como acontece no QoS = 1, o receptor enviará uma mensagem de confirmação ao emissor, logo a exclusão da mesma, enquanto que do lado do emissor a mensagem será excluída após o recebimento da confirmação de entrega da mensagem.

O melhor QoS dependerá das necessidades de cada cenário de uso da aplicação do MQ Telemetry Transport, dos recursos disponíveis entre outros itens a serem observados. Note que uma publicação pode ter um nível de QoS e um assinante pode ter um outro nível de QoS, e isso é possível porque a qualidade de serviço é negociada entre cliente e broker.

EXEMPLOS DE USO DO MQTT

O campo de implementações que abarca o uso do protocolo MQTT é vasto, ele pode ser implementado em um semáforo, em um sistema de irrigação, em sensores de temperatura e em muitos outras aplicações. Por certo, qualquer dispositivo do nosso dia a dia poderia se beneficiar com o uso desse protocolo, como o seu smartphone, por exemplo. Repetidas vezes mencionamos que entre as vantagens desse protocolo está o bom desempenho em redes cuja largura da banda é restrita e a latência alta, cenário este que abrange o uso dos telefones inteligentes.

É lugar comum que os smartphones em uma parte considerável do tempo estão em uma rede de má qualidade, além do recorrente problema de durabilidade da bateria. Portanto, quanto mais leve for o protocolo de troca de mensagens, menos recursos de rede serão necessários, e acarretará também em uma menor utilização da carga da bateria. Você mesmo caro leitor, quando troca mensagens usando o Facebook Messenger está indiretamente fazendo uso do MQTT. Entenda como.

O FACEBOOK MESSENGER E O MQTT

O Facebook Messenger é um aplicativo de envio de mensagens de forma instantânea que combina facilidade e simplicidade, onde o envio das mensagens pode ser 1 a 1 ou de 1 para muitos. Observem que estamos falando de um cenário de milhões de usuários.

Durante o processo de desenvolvimento e implementação do Facebook Messenger um dos problemas encontrados foi a alta latência no envio de mensagens. Contornar este problema significava encontrar um método que estabelecesse uma conexão persistente com os servidores e preservasse a carga da bateria sem esgotá-la. A solução encontrada foi o MQTT – Message Queue Telemetry Transport.

Originalmente o MQTT foi desenvolvido para vincular sensores em pipelines de petróleo para e a partir de sondas de espaço – satélites, por isso projetado para um baixo consumo de largura de banda e de bateria. Deste modo, a integração do protocolo MQTT com o roteamento de mensagens por meio do canal de bate-papo garantiu ao Facebook Messenger a entrega M2M de mensagens em centenas de milésimos de segundos, diferente dos muitos segundos que eram necessários anteriormente, o que eliminou severos problemas de desempenho como a alta taxa de latência.

Chegamos ao fim de mais uma postagem, esperamos que tenham gostado da parte – 02 da nossa conversa sobre o publish/subscriber. Fiquem com a gente e até a próxima postagem.

Gostou desta postagem? Então deixa seu comentário, dúvida ou sugestão aí embaixo!

Loja online: https://www.masterwalkershop.com.br
Fan page no Facebook: https://www.facebook.com/masterwalkershop

Nos ajude a espalhar conhecimento clicando no botão de compartilhar (f Like) que está mais abaixo.
Obrigado e até a próxima!

Seu feedback é muito importante! Que tal dar uma nota para esta postagem?! Faça sua avaliação aqui embaixo.