estudo e analise comparativa de desempenho do protocolo mqtt em redes de banda limitada

Helton Franco de Sousa

Gabriel Cirac Mendes Souza

MQTT:

Estudo e Analise Comparativa de

Desempenho do Protocolo MQTT em

Redes de Banda Limitada

Itajuba - MG

28 de outubro de 2014

Helton Franco de Sousa

Gabriel Cirac Mendes Souza

MQTT:

Estudo e Analise Comparativa de

Desempenho do Protocolo MQTT em

Redes de Banda Limitada

Este e um estudo dirigido do protocoloMessage Queuing Telemetry Transport(MQTT), onde e abordado seu funcio-namento e analizado seu comportamentoem diversos cenarios com limitacao debanda. O presente trabalho traz as me-didas de desempenho do protocolo comrelacao ao tempo de resposta ao cliente,quando este faz uma requisicao de enviode um arquivo.

Orientador:

Prof. Msc. Bruno Tardiole Kuehne

Universidade Federal de Itajuba - UNIFEIInstituto de Engenharia de Sistemas e Tecnologias da Informacao

Engenharia da Computacao

Itajuba - MG

28 de outubro de 2014

Sumário

Lista de Figuras

Resumo

1 Considerações iniciais p. 9

1.1 Introducao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 9

1.2 Objetivo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 12

2 Arquitetura do Protocolo MQTT p. 13

2.1 Funcionalidades do MQTT . . . . . . . . . . . . . . . . . . . . . p. 13

2.1.1 Publish, Subscribe and Topic . . . . . . . . . . . . . . . . p. 13

2.1.2 Identificador do Cliente MQTT . . . . . . . . . . . . . . . p. 14

2.1.3 Assinantes Duraveis e nao duraveis . . . . . . . . . . . . . p. 15

2.1.4 Keep Alive Time . . . . . . . . . . . . . . . . . . . . . . . p. 15

2.1.5 Mensagens Retidas . . . . . . . . . . . . . . . . . . . . . . p. 16

2.1.6 Topicos . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 16

2.2 Broker . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 18

2.3 Autenticacao e Seguranca . . . . . . . . . . . . . . . . . . . . . . p. 18

2.4 Fluxo das mensagens . . . . . . . . . . . . . . . . . . . . . . . . . p. 19

2.5 Assinatura do cliente . . . . . . . . . . . . . . . . . . . . . . . . . p. 19

2.6 Qualidade de Servico (QoS) . . . . . . . . . . . . . . . . . . . . . p. 21

2.7 QoS - Impacto no desempenho . . . . . . . . . . . . . . . . . . . . p. 23

2.8 Formato da Mensagem . . . . . . . . . . . . . . . . . . . . . . . . p. 24

2.9 Message Type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 26

2.10 Consideracoes Finais . . . . . . . . . . . . . . . . . . . . . . . . . p. 27

3 Ambiente de Experimento p. 28

3.1 Consideracoes Iniciais . . . . . . . . . . . . . . . . . . . . . . . . . p. 28

3.2 Consideracoes sobre o Cenario de Experimento . . . . . . . . . . . p. 30

3.3 Fatores . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 30

3.4 Script para Geracao de Carga no Sistema . . . . . . . . . . . . . . p. 32

3.5 Uso do Protocolo . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 33

3.6 Tratamento dos Resultados . . . . . . . . . . . . . . . . . . . . . p. 35

4 Resultados p. 36

4.1 Tempo de resposta por Cliente . . . . . . . . . . . . . . . . . . . . p. 36

4.1.1 QoS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 36

4.1.2 Arquivo . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 38

4.1.3 Razao entre Banda e Tamanho de Arquivo . . . . . . . . . p. 39

4.1.4 Velocidade do Processamento de requisicao . . . . . . . . . p. 43

4.2 Tempo de resposta para conexoes simultaneas . . . . . . . . . . . p. 45

4.2.1 10 Clientes . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 45

4.2.2 100 Clientes . . . . . . . . . . . . . . . . . . . . . . . . . . p. 48

4.2.3 200 Clientes . . . . . . . . . . . . . . . . . . . . . . . . . . p. 52

5 Conclusões e Trabalhos Futuro p. 57

5.1 Conclusoes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 57

5.2 Trabalhos Futuros . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 59

Referências p. 60

Lista de Figuras

1 Publicar uma mensagem para todos os assinantes. . . . . . . . . . p. 14

2 Mensagem retidas. . . . . . . . . . . . . . . . . . . . . . . . . . . p. 16

3 Exemplo de assinatura Multilevel. . . . . . . . . . . . . . . . . . . p. 17

4 Exemplo de assinatura Unilevel. . . . . . . . . . . . . . . . . . . . p. 17

5 Conexao do cliente com o servidor com clean session = 1 . . . . . p. 20

6 Assinando e cancelando assinatura de um topico . . . . . . . . . . p. 21

7 A mensagem enviada pode ou nao chegar ao destino. . . . . . . . p. 22

8 A mensagem enviada certamente chegara ao destinatario, porem

pode chegar duplicada. . . . . . . . . . . . . . . . . . . . . . . . . p. 22

9 A mensagem chega exatamente uma vez. . . . . . . . . . . . . . . p. 23

10 Relacao entre tamanho e perda de pacotes em conexao a cabo. . . p. 25

11 Relacao entre tamanho e perda de pacotes em conexao 3G. . . . . p. 25

12 Cabecalho da mensagem do MQTT . . . . . . . . . . . . . . . . . p. 26

13 Topologia utilizada. . . . . . . . . . . . . . . . . . . . . . . . . . . p. 30

14 Sobreposicao no tempo de envio e resposta quando ha mais de

um cliente se conectando simultaneamente. . . . . . . . . . . . . . p. 32

15 Iniciando o servidor. . . . . . . . . . . . . . . . . . . . . . . . . . p. 34

16 Assinante. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 34

17 Publicando a mensagem. . . . . . . . . . . . . . . . . . . . . . . . p. 34

18 Recebendo a mensagem. . . . . . . . . . . . . . . . . . . . . . . . p. 34

19 Diferenca de tempo entre os nıveis de Qos. . . . . . . . . . . . . . p. 37

20 Diferenca em percentagem em relacao aos nıveis de servico QoS. . p. 38

21 Comparacao do tempo de resposta com relacao a carga enviada

quando nao ocorre limitacao de banda. . . . . . . . . . . . . . . . p. 39

22 Tempo para um unico cliente transferir arquivos de 1 KB, 3 KB,

4 KB, 5 KB e 10 KB em diferentes bandas - utilizando o QoS2. . p. 40

23 Tempo para um unico cliente transferir um arquivo de 10 KB, 50

KB, 100 KB, 150 KB e 200 KB em diferentes bandas - utilizando

o QoS2. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 41

24 Percentagens maiores indicam o quanto o valor ficou abaixo do

teorico. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 42

25 Velocidade em que o dado foi transmitido de acordo com a carga

e a banda disponibilizada. . . . . . . . . . . . . . . . . . . . . . . p. 44

26 Tempo de resposta quando 10 requisicoes sao feitas ao mesmo

tempo para uma carga total de 0.01 MB, 0.03 MB, 0.04 MB, 0.05

MB e 0.1 MB. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 46


tempo para uma carga total 0.1 MB, 0.5 MB, 1 MB e 2 MB. . . . p. 46


teorico. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 47


e a banda disponibilizada para 10 clientes. . . . . . . . . . . . . . p. 48


tempo para uma carga total de 0.1 MB, 0.3 MB, 0.4 MB, 0.5 MB

e 1 MB. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 49


tempo para uma carga total 1 MB, 5 MB, 10 MB, 15 MB e 20 MB. p. 50


teorico. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 51


e a banda disponibilizada para 100 clientes. . . . . . . . . . . . . p. 52


tempo para uma carga total de 0.2 MB, 0.6 MB, 0.8 MB, 1 MB

e 2 MB.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 53


tempo para uma carga total de 2 MB, 10 MB, 20 MB, 30 MB e

40 MB. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 54


