Arquitetura

A arquitetura do MQTT é ilustrada na Figura 4.5. Nota-se que essa arquitetura é implementada sobre o protocolo TCP, o que provê confiabilidade na entrega das mensagens em nível de transporte. Cada mensagem trocada entre os clientes e o broker é encapsulada em uma conexão TCP. O MQTT não especifica nenhuma técnica de roteamento ou rede. Ele simplesmente assume que a rede subjacente fornece um serviço de transporte orientado a sessão, com auto-segmentação e entrega em ordem, empregando esse serviço para a troca de mensagens.

Figura 4.5: Arquitetura do MQTT baseada no protocolo TCP/IP [36]

O modelo comunicação do MQTT requer que cada cliente se conecte ao

broker fornecendo seu próprio identificador único (ID do cliente). Opcionalmente

pode-se utilizar mecanismos de autenticação baseados em usuário e senha, além de criptografia utilizando SSL (Secure Sockets Layer) / TLS (Transport Layer Security), que dependem do suporte oferecido pela implementação da biblioteca cliente e do broker. Quando um cliente não precisa receber quaisquer mensagens por um longo tempo, ele deve enviar periodicamente uma mensagem keep-alive para indicar ao broker que deve manter a conexão ativa, caso contrário o broker irá fechar a conexão após um tempo limite, que é especificado pelo cliente ao se conectar ao broker.

Há várias implementações de clientes e server brokers MQTT disponíveis para diversas linguagens de programação como Java, C, C#, Javascript e Python. Na implementação da solução proposta, por exemplo, utilizou-se o cliente MQTT Eclipse

