Nesta postagem você vai aprender a utilizar o Blynk em…
Protocolo MQTT | Publish/Subscriber (parte – 01)
Para que o leitor possa se contextualizar, na postagem anterior iniciamos uma abordagem sobre o protocolo MQTT (Message Queue Telemetry Transport) – um protocolo de rede para troca de mensagens, baseado na pilha TCP/IP. Ressaltamos ainda que o MQTT vem se destacando como uma alternativa aos outros inúmeros protocolos de rede por ser de implementação simples, seguro e de aplicação leve, o que, entre outros motivos o torna ideal para conectar dispositivos de IoT (Internet of Things) ou em português, Internet das Coisas.
Mencionamos ainda que o MQTT suporta comunicação assíncrona e tem suas bibliotecas suportadas por várias linguagens de programação, entre as quais evidenciam-se as linguagens C, C++, C#, Java, Python e Lua, obviamente há outras. Tal protocolo de rede vem ganhando projeção e se tornando uma ótima opção para integrar o cenário do conjunto de tecnologias de IoT, visto que o padrão comumente utilizado, o HTTP (HyperText Transfer Protocol), contempla severas limitações.
ENTENDENDO PROTOCOLO DE REDES
Uma rede de computadores compreende uma gama de equipamentos distintos, entre os quais podemos elencar desktops, tablets, servidores e quaisquer outros dispositivos que trocam informações entre si e que estejam conectados à rede. Assim para que essa comunicação seja possível, um conjunto de regras constituindo um padrão – protocolos, foi estabelecido. Ou seja, um protocolo de rede é um conjunto de regras e padrões utilizado para possibilitar a comunicação entre dispositivos diferentes. (CASTELUCCI, 2011).
Em suma, inúmeros são os tipos de protocolos os quais se distinguem também pelo tipo de serviço oferecido, uma vez que cada protocolo executa uma determinada tarefa. Juntos estes protocolos formam uma pilha executando uma função macro. Assim, com o propósito de permitir a comunicação entre cliente/servidor, possibilitando dessa forma que a informação trafegue pela web, dois protocolos distintos trabalham juntos, o Transfer Control Protocol – TCP que divide as informações em pacotes e as remonta quando as mesmas chegam ao local de destino, e o Internet Protocol – IP, que responde pelo caminho que essas informações podem seguir.
O protocolo TCP/IP também conhecido como arquitetura TCP/IP é organizado em quatro camadas, a saber, camada de aplicação, camada de transporte, inter rede e camada de interface. A camada de aplicação é o nível em que os usuários utilizam aplicações que interagem com o nível de transporte para enviar e receber dados. Entre as aplicações utilizadas pelos usuários para transferência de arquivos podemos destacar o File Transfer Protocol – FTP; Hiper Text Transfer Protocol – HTTP, que fornece acesso aos conteúdos web e recursos como arquivos de texto, fotos e etc. Este protocolo é adotado pelos navegadores da web, rede de conteúdos interligados através de hipertextos; Simple Mail Transfer Protocol – SMTP e também o Domain Name System – DNS.
Para conhecimento, outro importante modelo é o OSI (Open Systems Interconnection) da ISO (Internation Organization for Standardization), sendo um modelo para o desenvolvimento de padrões para interconexão de sistemas. O modelo OSI possui sete níveis de protocolos, são eles, nível de aplicação, apresentação, sessão, transporte, rede, enlace de dados e a camada física. No entanto, nos concentraremos no modelo TCP/IP, que está diretamente relacionado ao MQTT, objeto do nosso estudo.
Por conseguinte, vimos em nossa primeira postagem Conhecendo o protocolo MQTT que o Message Queue Telemetry Transport é um protocolo baseado na pilha TCP/IP. Então o leitor deve estar se perguntando, “porque não usar serviços da web para conectarmos os dispositivos de IoT, onde a requisição para o envio de dados poderia ser feita por meio de uma solicitação HTTP? O leitor certamente se lembrará que falamos que o HTTP (HyperText Transfer Protocol), contempla severas limitações. Continue a leitura e entenda o porquê.
SERVIÇOS DA WEB vs DISPOSITIVOS DE IOT
Antes, porém, de compreendermos o motivo que faz do protocolo HTTP uma escolha menos viável para sistemas de alto desempenho, vamos, e também apenas para conhecimento apresentar-lhes leitores, o sofisticado modelo usado em sistemas de middleware corporativa, o AMQP (Advanced Message Queuing Protocol), em português, Protocolo de Enfileiramento de Mensagens Avançadas.
Em linhas gerais, o middleware funciona como uma camada oculta de tradução, um software ligando o sistema operacional aos aplicativos nele executados. Neste contexto, o AMQP se insere como um padrão internacional que busca garantir a confiabilidade e a interoperabilidade entre todos os middlewares, permitindo a transmissão eficiente e confiável de dados em tempo real de transações comerciais. No entanto, os mais variados cenários de uso deste protocolo e o rico conjunto de funcionalidades, o torna inadequado para aplicações de IoT que possuem restrições de recursos. Em outras palavras, embora menos sofisticado, o MQTT com sua implementação simples, nem por isso menos segura, que ao contrário é escalável em ambiente de redes instáveis, traz recursos que o tornam uma ótima opção de implementação para sistemas embarcados.
O MQTT é um protocolo de mensagens assíncrono, que por não ocorrer ou se efetivar ao mesmo tempo possibilita que a partir do envio de leituras a rede descubra o caminho e a sincronização ideais para entregar aos dispositivos e serviços de destino. O que não é possível com o protocolo síncrono HTTP.
O protocolo HTTP por ser unidirecional depende do cliente para iniciar a conexão. Em contrapartida, o mesmo não ocorre com as aplicações que envolvem a Internet das Coisas, visto que os sensores e dispositivos de IoT geralmente são clientes, o que significa que não recebem comandos de forma passiva.
Ainda sobre o HTTP, sendo ele um protocolo unidirecional e funcionando de um para um, o custo para transmitir uma mensagem para todos os dispositivos da rede utilizando-o se torna alto, e ainda, o HyperText Transfer Protocol em função dos muitos cabeçalhos e regras é considerado um protocolo pesado.
Assim sendo o que faz do MQTT o protocolo mais indicado para aplicações de IoT? Sem dúvida o seu importante recurso de modelo de aplicação e assinatura, cujo ponto forte é o desacoplamento entre o publish e o subscribe, entenda, desacoplar o publicador, é em suma tornar ambos os elementos independentes, onde um não precisa conhecer o outro. Quais as vantagens desse sistema? Vamos explicar agora, continue com a gente.
MÉTODO PUBLISH/SUBSCRIBER DO MQTT
O modelo Publish/Subscriber, também conhecido como pub/sub, recurso este presente no MQTT é um padrão para troca de mensagens que funciona de forma desacoplada, isso significa que publicador e assinante podem interagir sem que um conheça o outro, basta que ambos conheçam o evento. Podemos entender o modelo pub/sub a partir de elementos do nosso cotidiano, assim, três componentes principais se sobressaem, publicador/canal; evento/publicação; inscrito/assinante.
Considere o canal da MasterWalker Shop no Youtube como o publicador, quando a MasterWalker deseja fazer uma publicação, ela simplesmente publica para quem estiver inscrito, no caso, o assinante, mas não é necessário que o canal conheça cada um dos inscritos. E mesmo se não houver inscritos a publicação será feita. Grosso modo, este modelo compreende um padrão onde criamos um ou mais publicadores e cada um irá possuir um ou mais inscritos. Em nosso exemplo, o evento é a publicação.
O protocolo MQTT define dois tipos de entidades na rede, o message broker que é capaz de gerir as publicações e subscrições e os inúmeros clientes. Em termos técnicos, tem-se o broker, um servidor que recebe todas as mensagens dos clientes e faz o roteamento para os clientes que são relevantes. Por exemplo, quando um elemento da rede deseja receber uma determinada informação, ele a subscreve fazendo uma requisição para o broker, que é o intermediário no processo de comunicação. Nota-se que o broker é um centralizador das informações, o que pode ser considerado um elo de fragilidade. Mas por outro lado, a independência dos elementos, ou seja, o desacoplamento entre as partes comunicantes, é altamente favorável para o universo da Internet das Coisas, sendo então uma das vantagens do MQTT.
Em síntese, o cliente ao se conectar com o broker pode assinar qualquer tópico (topics) de mensagem do broker, os tópicos são o meio de identificação da mensagem.
Entenda tópico como um conceito similar a URL, em que os níveis são separados por barras (“/”). Considere o exemplo de uma rede de sensores onde há a presença de vários sensores de temperatura e umidade, publicando como valor uma payload e identificando as mensagens com tópicos no seguinte formato (FONTE: Embarcados).
As possíveis publicações do exemplo acima poderiam ser:
O cliente publica a mensagem em um tópico, que como já informamos é o meio de identificação da mensagem, portanto, ao publicar a mensagem o cliente a envia juntamente com o tópico ao broker. A função do broker é encaminhar a mensagem a todos os clientes que assinaram esse tópico, mas atente-se, os subscritores podem escolher os tópicos que desejam subscrever.
Observe que as informações surgem de duas áreas diferentes, área 10 e área 20, informações estas que estão sendo geradas por quatro sensores, 5000, 5001, 4000, 4001, cada sensor publica respectivamente temperatura e umidade. Este valor da temperatura ou umidade faz parte dos dados para a carga útil da mensagem, sendo o formato algo dependente da aplicação, uma vez que o MQTT, como já mencionamos, não impõe restrições sobre isso. Por conseguinte, o formato poderia estar em JSON, XML ou mesmo um valor binário de 16bits criptografado. E ainda, um subscritor pode assinar estas mensagens, especificando exatamente o tópico que deseja.
Esperamos que tenham gostado da continuação da nossa série sobre o protocolo MQTT. Em nossa próxima postagem ainda falaremos um pouco mais sobre o método publish/subscriber, ensinaremos como receber informações agrupadas, e muito mais. Fique com a gente e até a próxima postagem.
REFERÊNCIA
CASTELUCCI, Daniella. Protocolos de Comunicação em Redes de Computadores. 2011. Disponível em: <https://bit.ly/2Mpd520>. Acesso em 10 set. 2018.
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.
Postagem anterior: Componentes Ativos – Transistor – Parte 1
Próxima postagem: Como usar com Arduino – Sensor (Detector) de Som – KY-038
Ótima matéria!