teorico. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 55


e a banda disponibilizada para 200 clientes. . . . . . . . . . . . . p. 56

Resumo

Essa monografia apresenta uma descricao do protocolo de comunicacao Mes-sage Queuing Telemetry Transport (MQTT), que vem ganhando um espaco con-sideravel no ambiente IoT(Internet of Things), onde o interesse e conectar dispo-sitivos e hardwares na internet. E abordado o seu funcionamento e analisado ocomportamento do mesmo em situacoes onde a banda e um fator limitante, tantopara conexoes unicas quanto para conexoes simultaneas, sendo assim, verificandose a finalidade ao qual ele foi criado, e atendida satisfatoriamente. O presente tra-balho tem por objetivo fazer uma avaliacao de desempenho do protocolo, variandoa carga a ser transmitida, o numero de clientes que fazem requisicoes de um servicoe a banda disponibilizada.

9

1 Considerações iniciais

1.1 Introdução

Durante as ultimas decadas, e possıvel ver um enorme crescimento no uso

e na complexidade na troca de informacoes nos varios nıveis de arquitetura de

comunicacao. Segundo Venkataram e Manvi (2004), um protocolo de comunicacao

e a gramatica usada por computadores ou dispositivos baseados em computadores

para comunicarem entre si. Em outras palavras, protocolo e um conjunto de regras

que controlam como o conteudo de dados e o controle de informacao sao montados

na fonte e em seguida sao transmitidos atraves de alguma rede e desmontados

em seus destinos, fazendo as entidades usar o mesmo padrao de comunicacao. Os

elementos chaves de um protocolo sao, na maioria das vezes:

• Sintaxe que inclui o formato de dados e o nıvel do sinal; semantica que

controla a informacao e erros;

• Timming que diz respeito ao tempo correspondente;

• Sequencia de controle;

Desde quando a pilha de protocolos TCP/IP foi definida, ela permite a conexao

de dispositivos a diversas redes e com isso uma enorme quantidade de protocolos

foram criados na camada de aplicacao para atender as necessidades de cada cliente,

sendo um deles o MQTT. Basicamente, a maioria dos protocolos seguem a ideia de

fragmentar a informacao em varios pacotes de tamanho relativamente menor, cada

10

um deles, possuindo um cabecalho onde carregam informacoes basicas para troca

de dados. O tamanho desse cabecalho varia de protocolo para protocolo, um grande

numero de bytes no cabecalho pode causar overhead na rede, necessitando assim,

uma largura de banda maior para dar suporte ao devido protocolo. Em ambientes

hostis com conexoes frageis, a largura de banda costuma ser baixa, impossibilitando

o uso geral de um unico protocolo para todos os tipos de comunicacoes. Nesses

cenarios, os dispositivos costumam sofrer frequentemente desconexoes temporarias,

deixando de receber e enviar dados.

Analisando esse problema, foi criado em 1999 o Message Queuing Telemetry

Transport (PIPER, 2013b), um protocolo de mensagens de publicacao e assinatura

(publish/subscribe) open-source, por Dr Andy Stanford-Clark, membro da IBM,

e por Arlen Nipper (LAMPKIN et al., 2012), membro da Eurotech, com a grande

vantagem de ser simples e leve. Esse protocolo foi projetado inicialmente para

operar na telemetria de sistemas crıticos industriais onde os dispositivos estavam

em lugares restritos ou que possuıam largura de banda limitada ou que a entrega

de dados nao era garantida pela rede.

Os princıpios da arquitetura do protocolo foram feitos para minimizar os re-

quisitos da largura de banda, garantir a entrega dos dados a um certo grau de

confiabilidade e ao mesmo tempo, rodar em sistemas embarcados onde existe um

limite de processamento e recursos de memoria.

A escolha de ser open-source, garante que adaptacoes possam ser feitas para

projetos especıficos. O MQTT foi desenvolvido para atuar sobre varios proto-

colos de comunicacao. O principal deles, como dito anteriormente, e a pilha de

protocolos TCP/IP que prove a conexao basica com a internet. Derivacoes do

MQTT foram criadas para trabalharem em outras pilhas de protocolo, como o

MQTT-SN (Message Queuing Telemetry Transport for Sensor Networks) onde a

comunicacao e feita usando radio frequencia (Bluetooh, ZigBee, Xbee, RFID e

outros). A padronizacao do MQTT e feita pela (OASIS, 2014), orgao responsavel

pelo desenvolvimento de especificacoes para protocolos como SOA(Service-oriented

11

architecture), web-services e outras.

Em geral, uma rede baseada no protocolo MQTT e indicada para manejar a

troca de mensagens entre cerca de no maximo 10 mil dispositivos. Para aumen-

tar essa quantidade de usuarios, pode-se adicionar um servidor em modo bridge,

garantindo assim uma boa escalabilidade. Cada cliente se conecta ao servidor,

denominado Broker, onde o usuario tem um ID unico para conexao. O Broker e

responsavel pela aplicacao das regras, conexao de novos clientes e a transferencia

de mensagens entre eles.

Com todos esses recursos o MQTT vem ganhando grandes proporcoes devido

ao crescimento de dispositivos conectados a internet (Internet of Things), onde o

mercado a cada dia exige seguranca e maxima eficiencia, sem deixar de garantir

a entrega da informacao. Devido a esse crescimento, outros protocolos surgiram

para atender essas necessidades, como o COAP, XMPP, AMQP e STOMP. Com

essa diversidade, o autor (PIPER, 2013a) demonstra as vantagens e desvantagens

de cada um deles, para ajudar na escolha do mais adequado para a sua aplicacao.

Um dos protocolos que vem ganhando espaco na area de IoT, e o COAP(Constrained

Application Protocol), que diferente do MQTT, utiliza pacotes UDP para enviar

e receber informacoes. Apesar desse diferenca, a finalidade dos dois protocolos

e a mesma, assim, comparacoes sao feitas, como mostra o trabalho dos autores

(THANGAVEL et al., 2014) e (CARO et al., 2013), onde o primeiro autor utiliza o dois

protocolos em um mesmo Middleware e o segundo autor avalia o comportamento

dos dois protolos em aplicacoes que usam smartphones. Ambos autores simulam a

perca de pacotes utilizando uma ferramenta Wireshark, (WIRESHARK, 2013).

Analisando todos esses trabalhos, percebeu-se a necessidade de simular um

ambiente em que os clientes estao limitados a uma pequena largura de banda e

ao mesmo tempo, avaliar esse desempenho em conexoes simultaneas, o qual esse

trabalho avalia.

12

1.2 Objetivo

O objetivo dessa monografia e fazer um estudo e uma analise de desempenho

do protocolo MQTT. Pretende-se avaliar o comportamento do protocolo quando se

varia o numero de clientes conectados, a carga transferida e qualidade do servico

na entrega das mensagens, podendo assim, verificar onde ao uso do protocolo e

mais viavel ou nao.

13

2 Arquitetura do Protocolo MQTT

Considerando a discussao levada no capıtulo anterior, percebe-se que a garan-

tia na entrega das mensagens e um fator limitante quando se trabalha em redes

com baixa largura de banda, com isso, o MQTT foi desenvolvido para atuar nesses

ambientes hostis e limitados. Neste capıtulo, e descrito com mais detalhes o fun-

cionamento do protocolo MQTT, especificando seus nıveis de seguranca e como e

feita toda a comunicacao entre clientes e servidor.

2.1 Funcionalidades do MQTT

2.1.1 Publish, Subscribe and Topic

O protocolo MQTT e baseado no padrao de publicacao de mensagens e assi-

natura de topicos, tipicamente denominado padrao Publish/Subscribe. O provedor

das informacoes e denominado Publisher e o consumidor desses dados e chamado

Subscriber. O Publisher simplesmente envia as mensagens para o servidor com

um identificador denominado topico, conforme indicado na figura 1. O Broker fica

responsavel por redistribuir todas as mensagens para os clientes que escolheram

ser assinantes daquele topico correspondente.

Esse mecanismo de topico pelo qual os clientes fazem a troca de dados e tecni-

