Docsity
Docsity

Prepare-se para as provas
Prepare-se para as provas

Estude fácil! Tem muito documento disponível na Docsity


Ganhe pontos para baixar
Ganhe pontos para baixar

Ganhe pontos ajudando outros esrudantes ou compre um plano Premium


Guias e Dicas
Guias e Dicas


Protocolo de comunicação MQTT, Manuais, Projetos, Pesquisas de Desenvolvimento de Aplicações para Internet

Descrição detalhada sobre o protocolo de comunicação MQTT

Tipologia: Manuais, Projetos, Pesquisas

2020

Compartilhado em 23/10/2020

jose-eduardo-sgo
jose-eduardo-sgo 🇧🇷

1 documento

1 / 6

Toggle sidebar

Esta página não é visível na pré-visualização

Não perca as partes importantes!

bg1
Protocolo MQTT
MQTT – Message Queuing Telemetry Transport
“Transporte de Filas de Mensagem de telemetria”
Protocolo de comunicação M2M, criada por Andy Stanford-Clark (IBM) e Arlen Nipper
em 1999, com intuito de conectar sistemas de telemetria de oleodutos via satélite,
liberada gratuitamente em 2010.
Este protocolo possui vantagens sobre HTTP, inicialmente o conceito de districuição
Publisher/Subscriber, possui vários níveis de serviço, com garantia de entrega, tem
foco no transporte e não no conteúdo, tendo maior nível de segurança. No HTTP,
temos envio de dados 1-1, já no MQTT, 1-0, 1-1, 1-N.
MQTT é um protocolo de transporte de mensagens Cliente/Servidor no conceito de
Publicação/Assinatura, ou seja, uma transmissão aprecida com rádio, a emissora
transmite em uma sintonia, e os clientes entram nesta, para receber os dados. Ele é
leve, aberto, simples e projetado para ser de fácil implementação, ideal para uso em
cenários com recursos restritos, comunicações M2M, IoT, cenários em que são
exigidos pacote de dados e/ou largura de banda mínimos.
O protocolo é executado sobre TCP/IP ou sobre outros protocolos de rede que
forneçam conexões bidirecionais ordenadas, sem perda.
Niveis de acesso, adequado à relevância de cada mensagem, segurança alta.
Conceitos
Publisher: Cliente que envia o pacote de dados
Subscriber: Cliente que recebe o pacote de dados
Broker: Recebe dados do Publisher, armazena e distribui aos subscriber
Cliente pode ser Publisher e Subscriber simultaneamente
Não existe identificação do cliente perante o Broker, seja para publicar ou
assinar
Message: Pacote de dados trafegado entre Clientes e Broker
Topic: Repositório de dados único que recebe a Mensagem, acessível aos
clientes, instantâneo e sem histórico
Publish: Ação de enviar ao Broker uma mensagem para um determinado tópico
Subscribe: ação de solicitar receber mensagens de um determinado tópico
Unsuscribe: Ação de solicitar não receber mais mensagens de um determinado
tópico
Payload (Conteúdo) : Dados eniados na mensagem
QoS – Quality of Service
oNível de serviço sob o qual o Broker deve receber e/ou transmitir os
dados
o0 – At most once (No máximo uma vez)
o1 – At least once (Pelo menos uma vez)
o2 – Exactly once (Exatamente uma vez)
Last Will / Will Message (Ultima vontade)
oMensagem a ser enviada pelo Broker caso o Cliente perca a conexão
`Ping : teste periódico entre Cliente e Broker
Session: Período no qual o Cliente está conectado ao Broker
pf3
pf4
pf5

Pré-visualização parcial do texto

Baixe Protocolo de comunicação MQTT e outras Manuais, Projetos, Pesquisas em PDF para Desenvolvimento de Aplicações para Internet, somente na Docsity!

Protocolo MQTT MQTT – Message Queuing Telemetry Transport “Transporte de Filas de Mensagem de telemetria” Protocolo de comunicação M2M, criada por Andy Stanford-Clark (IBM) e Arlen Nipper em 1999, com intuito de conectar sistemas de telemetria de oleodutos via satélite, liberada gratuitamente em 2010. Este protocolo possui vantagens sobre HTTP, inicialmente o conceito de districuição Publisher/Subscriber, possui vários níveis de serviço, com garantia de entrega, tem foco no transporte e não no conteúdo, tendo maior nível de segurança. No HTTP, temos envio de dados 1-1, já no MQTT, 1-0, 1-1, 1-N. MQTT é um protocolo de transporte de mensagens Cliente/Servidor no conceito de Publicação/Assinatura, ou seja, uma transmissão aprecida com rádio, a emissora transmite em uma sintonia, e os clientes entram nesta, para receber os dados. Ele é leve, aberto, simples e projetado para ser de fácil implementação, ideal para uso em cenários com recursos restritos, comunicações M2M, IoT, cenários em que são exigidos pacote de dados e/ou largura de banda mínimos. O protocolo é executado sobre TCP/IP ou sobre outros protocolos de rede que forneçam conexões bidirecionais ordenadas, sem perda. Niveis de acesso, adequado à relevância de cada mensagem, segurança alta. Conceitos  Publisher: Cliente que envia o pacote de dados  Subscriber: Cliente que recebe o pacote de dados  Broker: Recebe dados do Publisher, armazena e distribui aos subscriber  Cliente pode ser Publisher e Subscriber simultaneamente  Não existe identificação do cliente perante o Broker, seja para publicar ou assinar  Message: Pacote de dados trafegado entre Clientes e Broker  Topic: Repositório de dados único que recebe a Mensagem, acessível aos clientes, instantâneo e sem histórico  Publish: Ação de enviar ao Broker uma mensagem para um determinado tópico  Subscribe: ação de solicitar receber mensagens de um determinado tópico  Unsuscribe: Ação de solicitar não receber mais mensagens de um determinado tópico  Payload (Conteúdo) : Dados eniados na mensagem  QoS – Quality of Service o Nível de serviço sob o qual o Broker deve receber e/ou transmitir os dados o 0 – At most once (No máximo uma vez) o 1 – At least once (Pelo menos uma vez) o 2 – Exactly once (Exatamente uma vez)  Last Will / Will Message (Ultima vontade) o Mensagem a ser enviada pelo Broker caso o Cliente perca a conexão  `Ping : teste periódico entre Cliente e Broker  Session: Período no qual o Cliente está conectado ao Broker

 Clean o Indica se a sessão deve ser persistida  Tópicos assinados, mensagens recebidas enquanto o cliente está desconectado. o Ao inciar uma Sessão “limpa”, os dados da Sessão anterior são descartados  Retain: Indica se a Mensagem deve ser mantida pelo Broker, até uma próxima ser recebida MQTT Box  Teste do procotocolo Modelo Publish/Subscribe É uma alternativa ao tradicional modelo Cliente – Servidor, onde o cliente não está conectado diretamente ao servidor/Endpoint. O Publisher ele apenas publica o dado ao broken e não tem informação do cliente, de quantos são, da mesma forma que o subscriber só obtém os dados do broken. Isso faz com que os clientes não tenham contatos entre si e possam ser Publisher, Subscriber ou ambos, já que a comunicação é centrado ao broken. Papel do Broker Cabe ao broker manter o controle dos tópicos criados e assinados, receber todas as publicações, armazena-las nos seus respectivos tópicos e encaminhar para seus assinantes. Ele deve gerenciar a comunicação de acordo com o QoS atribuído, manter as publicações definidas para retenção e enviando para novos clientes, deve manter controle sobre as conexões e desconexões para enviar a will messages, casa tenha sido definida. Por fim, gerenciar toda a segurança. O Broken não manterá histórico de publicação, logo irá descartar a ultima mensagem assim que for entregue a todos subscriber, não terá foco no conteúdo, apenas repassando ele. E por fim não fará gerenciamento de clientes. Caracteristicas da comunicação MQTT Os clientes são alheios uns aos outros, sem conexão física ou lógica, vários publishers podem publicar no tópico e vários subscribers podem assinar o mesmo tópicos. Não á a necessidade de sincronia, ou seja, Publisher e Subscriber executam suas ações em tempos independentes, já o MQTT garante a entrega o mais rápido possível, com foco na entrega não na velocidade. A comunicação é essencialmente assíncrona, tendo que o Publisher apenas publica a mensagem, não se preocupara com sua entrega ( Fire and Forget ) e o subscriber toma conhecimento da Mensagem apenas quando o broken a entrega.

 Exemplos: o Casa/sala/temperatura o Casa/sala/umidade o Casa/sala/arcondicionado/modo  Separador de nível – “/”  Cada nível deve possuir ao menos um caractere  Um separador sozinho é considerado um nível  Coringas: Utilizado apenas em assinaturas(subscribe) o Nível único - “+” : Pode ser utilizado em qualquer nível, correspondendo a qualquer conteúdo  Casa/+/temperatura  Casa/sala/temperatura  Casa/quarto/temperatura o Nível Múltiplo – “#”: Utilizado apenas no final, em qualquer conteúdo e quantidade de níveis:  Casa/#  Casa/sala/temperatura  Casa/quarto/temperatura  Casa/cozinha  Ele recebe todas mensagens enviadas pelo broker Tópicos especiais:  Iniciam com “$” (sifrão)  Não podem receber publicação de Clientes  Não podem ser assinados por Coringas  Não a formaçização de seu uso  Convencionou-se que tópicos iniciando com “$SYS/” fornecem estatísticas internas do broker o $SYS/broker/cliente/total o $SYS/broker/mesage/sent Caracteristicas do QoS  Principal característica do MQTT, define o nível de garantia de entrega de uma mensagem ao subscriber  Impacta diretamente no fluxo de tráfego  O QoS esperado é definido pelo Publisher o Nível máximo de execução do serviço  O QoS no recebimento é definido pelo Subscriber o Nível real de execução do serviço o Pode ser inferior ao definido no Publisher Níveis:  0 – At most once (No máximo uma vez) o Mensagem será entregue até uma única vez o Ou nenhuma... o Ele envia e não espera retorno

