estudo e analise comparativa de desempenho do protocolo mqtt em redes de banda limitada
TRANSCRIPT
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
27 Tempo de resposta quando 10 requisicoes sao feitas ao mesmo
tempo para uma carga total 0.1 MB, 0.5 MB, 1 MB e 2 MB. . . . p. 46
28 Percentagens maiores indicam o quanto o valor ficou abaixo do
teorico. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 47
29 Velocidade em que o dado foi transmitido de acordo com a carga
e a banda disponibilizada para 10 clientes. . . . . . . . . . . . . . p. 48
30 Tempo de resposta quando 100 requisicoes sao feitas ao mesmo
tempo para uma carga total de 0.1 MB, 0.3 MB, 0.4 MB, 0.5 MB
e 1 MB. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 49
31 Tempo de resposta quando 100 requisicoes sao feitas ao mesmo
tempo para uma carga total 1 MB, 5 MB, 10 MB, 15 MB e 20 MB. p. 50
32 Percentagens maiores indicam o quanto o valor ficou abaixo do
teorico. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 51
33 Velocidade em que o dado foi transmitido de acordo com a carga
e a banda disponibilizada para 100 clientes. . . . . . . . . . . . . p. 52
34 Tempo de resposta quando 200 requisicoes sao feitas ao mesmo
tempo para uma carga total de 0.2 MB, 0.6 MB, 0.8 MB, 1 MB
e 2 MB.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 53
35 Tempo de resposta quando 200 requisicoes sao feitas ao mesmo
tempo para uma carga total de 2 MB, 10 MB, 20 MB, 30 MB e
40 MB. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 54
36 Percentagens maiores indicam o quanto o valor ficou abaixo do
teorico. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 55
37 Velocidade em que o dado foi transmitido de acordo com a carga
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
• QoS 1: 14 segundos
• QoS 2: 22 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.
Figura 27: Tempo de resposta quando 10 requisicoes sao feitas ao mesmo tempo
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.
Figura 28: Percentagens maiores indicam o quanto o valor ficou abaixo do teorico.
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
Figura 29: Velocidade em que o dado foi transmitido de acordo com a carga e a
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
Figura 30: Tempo de resposta quando 100 requisicoes sao feitas ao mesmo tempo
para uma carga total de 0.1 MB, 0.3 MB, 0.4 MB, 0.5 MB e 1 MB.
50
Figura 31: Tempo de resposta quando 100 requisicoes sao feitas ao mesmo tempo
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
Figura 32: Percentagens maiores indicam o quanto o valor ficou abaixo do teorico.
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
Figura 33: Velocidade em que o dado foi transmitido de acordo com a carga e a
banda disponibilizada para 100 clientes.
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.
Figura 34: Tempo de resposta quando 200 requisicoes sao feitas ao mesmo tempo
para uma carga total de 0.2 MB, 0.6 MB, 0.8 MB, 1 MB e 2 MB..
54
Figura 35: Tempo de resposta quando 200 requisicoes sao feitas ao mesmo tempo
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
Figura 36: Percentagens maiores indicam o quanto o valor ficou abaixo do teorico.
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
Figura 37: Velocidade em que o dado foi transmitido de acordo com a carga e a
banda disponibilizada para 200 clientes.
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.