camente uma fila de mensagens. Esse padrao tambem e conhecido como Observer

(Observador), pois o cliente fica na observacao do topico ao qual ele esta inte-

ressado em receber a mensagem. Para o cliente assinante, nao interessa quem

14

Figura 1: Publicar uma mensagem para todos os assinantes.

esta publicando, mas somente a informacao, dando um caracter de relacionamento

unidirecional one-to-one ou one-to-many para o protocolo.

2.1.2 Identificador do Cliente MQTT

O Protocolo MQTT define um identificar unico (client ID) para cada cliente

que se conecta ao Broker. Em resumo, quando um cliente se conecta ao servidor,

ele precisa especificar uma String unica que possa garantir que nao foi e nem

sera usada por outros clientes. Ele restringe o ID com tamanho maximo de 23

caracteres, mas existem situacoes em que o cliente pode encurtar o tamanho do

seu identificador.

Para garantir que o ID seja unico, aproveita-se o endereco MAC que e dife-

rente para cada dispositivo de rede. Mesmo assim, erros podem ocorrer com uso

de identificadores duplicados, logo, executa-se uma sequencia de acoes para o tra-

tamento do mesmo. Toda mensagem e mantida no servidor antes de ser enviada

para os clientes. Existe um recurso opcional no protocolo MQTT onde ele verifica

a lista de identificadores antes de permitir a entrada de um novo cliente, caso o

identificador do cliente novo seja igual a qualquer outro, o Broker pode decidir

em permitir a conexao do novo cliente e a desconexao do antigo ou o bloqueio do

cliente novo e a permissao do cliente antigo.

15

2.1.3 Assinantes Duráveis e não duráveis

Assinantes duraveis sao aqueles clientes que podem receber todas as mensagens

publicadas, incluindo aquelas que foram publicadas quando ele estava desconectado

do Broker. No caso nao-duravel, o Broker nao retransmite as mensagens perdidas

durante o perıodo que o cliente assinante esteve desconectado. Essa funcao e

definida quando o cliente se conecta usando o Flag Clean Session. Esse Flag e

marcado como true quando o cliente faz uma assinatura com os nıveis de seguranca

QoS 1 e QoS 2. Apenas no nıvel QoS 0 que o Flag nao e ativado, os detalhes sobre

os nıveis de QoS serao apresentados na secao 2.8.

2.1.4 Keep Alive Time

Pelo lado do servidor, existe a necessidade que ele saiba quando seus clientes

estao ativos ou nao. Mandar requisicoes para seus clientes perguntando se eles

estao conectados tem um enorme custo operacional quando se trata de milhares

de clientes. Por essa questao, fica como responsabilidade do cliente enviar uma

mensagem em um certo perıodo de tempo, denominado como constante Keep Alive,

dizendo que ainda esta conectado.

Essa situacao e util no caso onde o cliente nao interage mais com o servidor

depois de um certo tempo. Esse tempo Keep Alive e configurado pelo cliente ao se

conectar, informando o valor em milissegundos e o servidor guarda em uma tabela

juntamente com o identificador do cliente. Existem duas mensagens que consti-

tuem na interacao do tempo de Keep Alive, e sao PINGREQ e a PINGRESP. A

mensagem PINGREQ e simplesmente envio de um ping ao servidor e o PINGRESP

e a resposta enviada pelo servidor para o cliente referente ao ping.

Ambas as mensagens sao curtas de tamanho maximo de 2-bytes e elas nao estao

associadas a nenhum nıvel de seguranca QoS. Portanto, existe um temporizador

no cliente que envia a mensagem PINGREQ e so ira disparar outro apos receber

o PINQRESP do servidor. Caso o Broker nao receba o PINQREQ, o cliente e

16

desconectado. O servidor oferece uma carencia para receber o ping que vem do

cliente, adicionando mais 50 por cento de tempo em relacao ao devido Keep Alive.

Por isso, de forma geral, o tempo final que o Broker espera que o cliente envie seu

PING corresponde a : Keep− Alive− Final = 1.5 ∗Keep− Alive− User.

2.1.5 Mensagens Retidas

Outro recurso disponıvel, e a propriedade de uma mensagem ser retida ou nao,

como mostrado na figura 2. Todo Publisher pode marcar a sua devida mensagem

como retida para que os novos Subscribers possam recebe-la no momento de sua

conexao, nao tendo necessidade do Subscribers esperar por uma nova mensagem.

Figura 2: Mensagem retidas.

2.1.6 Tópicos

A distribuicao de mensagens por topicos e organizada como uma arvore onde

cada nıvel e dividido pelo caracter “/” para criar seus sub-nıveis. Topicos podem

conter outros caracteres que ajudam na integracao de um cenario onde um assi-

nante quer obter informacoes de varios topicos combinando alguns padroes. Para

esse tipo de necessidade, foi definido mais dois caracteres especiais no protocolo

MQTT, conhecidos como wildcards que sao utilizados para navegar entre os nıveis

em que o cliente deseja assinar, sao eles o Multilevel e Unilevel.

17

Multilevel: E definido pelo caracter curinga “#” onde e usado para navegar

em todas as combinacoes possıveis do topico pai. Por exemplo, se for assinado o

topico “A/#” por um cliente, significa que esse assinante ira receber as mensagens

de todas as combinacoes de topicos possıveis partindo de A. Sao eles“A/B”,“A/C”,

“A/B/C”, “A/B/D”, “A/C/D” e “A/C/F” conforme figura 3.

Figura 3: Exemplo de assinatura Multilevel.

Unilevel: E definido pelo caracter curinga (+) onde e usado para assinar todas

as combinacoes possıveis de topicos dentro de um unico nıvel. Por exemplo, se

for assinado o topico “A/+/D” por um cliente, significa que esse assinante ira

receber as mensagens de todas as combinacoes de topicos possıveis partindo de A

e terminando em D. Sao eles “A/B/D” e “A/C/D” conforme figura 4.

Figura 4: Exemplo de assinatura Unilevel.

18

2.2 Broker

O Broker e o servidor do MQTT, ele e responsavel por gerenciar os publican-

tes e assinantes, ou seja, ele disponibiliza todos os recursos e servicos para que

as mensagens sejam entregues. Quando um cliente quer enviar uma mensagem

para um topico qualquer, o servidor retransmite a devida mensagens para os seus

respectivos assinantes. O MQTT disponibiliza uma hierarquia de topicos atraves

da palavra $SYS para os clientes acompanharem o status atual do servidor. Esses

topicos sao atualizados de acordo com a constante everysys-interval em segun-

dos, contida no arquivo “mosquitto.conf”. Caso ela seja setada como 0, nenhuma

atualizacao e enviada para os clientes. A seguir tem-se alguns topicos de exemplos:

• $SYS/broker/bytes/received - Retorna o numero de bytes recebidos desde

quando o Broker foi iniciado.

• $SYS/broker/bytes/sent - Retorna o numero de bytes enviados desde quando

o Broker foi iniciado.

2.3 Autenticação e Segurança

O protocolo MQTT tem dois mecanismos de seguranca para autenticacao do

cliente: client ID e user. Quando o cliente se conecta ao servidor, ele possui

uma identificacao unica dentre todos os clientes, como sitado no item 2.4.2. Alem

do mais, a mensagem de autenticacao pode conter um username e um password

para identificacao do cliente. Lembrando que o MQTT nao possui uma camada

de seguranca propria, ou seja, ele utiliza a camada do TCP/IP, assim, pode-se

usar a criptografia de dados atraves da rede, por exemplo, usando SSL/TLS onde

utiliza-se certificados para autenticacao, o que e mais seguro e melhor do que um

simples username/password. Tambem pode-se usar uma camada de aplicacao do

proprio MQTT para fazer a criptografia das mensagens lancando mao dos recursos

SSL/TLS.

19

2.4 Fluxo das mensagens

Para melhor entendimento do protocolo MQTT, e interessante estudar o fluxo

de mensagens entre clientes e servidor. Existem quatro tipos de situacoes que