Paho Android Service 1.0.28_{(versão para Android) e o broker Mosquitto 1.4.5}9_(versão

8_{www.eclipse.org/paho/} 9_{http://mosquitto.org/}

para Linux), sendo ambos livres e de código aberto. O broker Mosquitto tem suporte a autenticação autorização e criptografia. Existem também versões reduzidas de brokers,

voltadas para dispositivos móveis, tais como o Micro Broker Moquette10_{. Esse Micro}

Broker também foi utilizado na implementação da solução proposta (ver Seção 5).

4.3.2 Confiabilidade de Entrega

A confiabilidade de entrega é a única política de QoS provida pelo MQTT, sendo que, em nível de aplicação, esse protocolo oferece três níveis de confiabilidade: QoS 0 (at most once), QoS 1 (at least once), QoS 2 (exactly once).

Uma fragilidade do mecanismo de confiabilidade do MQTT é que as tentativas de retransmissão do publicador só duram enquanto a conexão deste com o

brokerperdurar. Caso a conexão falhe, o cliente deixa de tentar reenviar as mensagens.

Além disso, o buffer de mensagens em trânsito (in-flight) no cliente MQTT é limitado, o que significa que as mensagens mais antigas poderão ser removidas do buffer antes da confirmação de entrega, a fim de dar lugar às mensagens mais recentes [69].

4.3.3 Configuração da QoS

Publicadores e subscritores definem suas configurações de confiabilidade de maneira independente. O publicador escolhe o nível máximo de confiabilidade que está disposto a prover, enquanto que o subscritor escolhe o nível mínimo de

confiabilidade com o qual deseja receber as mensagens. Por exemplo, se uma

mensagem é publicada com QoS 2, mas o subscritor assina o tópico usando QoS 0, então a mensagem será entregue a esse subscritor com QoS 0. Se um segundo subscritor, do mesmo tópico, escolheu a QoS 2, então ele receberá a mesma mensagem que o subscritor anterior, mas com QoS 2. Em outro caso, se o subscritor assina o tópico utilizando QoS 2, mas a mensagem é publicada em QoS 0, então essa mensagem será enviada ao subscritor (podendo não ser entregue) com QoS 0. Portanto, o nível de confiabilidade escolhido pelo subscritor só será atendido se ele for menor ou igual ao nível definido pelo publicador.

4.3 Message Queue Transport Telemetry (MQTT) 80 A escolha do nível de confiabilidade mais adequado para cada aplicação dependerá dos seus requisitos e das características do ambiente de rede. Por exemplo, em cenários em que o ambiente de rede é estável e relativamente confiável, mas uma pequena taxa de perda de dados é aceitável, sendo que as informações são publicadas em intervalos curtos, então a QoS 0 pode ser empregada, visto que o requisito de obter um baixo tempo na transmissão da mensagem é mais importante que o de garantir a entrega a qualquer custo. Em cenários mais instáveis e exigentes, por exemplo, no qual a rede não é confiável mas a perda de dados não é tolerada sob quaisquer circunstâncias, pode-se usar QoS 1 ou QoS 2. A escolha nesse caso dependerá ainda se o recebimento de mensagens duplicadas interfere no bom funcionamento da aplicação.

4.3.4 Sessão Persistente

Quando um cliente se conecta a um broker MQTT, ele precisa criar assinaturas para todos os tópicos de interesse, a fim de receber mensagens do broker. Ao se reconectar, as assinaturas referentes a esses tópicos são perdidas e o cliente precisa se inscrever novamente. Este é o comportamento padrão do broker MQTT. Para evitar que clientes com recursos limitados tenham maiores custos com novas assinaturas a cada reconexão, o protocolo MQTT tem suporte a sessões persistentes que guardam informações de estado do cliente. A sessão é identificada pelo ID fornecido pelo cliente no ato da conexão.

Em sua sessão persistente, o brokerr deve armazenar os seguintes itens:

• ID do cliente, mesmo que não haja assinaturas.

• Assinaturas do cliente;

• Mensagens em trânsito com QoS 1 ou 2 que não foram confirmadas pelo cliente;

• Novas mensagens com QoS 1 ou 2 que o cliente perdeu quando estava off-line;

• Mensagens recebidas com QoS 2 que ainda não foram confirmadas para o cliente;

Isso significa que, mesmo se o cliente for desconectado, todos os itens acima serão armazenados pelo broker e estarão disponíveis logo após ele se reconectar.

Cada cliente do MQTT também deve manter uma sessão persistente do seu lado. Portanto, quando um cliente solicita ao broker que guarde os dados da sessão, ele também tem a responsabilidade de guardar algumas informações localmente:

• Mensagens em trânsito com QoS 1 ou 2 não confirmadas pelo broker;

• Mensagens recebidas com QoS 2 que não foram confirmadas ao broker.

A implementação da sessão persistente varia de acordo com o cliente e o

broker MQTT utilizados. O volume de dados que podem ser armazenados na sessão

dependerá de um conjunto de configurações de conexão tanto do cliente como do broker

4.3.5 Testamento

Outra característica presente no protocolo MQTT é o suporte ao envio de mensagens de testamento (Last Will and Testament - LWT). A LWT é uma mensagem que o cliente opcionalmente pode registrar junto ao broker no estabelecimento da conexão. Ao definir a mensagem LWT, o cliente deve indicar também o tópico no qual ela poderá ser publicada futuramente, denominado Tópico LWT. Caso o cliente se desconecte de forma anormal, ou seja, sem que ele tenha espontaneamente solicitado a desconexão ao broker, a mensagem de testamento será enviada pelo broker para todos os demais clientes ativos que assinaram o tópico LWT correspondente. Clientes podem usar esse recurso para detectar falhas em outros clientes da rede.

4.3.6 Retenção

O mecanismo de retenção do protocolo MQTT consiste simplesmente em manter armazenada no broker a última mensagem publicada de cada tópico. Para que isso aconteça, é necessário que o publicador marque a mensagem a ser enviada como “retained”. Mensagens com essa marcação poderão ser entregues a subscritores atrasados, ou seja, aqueles que assinaram o tópico depois da publicação da mensagem retida pelo broker. Esse mecanismo é útil, por exemplo em situações onde o subscritor atrasado não pode esperar até a próxima publicação para receber uma atualização. É

4.3 Message Queue Transport Telemetry (MQTT) 82 importante ressaltar que a retenção da mensagem por parte do broker não depende e nem tão pouco interfere na confiabilidade com a qual ela será publicada ou recebida.