o Utilizar em conexões estáveis e perca aceitável  1 – At least once (Pelo menos uma vez) o Mensagem será entregue ao menos uma vez o Pode ocorrer entrega duplicada, triplicada. o Ele vai enviando até receber uma confirmação o Utilizar quando todas as mensagens precisam ser recebidas, mesmo que duplicadas e o tráfego e mensagens aceitáveis do que trafego do QoS 2  2 – Exactly once (Exatamente uma vez) o Mensagem será entregue exatamente uma vez o É enviado, o broker confirma, é enviado uma mensagem e encerramento e o broker confirma o encerramento o Utilizar quando a precisão no recebimento da mensagem é crítico  Para todos os níveis são iguais para qualquer caminho da mensagem Características do Retain  Indica ao Broker para armazenar uma Mensagem  Apenas uma Mensagem com Retain por tópico  Novos Subscribers receberão a mensagem imediatamente  A Mensagem com retains não é necessariamente a ultima do tópico  Para alterar uma mensagem com retain, basta publicar outra com retain, que irá sobrescrever a anterior. Para excluir basta publicar sem conteúdo. Persistência de conexão  Permite ao Broker e ao Client estarem ciente de seu estado de conexão  Quando ocorre uma desconexão o broker encerrra a conexão com o cliente e aceita nova conexão  Cabe ao cliente refazer conexão  Tempo de “Keep Alive” o Definido pelo cliente durante a conexão o Tempo máximo que o Client pode ficar sem enviar mensagem, definido pelo cliente  Requisição PING o Enviada pelo Client ao Broker Sinalizando que o cliente está online o Casa não haja mensagem a ser enviada, o client deve enviar PING antes do tempo de Keep Alive  Tempo máximo de Keep Alive o 18h 12m 15s = 65535 – 2 bytes  Tempo de Keep Alive 0 desabilita o controle de persistência  Responsabilidades o Broker – Desconectar Client e Permitir reconexão o Client – enviar mensagem ou ping em intervalo inferior ao tempo de Keep alive e refazer conexão caso desconecte Última vontade (Last Will Message)  Definida pelo Client durante a conexão