podem ocorrer, o cliente pode:

• Assinar um topico e receber mensagens dessa assinatura.

• Publicar uma mensagem em um topico.

• Manter a conexao viva entre o cliente e o servidor.

• Fechar a conexao.

Quando o cliente se conecta com o servidor, ele envia a mensagem CONNECT

e o servidor responde com a mensagem CONNACK. Apos a conexao, inicia-se uma

nova sessao e o cliente pode assinar um ou mais topicos dentro dessa sessao. A

mensagem CONNECT possui o Flag Clean Session citado no item 2.4.3, o que

garante que o cliente nao perca todas as assinaturas quando se desconectar do

servidor. Caso o Flag Clean Session seja marcado como verdadeiro, as assinaturas

sao validas somente dentro daquela sessao, ou seja, caso o cliente se desconecte

sem se desfazer de todos os topicos, o servidor ira cancelar a assinatura dos topicos

na proxima conexao do cliente. A figura 5 mostra com mais detalhes todo esse

processo.

2.5 Assinatura do cliente

Na assinatura do cliente, ele apenas envia uma mensagem SUBSCRIBE indi-

cando o topico que ele deseja assinar e caso ele obtenha sucesso, o cliente recebe

uma mensagem SUBACK do servidor, a partir desse momento, o cliente recebera

todas as mensagens relativas ao topico que ele assinou ate o momento em que

ele cancele a assinatura com a mensagem UNSUBSCRIBE e receba a confirmacao

20

Figura 5: Conexao do cliente com o servidor com clean session = 1

com a mensagem UNSUBACK do servidor. Quando o cliente nao envia nenhuma

mensagem na rede, e necessario manter a conexao ativa usando mensagens de ping

para evitar que o servidor feche as conexoes, assim o cliente envia a mensagem

PINGREQ e recebe do servidor uma mensagem PINGRESP. A mensagem final

do MQTT e a DISCONNECT, que faz a requisicao para que o servidor desligue

o cliente de sua assinatura, conforme a figura 6. Se ele nao receber uma resposta,

ele se desconecta em um tempo limite. Um recurso interessante do MQTT sao as

mensagens denominadas will. Quando o cliente se conecta usando essa opcao, o

servidor guarda essa informacao e no caso em que o cliente seja desconectado sem

mandar a mensagem DISCONNECT, o servidor automaticamente avisa os outros

assinantes que houve uma desconexao inesperada por parte do primeiro assinante.

21

Figura 6: Assinando e cancelando assinatura de um topico

2.6 Qualidade de Serviço (QoS)

Segundo o site Embedded101 (2013), o MQTT define tres nıveis de qualidade

na entrega de mensagens, onde cada nıvel possui os seus respectivos metodos para

garantir que a qualidade do servico de entrega seja atendida. Lembrando que o

protocolo e baseado na pilha TCP/IP, o que garante a entrega da mensagem mas

nao garante perdas caso a conexao com a rede venha a falhar. Quanto mais alto o

nıvel, mais recursos sao necessarios.

QoS Level 0 (At most once): Neste caso, o MQTT apenas envia a mensa-

gem sem a garantia de entrega. A mensagem pode chegar ou nao ao seu destino

conforme figura 7.

22

Figura 7: A mensagem enviada pode ou nao chegar ao destino.

QoS Level 1 (At lest once ): Neste nıvel, o MQTT garante que a mensagem

chegue aos assinantes, porem, ela pode ser enviada mais de uma vez conforme

figura 8.

Figura 8: A mensagem enviada certamente chegara ao destinatario, porem pode

chegar duplicada.

23

QoS Level 2 (Exactly once): Neste caso, a mensagem chega para os assinantes

apenas uma vez. Assim, o gasto com recursos e maximo ou seja existe um overhead

e o servidor necessita guardar a mensagem localmente conforme figura 9.

Figura 9: A mensagem chega exatamente uma vez.

2.7 QoS - Impacto no desempenho

De acordo com Lampkin et al. (2012), existe uma regra clara quanto ao impacto

de desempenho relacionado ao nıvel QoS. Quanto maior for o nıvel, maior sera o

tempo gasto para a entrega da mensagem. Considerando que o tempo que se

leva para publicar uma mensagem seja pt, se o QoS for usado para publicar N

mensagens, o tempo levado sera Npt. Agora, no caso do QoS 1, tem-se uma

24

mensagem a mais, que e a resposta do servidor para o cliente e contem apenas 2

bytes. Denomina-se o tempo de resposta dessa mensagem por mt. Assim sendo, o

tempo necessario levado para N mensagens sera N(pt + mt). Analisa-se agora o

QoS 2, que utiliza outras tres mensagens de controle, tendo um tempo aproximado

de (pt + 3mt) para o envio de uma mensagem e N(pt + 3mt) para o envio de N

mensagens com esse nıvel QoS. Entao, se 10 mensagens sao enviadas e tem-se um

caso onde pt e 1.0 segundo e mt equivale a 0.4 segundos, assim, substituindo na

formula para cada caso, obtem-se os seguintes tempos hipoteticos:

• QoS 0: 10 segundos



Comparando a perda de pacotes em relacao ao nıvel QoS, segundo Lee et al.

(2013), para pacotes de ate 4,000 bytes a perda utilizando uma conexao a cabo e

praticamente zero, como mostrado na figura 10 (LEE et al., 2013), porem, ha um

acrescimo significativo na perda para pacotes acima do tamanho citado.

Em um cenario onde a conexao e atraves de telefonia movel, existe uma breve

perda de pacotes, mas o tamanho do pacote nao influencia significativamente na

perda, conforme figura 11 (LEE et al., 2013).

2.8 Formato da Mensagem

O cabecalho da mensagem do protocolo MQTT carrega uma quantidade de

informacoes necessarias, para o controle do proprio. O protocolo pode adotar

cabecalhos de tamanho variavel, dependendo da aplicacao. No caso do MQTT, o

cabecalho tem um tamanho fixo, de acordo com a ilustracao da figura 12.

25

Figura 10: Relacao entre tamanho e perda de pacotes em conexao a cabo.

Figura 11: Relacao entre tamanho e perda de pacotes em conexao 3G.

26

7 6 5 4 3 2 1 0

Byte 1

Byte 2

QoS Level RETAIN

Remaining Length

Figura 12: Cabecalho da mensagem do MQTT

2.9 Message Type

As mensagens trocadas entre cliente e servidor variam em diversos tipos, sendo

que cada uma tem sua finalidade. O protocolo MQTT usa os bits 4,5, 6 e 7

do cabecalho para conter o tipo de mensagem que o protocolo esta enviando no

momento. Os tipos possıveis sao:

CONNECT: A carga de informacao contida nessa mensagem pode ser uma ou

tres strings com codificacao UTF-8. A primeira string apenas identifica o cliente

para o servidor o qual ele esta se conectando. A segunda string e o topico Will e

a terceira strings e a mensagem Will. A terceira e a segunda string so vai estar

presente se o flag will for marcada como TRUE na mensagem CONNECT.

CONNACK: Reconhece um pedido de conexao. E uma mensagem enviada do

servidor ao cliente em resposta a um pedido CONNECT.

SUBSCRIBE: A carga dessa mensagem contem a lista de topicos que o cliente

pode assinar e o nıvel QoS utilizado nesta assinatura. Utiliza codificacao UTF.

SUBACK: Esta mensagem contem as listas de nıveis QoS que o administrador

do servidor permite ao cliente utilizar em sua assinatura.

PINGREQ: E um pedido de PING. Utilizado para sinalizar que o cliente esta

ativo.

PUBLISH: E a mensagem que faz o pedido de publicacao. E enviada do cliente

para o servidor e cada mensagem desse tipo esta associada a um topico para poder

diferenciar o destino e os interessados em recebe-la.

27

PUBACK: Reconhece um PUBLISH. E uma resposta a uma mensagem PU-

BLISH. E e enviada pelo servidor para o cliente.

PUBCOMP: Assegura que a publicacao foi feita. Esta mensagem e uma res-

posta do servidor para o cliente em face a mensagem PUBREL, isso assegura ao

cliente que a mensagem PUBLISH foi executada com exito.

PUBREC: Assegura que a publicacao foi recebida. A mensagem PUBREC e

uma resposta a mensagem PUBLISH quando se usa o QoS2. Ela e enviada do

servidor para o cliente dizendo que a mensagem chegou corretamente.

PUBREL: E uma resposta a mensagem PUBREC. E a terceira mensagem do

QoS2.

UNSUBSCRIBE: Pedido do cliente para cancelar determinado topico. Ela e

enviada do cliente para o servidor.

UNSUBACK: O servidor reconhece um pedido para cancelar uma assinatura.

Ela e enviada do servidor para o cliente em resposta a uma mensagem de UN-

SUBSCRIBE.

DISCONNECT: Esta e a mensagem de notificacao de desconexao. Ela e envi-

ada do cliente para o servidor para notificar que esta prestes a encerrar a conexao.

Isso permite que a desconexao seja limpa, ou seja, nao seja uma queda de conexao

inesperada.

2.10 Considerações Finais

Pode-se perceber, pelo que foi apresentado no presente capıtulo, que o proto-

colo MQTT tem um sistema de gerenciamento de mensagens simples e robusto,

motivo que o torna amplamente utilizado no mercado. Entendendo melhor do

funcionamento do protocolo, pode-se criar uma metodologia para testa-lo e extrair

informacoes a respeito do seu desempenho, que e o assunto do capıtulo seguinte.

28

3 Ambiente de Experimento

3.1 Considerações Iniciais

Conforme mencionado no Capıtulo 1, o objetivo da presente dissertacao e

avaliar o desempenho do protocolo MQTT em ambientes diversos onde a banda

pode ser um fator limitante, variando tambem o QoS (Quality of Service), numero

de usuarios e tamanho do arquivo a ser enviado. O objetivo desse capıtulo e

apresentar a metodologia utilizada nos testes do protocolo, os fatores que foram

levados em consideracao para obtencao dos resultados e o ambiente onde esses

teste foram realizados.

Na definicao dos testes, relevou-se a importancia de verificar o impacto quando

nao ha limitacao de banda, variando somente o QoS e o tamanho do arquivo.

Foram criados entao, diversos cenarios, assim, com os dados obtidos, pode-se fazer

uma avaliacao do protocolo e extrair diversas informacoes, com as quais, e possıvel

dizer onde o uso do MQTT e mais viavel. Os testes sao divididos em duas linhas

frontais de interesse:

• Tempo de resposta por cliente - Analisar o tempo de resposta, quando

um unico cliente executa um processo de envio para o servidor. A contagem

do tempo e iniciada quando o processo e disparado do cliente e termina

quando o proprio recebe uma confirmacao do servidor.

• Tempo de resposta total - Avaliar o comportamento quando varios clien-

tes se conectam a um unico broker, enviando dados e analisar o throughput

29

(quantidade de requisicoes atendidas em determinado intervalo de tempo)

atraves de conexoes simultaneas. O tempo coletado se inicia quando o pri-

meiro cliente se conecta ao servidor e termina quando o ultimo cliente recebe

a resposta de confirmacao vinda do servidor.

Para o ambiente de teste, utilizou-se o laboratorio Cluster da UNIFEI, con-

tendo as seguintes configuracoes:

• Maquinas Quad-core com sistema operacional CentOS 6.2 equipadas com

placas de rede Realtek Semiconductor RTL8111/8168/8411, usando cabos

de rede CAT-6 - com capacidade de 1000Mbps de transmissao de dados.

• Utilizou-se tres computadores para os testes. Um computador foi utilizado

como servidor, recebendo e redirecionando as mensagens. Um computador

assumiu a responsabilidade do publicante, onde era possıvel fazer publicacoes

simultaneas aumentando o numero de threads e finalmente a ultima maquina

como assinante, onde era possıvel criar varios assinantes simultaneos.

• Limitador de Banda Trickle - Utilizado para poder variar a banda disponı-

vel para cada cliente durante o envio de um arquivo para o servidor. O

programa controla o limite de download e upload atraves do gerenciamento

da quantidade de dados que e lido e escrito no socket, usando uma versao

alternativa da API do BSD Socket.

• Mosquitto 3.1.1 - Versao do MQTT usado tanto como cliente e servidor.

A escolha do Mosquitto se deu pela finalidade e facilidade do uso. Outros

servidores open-source sao disponıveis, como RabbitMQ (COMPANY, 2014) e Paho

(FOUNDATION, 2014).

A figura 13 mostra a topologia implementada para avaliar o desempenho do

protocolo em funcao dos varios fatores a serem alterados.

30

Figura 13: Topologia utilizada.

3.2 Considerações sobre o Cenário de Experimento

Inicialmente, o planejamento foi feito com o interesse de simular ao maximo

ambientes hostis para qual o protocolo foi desenvolvido. Nas primeiras fases dos

experimentos, usou-se um pequeno computador de bordo bem conhecido na area

de embarcados, Raspberry Pi, como cliente, mas logo percebeu-se a incapacidade

do hardware e software de gerenciar o envio dos varios clientes, entao usou-se uma

maquina Quad-Core para simular as conexao simultaneas.

Em seguida, outro fator limitante foi a rede. Ao decorrer dos experimentos, a

quantidade de dados transferidos chegou a uma taxa maior do que o proprio hard-

ware conseguia transportar, no entanto, passou-se a usar cabos do tipo CAT-6 em

vez dos convencionais cabos CAT-5 que chegam ao limite de 100Mbps .Consequen-

temente, foi necessario atualizar os drivers das placas de rede para que suportassem

a velocidade de 1000Mbps oferecida pelo cabo CAT-6.

3.3 Fatores

A cada dia, existe uma forte tendencia de minimizar os custos computacionais

dos clientes e ao mesmo tempo garantir uma confiabilidade alta do sistema na

31

entrega dos dados, por isso, a primeira linha de testes analisa o tempo de envio e

resposta do dado ao servidor.

Inicialmente, no presente trabalho, escolheu-se quatro fatores que podem in-

fluenciar diretamente nesse tempo de resposta.

QoS - (Quality of Service): Como mencionado no item 2.2, ha tres nıveis

que definem a qualidade da entrega das mensagens. Como cada um possui em

sua arquitetura um conjunto de mensagens necessarias para operacao de envio,

decidiu-se medir o quanto cada nıvel impacta no tempo de resposta ao cliente.

Bandwidth : Como um dos principais fatores da criacao do protocolo MQTT

foi aumentar o desempenho em redes hostis e limitadas, escolheu-se variar a lar-

gura de banda para aproximar-se ao maximo de uma situacao real . Escolheu-se

disponibilizar para cada cliente as bandas de tamanho: 50 KB/s, 100 KB/s, 200

KB/s, 500 KB/s, 750KB/s e 1MB/s

Tamanho do Arquivo: Assim como em aplicacoes reais, o tamanho de um

arquivo em uma mensagem e variavel, portanto, decidiu-se analisar o impacto ao

usar diferentes tamanhos de arquivos junto a cada mensagem publicada. Foram

utilizados arquivos de 1KB, 3KB, 5KB, 50KB, 100KB, 150KB e 200KB.

Numero de Clientes Assinantes e Publicadores: O numero de clientes

foi um fator determinante para a divisao das duas linhas frontais de testes, onde, na

primeira utiliza-se conexao individual que possibilita avaliar o tempo de resposta.

Ja na segunda linha de testes, utiliza-se conexoes simultaneas com 10, 100 e 200

clientes e podendo assim avaliar o desempenho e a capacidade do servidor de

atender todas as requisicoes simultaneamente, assim como uma aplicacao real.

Pode-se observar que nessa segunda linha de testes, onde e feita a simulacao

de varios clientes, nao e possıvel analisar o tempo de resposta de cada processo

individualmente utilizando o modelo de testes proposto, pois ha uma concorrencia

entre os processos, como ilustrado na figura 14, impossibilitando a escrita no ar-

quivo de saıda. Para trabalhos futuros, pretende-se utilizar um servico de banco

32

de dados, que gerencie essa concorrencia e, dessa maneira, seja possıvel obter mais

um dado para a pesquisa.

Figura 14: Sobreposicao no tempo de envio e resposta quando ha mais de umcliente se conectando simultaneamente.

3.4 Script para Geração de Carga no Sistema

Considerando os fatores acima citados, tem-se 3 nıveis QoS, 6 valores de Lar-

gura de Banda, 4 quantidade de clientes e 7 nıveis para tamanhos de arquivo. Essa

combinacao gera um total de 504 testes. Para se alcancar um otimo resultado, foi

executado pelo menos 10 vezes cada teste, com isso chegou-se a um total de 5040

execucoes. Para facilitar, criou-se entao um prototipo generico de um script, onde

era possıvel fazer os diversos testes em sequencia, conforme a estrutura abaixo

listada.

1 for contador2 in {1..10}

2 do

3 inicio=$(date +"%s%N")

4 for contador in {1..N}

5 do

6 trickle -s -d D -u U mosquitto_pub -h 192.168.1.10

-q Q -f A -t sensor/temp &

7 done

8 wait $!

33

9 fim=$(date +"%s%N")

10 resultado=$(($fim -$inicio))

11 echo $resultado >> Dados.ods

12 done

13 wait $!

• Linha 1: Loop usado para repetir o teste 10 vezes.

• Linha 3: Guarda o tempo inicial do teste em nanosegundos na variavel inicio.

• Linha 4: Loop usado para determinar o numero clientes que se conectam

simultaneamento no servidor onde N e numero de clientes.

• Linha 6: Esta linha e dividida em dois comandos. O comando trickle invoca o

limitador de banda para o processo mosquitto pub, onde D e U correspondem

a taxa de Download e Upload respectivamente. O comando mosquitto pub

fica responsavel por publicar a mensagem onde Q corresponde a qualidade de

servico (QoS) e A o arquivo a ser enviado. O trecho sensor/temp corresponde

ao topico hipotetico ao qual queremos publicar.

• Linha 9: O codigo wait $! faz com que o codigo so prossiga apos o termino

de todos os processos descritos pelo caracter &, descrito no final da linha 6.

• Linha 10: Guarda o tempo final do teste na variavel fim.

• Linha 11: A diferenca e calculada e armazenada na variavel resultado.

• Linha 12: O resultado e salvo no arquivo Dados.ods

3.5 Uso do Protocolo

Para que o leitor possa entender como se usa o protocolo, aqui sera deixado um

exemplo. No caso, um publicante envia uma mensagem para o topico hipotetico

34

sensor/temp e o servidor recebe essa mensagem e envia para os clientes assinantes.

Primeiro liga-se o servidor com o comando da figura 15.

Figura 15: Iniciando o servidor.

Em seguida inicia-se um cliente para assinar o topico sensor/temp na maquina

local com o comando da figura 16.

Figura 16: Assinante.

Agora um publicante deve enviar uma mensagem para o respectivo topico na

maquina local com o comando da figura 17.

Figura 17: Publicando a mensagem.

E finalmente o cliente assinante recebe a mensagem conforme a figura 18.

Figura 18: Recebendo a mensagem.

35

3.6 Tratamento dos Resultados

Para aumentar a confiabilidade dos resultados, cada teste foi repetido dez

vezes e adotou-se um nıvel de significancia de 0,05 para calcular o intervalo de

confianca, ou seja, 95% de confianca. Com a metodologia descrita acima, iniciou-

se os testes, no laboratorio Cluster. Os resultados obtidos foram analisados e serao

apresentados no capıtulo seguinte.

36

4 Resultados

4.1 Tempo de resposta por Cliente

Os resultados obtidos a seguir iveram como objetivo, avaliar o tempo de res-

posta do cliente Publicador variando tres fatores: QoS, Tamanho do Arquivo e o

Tamanho da Banda.

4.1.1 QoS

Cada nıvel de QoS e composto por um conjunto personalizado de instrucoes,

com a justificativa de oferecer diferentes tipos de qualidade na entrega de men-

sagens. Alem das instrucoes, o cabecalho da mensagem varia para cada nıvel,

alterando tambem a quantidade de dados transmitidos na rede. O atual experi-

mento tem como objetivo avaliar o quanto cada nıvel de QoS impacta no tempo

de resposta. Nesse caso, variou-se apenas o tamanho do arquivo enviado, deixando

o tamanho da banda com seu valor maximo de 1 GigaByte. Conforme o grafico

da figura 19 percebe-se que o MQTT praticamente atende os requisitos teoricos

mencionados no primeiro capıtulo, ou seja, quanto maior o QoS utilizado mais

recursos sao necessarios e consequentemente mais tempo e gasto para transmissao

de um arquivo. Apesar do QoS2 consumir mais recursos do que o QoS1 eles estao

estatisticamente empatados.

37

Figura 19: Diferenca de tempo entre os nıveis de Qos.

A diferenca de tempo e mais visıvel quanto maior a carga do arquivo anexo a

mensagem. Analisando o grafico da figura 20, que utiliza o QoS0 como base de

comparacao, percebe-se uma diferenca de 2% ate 7% quando comparado com o

QoS1 e de 3% ate 9%, quando a comparacao e feita com o QoS2.

38

Figura 20: Diferenca em percentagem em relacao aos nıveis de servico QoS.

4.1.2 Arquivo

Como a diferenca observada entre os QoS foi de no maximo 9%, adotou-se

o QoS2 como padrao para analizar o impacto do tamanho do arquivo no tempo

de resposta quando nao ha restricoes de banda. Com isso, obteve-se o grafico da

figura 21.

39

Figura 21: Comparacao do tempo de resposta com relacao a carga enviada quando

nao ocorre limitacao de banda.

Pode-se perceber que quando a banda nao e um fator limitante e o interesse

esta apenas no tamanho do arquivo, nao ha um incremento significativo no tempo

de resposta, apenas a partir de uma carga de 50 KB o aumento no tempo e signi-

ficativo.

4.1.3 Razão entre Banda e Tamanho de Arquivo

Um dos objetivos do atual trabalho e avaliar o MQTT em ambientes onde a

banda pode ser um fator limitante, com isso, decidiu-se variar a banda disponıvel

para cada processo e assim analisar a influencia em relacao ao tamanho do arquivo

enviado. Apos os dados serem coletados, foi possıvel verificar:

• O tempo de resposta;

• A taxa de transferencia real, verificando se a devida banda foi totalmente

40

utilizada pelo processo;

• Percentagem da velocidade utilizada em relacao ao teorico, verificando se

o incremento de banda corresponde ao incremento real na transferencia do

arquivo.

Para todos os itens citados anteriormente, usou-se o QoS2, pois a diferenca

de resultados entre os demais nıveis eram mınimos e a maioria das aplicacoes que

utilizam o MQTT usam esse nıvel de servico. Apenas um cliente foi usado para

esse teste, assim, futuramente pode-se avaliar e comparar o desempenho do servidor

com conexoes simultaneas analisando o tempo de resposta separadamente. Para

o seguinte teste, dividiu-se o grafico em dois para facilitar a leitura. Nos graficos

da figura 22 e figura 23 tem-se o tempo de resposta quando varia-se a banda e o

tamanho do arquivo.

Figura 22: Tempo para um unico cliente transferir arquivos de 1 KB, 3 KB, 4 KB,

5 KB e 10 KB em diferentes bandas - utilizando o QoS2.

41

Apesar das bandas com valores mais altos terem um tempo de resposta me-

lhor, para arquivos com carga ate 10 KB percebe-se que o tempo de resposta em

segundos nao e influenciado significativamente pela banda.

Figura 23: Tempo para um unico cliente transferir um arquivo de 10 KB, 50 KB,

100 KB, 150 KB e 200 KB em diferentes bandas - utilizando o QoS2.

No caso de arquivos com carga de 10 KB ate 200 KB, percebe-se que o incre-

mento na banda influencia relativamente no tempo de resposta. Considerando os

dados obtidos, analisou-se a afirmacao da seguinte hipotese:

• Dobrar a banda implica em obter um tempo de resposta pela metade

Para analise da afirmacao acima, utilizou-se a banda de 50 KB/s como referen-

cia, ou seja, a partir dos resultados obtidos com a banda de 50 KB/s, comparou-se

os resultados com as demais bandas e assim descrevendo o grau de lentidao em

percentagem em relacao ao teorico. Para melhorar o entendimento do grafico, o

42

objetivo fica claro ao citar o seguinte exemplo, onde, se um arquivo de 1KB de-

mora 2 segundos para ser transmitido pela banda de 50KB/s, espera-se que ele

gaste apenas 1 segundo para ser transmitido pela banda de 100KB/s.

Figura 24: Percentagens maiores indicam o quanto o valor ficou abaixo do teorico.

Quando e disponibilizado para um servico uma dada banda, espera-se que todo

esse recurso disponibilizado seja utilizado quando requisitado, ou seja, se ha uma

banda de 1 MB/s esta disponıvel para um recurso e este necessite utiliza-la para

a transferencia de um arquivo, espera-se que essa transmissao seja realizada na

velocidade citada acima, ou seja, a velocidade teorica e a velocidade total disponi-

bilizada para o servico. O grafico da figura 24 mostra o quanto uma transferencia

e mais lenta do que a teorica, assim, um ponto com 500% significa que o dado

foi transferido 5 vezes mais lento do que o esperado. Analisando os resultados,

43

percebe-se que, quando ocorre um aumento na banda, melhora-se o tempo de res-

posta, porem, essa melhora so satisfaz parcialmente a hipotese citada, quando o

tamanho do arquivo e maior ou igual a 50 KB, pois nesse ponto o arquivo comeca

a ser igual ou maior que as bandas disponibilizadas.

4.1.4 Velocidade do Processamento de requisição

Aplicacoes que utilizam requisicao por uso de servidores dependem muitas

vezes da qualidade do servico prestado. O hardware utilizado nessas maquinas

costuma ser robusto para que a velocidade de processamento seja maior ou igual a

velocidade de transmissao da rede, fazendo com que nao ocorra atrasos no tempo

de resposta ao cliente. Nesse atual experimento, o interesse e verificar a capacidade

do protocolo MQTT de gerenciar essas requisicoes. Inicialmente o teste se da pelo

uso de apenas um usuario publicante e um assinante, o grafico da figura 25 mostra

os detalhes desse resultado.

44

Figura 25: Velocidade em que o dado foi transmitido de acordo com a carga e a

banda disponibilizada.

Percebe-se, pelo grafico, que o protocolo MQTT responde satisfatoriamente ao

processo de requisicao para as bandas fornecidas quando o arquivo e maior que

50KB, ou seja, a velocidade de processamento de arquivos maiores que 50KB e

consideravelmente correspondente a velocidade de transmissao.

E intuitivo inferir que arquivos com cargas menores sejam transferidos a uma

taxa de transferencia maior, porem percebe-se que quanto maior o arquivo, maior

e a taxa de transferencia disponibilizada para o processo. Isso se da pela quebra

de pacotes do protocolo TCP, onde sao divididos em quantidade maiores e podem

ser simultaneamente enviados atraves da rede.

45

4.2 Tempo de resposta para conexões simultâneas

O interesse dessa linha de frente e avaliar a capacidade do servidor de atender a

diversas conexoes ao mesmo tempo. Para esses testes, foram criados tres cenarios

onde variou-se o numero de clientes. Para cada quantidade N de publicadores,

utilizou-se a mesma quantidade de assinantes, onde N e igual a 10, 100 e 200

usuarios. Separou-se os testes em tres etapas. Novamente, adotou-se para os

proximos testes, o nıvel QoS2 pois a diferenca notada entre os demais nıveis nao

foi tao significativa.

4.2.1 10 Clientes

Para esse teste, o servidor teve que atender 10 requisicoes simultaneas dos

publicadores e fornecer a resposta para 10 assinantes. No ambiente atual, variou-se

apenas a banda dos usuarios publicadores, mantendo os assinantes sem restricoes.

Com o intuito de obter mais resultados, o tamanho do arquivo foi alterado para

cada teste.

Os graficos da figura 26 e figura 27 tratam-se do tempo resposta para 10

usuarios enviar arquivos de 1 KB, 3 KB, 4 KB, 5 KB, 10 KB, 50 KB, 100 KB e

200 KB gerando uma carga total de 0.01 MB, 0.03 MB, 0.04 MB, 0.05 MB, 0.1

MB, 0.5 MB, 1 MB e 2 MB respectivamete. As bandas utilizadas foram as mesmas

dos testes anteriores, que somadas para o numero de 10 usuarios chegam ao total

de 0.5 MB/s, 1 MB/s, 2 MB/s, 3 MB/s, 5 MB/s, 7.5 MB/s e 10 MB/s.

46

Figura 26: Tempo de resposta quando 10 requisicoes sao feitas ao mesmo tempo

para uma carga total de 0.01 MB, 0.03 MB, 0.04 MB, 0.05 MB e 0.1 MB.


para uma carga total 0.1 MB, 0.5 MB, 1 MB e 2 MB.

47

Comparando os resultados atuais com os obtidos no item 4.1.3, onde se faz o

uso de apenas um usuario, percebe-se que o protocolo responde de forma similar,

mostrando um otima desempenho no caso de 10 conexoes simultaneas. Conse-

quentemente, o grafico da figura 28, que mostra a razao entre o tempo de resposta

das bandas usando 50 KB/s como referencia, demonstrou-se com valores similares

ao caso de um cliente.


No grafico da figura 29 foi analizado a velocidade em que os dados foram

transmitidos, e dessa vez, os resultados obtidos tiveram um resultado abaixo do

esperado, porem, percebe-se que o protocolo MQTT responde satisfatoriamente

ao processo de requisicao para as bandas fornecidas quando o arquivo e maior que

50KB, ou seja, e capaz de utilizar quase totalmente a banda fornecida. Como

foram utilizados 10 clientes para o experimento, os valores do grafico se encontram

em MegaBytes.

48


banda disponibilizada para 10 clientes.

4.2.2 100 Clientes

Nesse proximo experimento, o objetivo e sobrecarregar ainda mais o servidor

com um total de 100 usuarios publicantes. E importante relembrar que antes

do inıcio do teste, foram acionados 100 assinantes que ficararam responsaveis de

receber os dados publicados. Para o teste do tempo de resposta, obteve-se os

seguintes graficos da figura 34 e figura 35. As bandas totais mencionadas no

grafico sao bandas virtuais, onde foi disponibilizado no maximo 1 MB/s para cada

processo, totalizando 100 MB/s para o caso mais robusto.

49


para uma carga total de 0.1 MB, 0.3 MB, 0.4 MB, 0.5 MB e 1 MB.

50


para uma carga total 1 MB, 5 MB, 10 MB, 15 MB e 20 MB.

Com relacao ao tempo de resposta de 10 clientes, observou-se que para 100

clientes o protocolo MQTT ainda responde muito bem, ocorrendo um pequeno au-

mento de tempo, que e relativamente consideravel para um numero de requisicoes

10 vezes maior. Ja com relacao a razao teorica entre as bandas, percebe-se uma

grande diferenca em comparacao com aos valores teoricos, sendo que em apenas

um caso, Banda Total de 10 MB/s, obteve-se o resultado esperado a partir de uma

carga total de 15 MB, conforme grafico da figura 32.

51


Outra diferenca percebida, e a velocidade do processo de requisicao, conforme

grafico da figura 33, onde a taxa nao alcanca a metade da banda total disponibi-

lizada no melhor caso, ou seja, Banda total real de 100 MB/s e carga de dados de

20 MB.

52



4.2.3 200 Clientes

Com a intencao de sobrecarregar mais ainda o servidor, o proximo teste utilizou

200 requisicoes simultaneas de publicadores e, ao mesmo tempo, 200 assinantes.

Para o experimento de tempo total de resposta, percebe-se um grande aumento

em relacao ao teste com 10 clientes. Lembrando que as velocidades das bandas

totais fornecidas no grafico sao velocidades virtuais, ou seja, para um teste onde

foi fornecida a banda de 1 MB/s para cada processo e com um total de 200 cli-

entes, obteve-se uma banda total virtual de 200 MB/s, porem, a banda fısica real

disponıvel foi de 100 MB/s. Nesse ponto, pode-se levar a pensar que existe uma

saturacao da rede, o que nao e verdade visto que:

• Para 100 clientes tanto a banda virtual quando a banda real maxima sao de

53

100 MB/s e a velocidade maxima de requisicao de servico foi de 35 MB/s,

mostrando claramente que os recursos disponıveis nao sao usados em totali-

dade.

• Para o teste com 200 clientes, a maior banda utilizada foi de aproximada-

mente 35 MB/s, o que novamente mostra que os recursos nao foram utilizados

em sua totalidade, sendo assim, nao ha saturacao da rede.


para uma carga total de 0.2 MB, 0.6 MB, 0.8 MB, 1 MB e 2 MB..

54


para uma carga total de 2 MB, 10 MB, 20 MB, 30 MB e 40 MB.

Mesmo que o numero de clientes tenha sido incrementado em 20 vezes, o tempo

de resposta para atender todas as requisicoes nao teve um aumento proporcional.

Com esse aumento, o protocolo MQTT ainda foi capaz de atender todas as requi-

sicoes sem nenhuma falha, sendo assim, entregando a todos os assinantes os dados

enviados pelos publicantes.

Em relacao a razao teorica, o grafico da figura 36 apresenta com mais detalhes

os valores obtidos em comparacao ao tempo de resposta da Banda de 50 KB/s,

sendo que em nenhum caso o protocolo conseguiu atingir a velocidade de requisicao

teorica para 200 clientes.

55


No grafico da figura 37, onde demonstra-se a velocidade do processo de re-

quisicao para 200 clientes, e alcancado um limite para essa velocidade que chega

em torno de 35 MB/s. Esse valor e obtido perante a comparacao com o grafico

33 onde sao executadas 100 requisicoes simultaneas, ou seja, tanto para a banda

de 100 MB/s para 100 clientes e para a banda de 200 MB/s para 200 clientes,

observou-se que a velocidade do processo de requisicao foi a mesma.

56



57

5 Conclusões e Trabalhos Futuro

5.1 Conclusões

Nesta monografia, foi realizado um estudo com objetivo de avaliar o compor-

tamento do protocolo MQTT em redes onde a banda e um fator limitante e ao

mesmo tempo observar o seu desempenho, usando conexoes unicas e simultaneas

com diferentes cargas. Alguns testes iniciais sem o uso de restricao de banda foram

feitos com o objetivo de comprovar alguns fatos estruturais descritos no Capıtulo

1, como o caso do QoS, onde a bibliografia afirma que quanto maior o nıvel, maior

e o tempo gasto para o fim do processo.

Com base nos cenarios descritos no Capıtulo 4, o estudo contemplou:

• Analise da influencia dos fatores QoS e Tamanho de Carga, no tempo de

resposta, sem limitacoes de banda.

• Analise da influencia dos fatores Largura de Banda e Tamanho de Carga, no

tempo de resposta.

• Analise da influencia da relacao da quantidade de usuarios se conectando ao

servidor ao mesmo tempo, em ambientes de banda limitada.

Todas as analises aqui apresentadas junto com os resultados obtidos nesse

trabalho, permitiu concluir que:

58

• Existe uma pequena diferenca entre o tempo de resposta para os tres nıveis

de QoS, comprovando o fato teorico.

• A diferenca do QoS 1 e QoS 2 com relacao ao QoS 0, varia de no maximo

9%, indicando-se o uso do nıvel QoS 2 para aplicacoes que envolvem garantia

na entrega de dados.

• Os nıveis QoS 1 e QoS 2 apresentam tempo de respostas parecidos, o que

incentiva o uso do QoS 2, devido a quantidade de recursos inclusos em relacao

ao QoS 1.

• O protocolo MQTT nao apresenta um bom comportamento quando a carga

chega na grandeza dos MegaBytes, isso se da pela divisao do arquivo em

varios pacotes feita pela pilha de protocolo TCP/IP.

• Do ponto de vista do cliente, a banda nao tem um impacto significativo para

transferencia de arquivos menores que 10 KB, isso acontece pois a menor

banda fornecida foi de 50 KB/s que e maior que os pacotes em questao.

• O limite de processamento e de 35 MB/s, no caso desse ambiente. Nos testes

de throughput com 100 e 200 clientes, quando o interesse e a velocidade

do processo de requisicao, o MQTT nao utiliza toda a banda fornecida. O

servidor atende os clientes na velocidade descrita acima, quando na verdade

a banda disponibilizada e a maxima, o mesmo ocorre com 200 clientes, ou

seja, atinge o lımite de 35 MB/s.

• A velocidade (35 MB/s) de processamento, descrita acima, nao e limitada

pelo numero de usuarios que fazem a requisicao do servico e sim pela carga

de dados a qual e necessaria que o servidor processe simultaneamente. Essa

conclusao parte da seguinte observacao: tanto para 100 ou 200 clientes o

Broker foi capaz de atender sem perdas todas as solicitacoes, porem, com

a mesma velocidade. Assim, chegou-se a uma carga limite a qual o MQTT

consegue processar e nao ha um limite de clientes que fazem a requisicao de

um servico ao mesmo tempo.

59

5.2 Trabalhos Futuros

A partir dos resultados e conclusoes obtidos nesse trabalho, e sugerido os se-

guintes trabalhos futuros com o protocolo MQTT, tais como:

• Analizar o comportamento do protocolo com 10 mil clientes conectados ao

servidor. Esse e o valor teorico de publicantes e assinantes os quais o servidor

hipoteticamente pode atender, e nao um numero de conexoes simultaneas.

• Verificar o tempo de resposta separadamente para cada cliente, quando ha

muitas requisicoes ao mesmo tempo.

60

Referências

CARO, N. D. et al. Comparison of two lightweight protocols for smartphone-basedsensing. 20th Symposium Communications and Vehicular Technology in theBenelux (SCVT), Brussels, Belgium, 2013.

COMPANY, P. S. Rabbitmq broker. www.rabbitmq.com, San Francisco, USA,2014.

EMBEDDED101. Develop m2m iot devices.http://www.embedded101.com/developm2miotdevicesebook.aspx, Califor-nia, 2013.

FOUNDATION, T. E. Paho clients. https://eclipse.org/paho/, Ontario,Canada,2014.

LAMPKIN, V. et al. Building Smarter Planet Solutions with MQTT and IBMWebSphere MQ Telemetry. IBM: http://www.redbooks.ibm.com/, 2012.

LEE, S. et al. Correlation analysis of mqtt loss and delay according to qoslevel. The International Conference on Information Networking (ICOIN), Daegu,Republic of Korea, 2013.

OASIS. Oasis message queuing telemetry transport (mqtt) technical committee.https://www.oasis-open.org/committees/mqtt/charter.php, Burlington, 2014.

PIPER, A. Choosing your messaging protocol: Amqp, mqtt, or stomp.http://blogs.vmware.com/vfabric/2013/02/choosing-your-messaging-protocol-amqp-mqtt-or-stomp.html, http://andypiper.co.uk/, 2013.

PIPER, A. Developing applications. http://mqtt.org/wiki/, http://mqtt.org/,2013.

THANGAVEL, D. et al. Performance evaluation of mqtt and coap via a commonmiddleware. Ninth International Conference on Intelligent Sensors, SensorNetworks and Information Processing (ISSNIP), National University of Singapore,Singapore, 2014.

61

VENKATARAM, P.; MANVI, S. S. Communication Protocol Engineering. NewDelhi: Prentice/HALL, 2004.

WIRESHARK. Wireshark. https://Wireshark.org, 2013.