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

767 visualizações

Publicada em

Este é um estudo dirigido do protocolo Message Queuing Telemetry Transport (MQTT), onde é abordado seu funcionamento, vantagens e aplicações bem como alguns exemplos de uso na industria, no mundo acadêmico e mesmo para estudo. A título de conhecimento, também sera apresentado situações reais que no futuro podem vir a utilizar destes recursos oferecidos pelo protocolo, seja na área da engenharia, saúde, comércio dentre outras.

Publicada em: Tecnologia
0 comentários
5 gostaram
Estatísticas
Notas
  • Seja o primeiro a comentar

Sem downloads
Visualizações
Visualizações totais
767
No SlideShare
0
A partir de incorporações
0
Número de incorporações
18
Ações
Compartilhamentos
0
Downloads
45
Comentários
0
Gostaram
5
Incorporações 0
Nenhuma incorporação

Nenhuma nota no slide

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

  1. 1. Helton Franco de Sousa Gabriel Cirac Mendes Souza MQTT: Estudo e An´alise Comparativa de Desempenho do Protocolo MQTT em Redes de Banda Limitada Itajub´a - MG 28 de outubro de 2014
  2. 2. Helton Franco de Sousa Gabriel Cirac Mendes Souza MQTT: Estudo e An´alise Comparativa de Desempenho do Protocolo MQTT em Redes de Banda Limitada Este ´e um estudo dirigido do protocolo Message Queuing Telemetry Transport (MQTT), onde ´e abordado seu funcio- namento e analizado seu comportamento em diversos cen´arios com limita¸c˜ao de banda. O presente trabalho traz as me- didas de desempenho do protocolo com rela¸c˜ao ao tempo de resposta ao cliente, quando este faz uma requisi¸c˜ao de envio de um arquivo. Orientador: Prof. Msc. Bruno Tardiole Kuehne Universidade Federal de Itajub´a - UNIFEI Instituto de Engenharia de Sistemas e Tecnologias da Informa¸c˜ao Engenharia da Computa¸c˜ao Itajub´a - MG 28 de outubro de 2014
  3. 3. Sumário Lista de Figuras Resumo 1 Considerações iniciais p. 9 1.1 Introdu¸c˜ao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 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 Dur´aveis e n˜ao dur´aveis . . . . . . . . . . . . . p. 15 2.1.4 Keep Alive Time . . . . . . . . . . . . . . . . . . . . . . . p. 15 2.1.5 Mensagens Retidas . . . . . . . . . . . . . . . . . . . . . . p. 16 2.1.6 T´opicos . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 16 2.2 Broker . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 18 2.3 Autentica¸c˜ao e Seguran¸ca . . . . . . . . . . . . . . . . . . . . . . p. 18 2.4 Fluxo das mensagens . . . . . . . . . . . . . . . . . . . . . . . . . p. 19
  4. 4. 2.5 Assinatura do cliente . . . . . . . . . . . . . . . . . . . . . . . . . p. 19 2.6 Qualidade de Servi¸co (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 Considera¸c˜oes Finais . . . . . . . . . . . . . . . . . . . . . . . . . p. 27 3 Ambiente de Experimento p. 28 3.1 Considera¸c˜oes Iniciais . . . . . . . . . . . . . . . . . . . . . . . . . p. 28 3.2 Considera¸c˜oes sobre o Cen´ario de Experimento . . . . . . . . . . . p. 30 3.3 Fatores . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 30 3.4 Script para Gera¸c˜ao 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 Raz˜ao entre Banda e Tamanho de Arquivo . . . . . . . . . p. 39 4.1.4 Velocidade do Processamento de requisi¸c˜ao . . . . . . . . . p. 43 4.2 Tempo de resposta para conex˜oes simultˆaneas . . . . . . . . . . . p. 45 4.2.1 10 Clientes . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 45
  5. 5. 4.2.2 100 Clientes . . . . . . . . . . . . . . . . . . . . . . . . . . p. 48 4.2.3 200 Clientes . . . . . . . . . . . . . . . . . . . . . . . . . . p. 52 5 Conclusões e Trabalhos Futuro p. 57 5.1 Conclus˜oes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 57 5.2 Trabalhos Futuros . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 59 Referências p. 60
  6. 6. 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 Conex˜ao do cliente com o servidor com clean session = 1 . . . . . p. 20 6 Assinando e cancelando assinatura de um t´opico . . . . . . . . . . p. 21 7 A mensagem enviada pode ou n˜ao chegar ao destino. . . . . . . . p. 22 8 A mensagem enviada certamente chegar´a ao destinat´ario, por´em pode chegar duplicada. . . . . . . . . . . . . . . . . . . . . . . . . p. 22 9 A mensagem chega exatamente uma vez. . . . . . . . . . . . . . . p. 23 10 Rela¸c˜ao entre tamanho e perda de pacotes em conex˜ao a cabo. . . p. 25 11 Rela¸c˜ao entre tamanho e perda de pacotes em conex˜ao 3G. . . . . p. 25 12 Cabe¸calho da mensagem do MQTT . . . . . . . . . . . . . . . . . p. 26 13 Topologia utilizada. . . . . . . . . . . . . . . . . . . . . . . . . . . p. 30 14 Sobreposi¸c˜ao no tempo de envio e resposta quando h´a mais de um cliente se conectando simultˆaneamente. . . . . . . . . . . . . . p. 32 15 Iniciando o servidor. . . . . . . . . . . . . . . . . . . . . . . . . . p. 34 16 Assinante. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 34
  7. 7. 17 Publicando a mensagem. . . . . . . . . . . . . . . . . . . . . . . . p. 34 18 Recebendo a mensagem. . . . . . . . . . . . . . . . . . . . . . . . p. 34 19 Diferen¸ca de tempo entre os n´ıveis de Qos. . . . . . . . . . . . . . p. 37 20 Diferen¸ca em percentagem em rela¸c˜ao aos n´ıveis de servi¸co QoS. . p. 38 21 Compara¸c˜ao do tempo de resposta com rela¸c˜ao a carga enviada quando n˜ao ocorre limita¸c˜ao 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 te´orico. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 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 requisi¸c˜oes s˜ao 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 requisi¸c˜oes s˜ao 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 te´orico. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 47 29 Velocidade em que o dado foi transmitido de acordo com a carga e a banda disponibilizada para 10 clientes. . . . . . . . . . . . . . p. 48
  8. 8. 30 Tempo de resposta quando 100 requisi¸c˜oes s˜ao 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 requisi¸c˜oes s˜ao 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 te´orico. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 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 requisi¸c˜oes s˜ao 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 requisi¸c˜oes s˜ao 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 te´orico. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 55 37 Velocidade em que o dado foi transmitido de acordo com a carga e a banda disponibilizada para 200 clientes. . . . . . . . . . . . . p. 56
  9. 9. Resumo Essa monografia apresenta uma descri¸c˜ao do protocolo de comunica¸c˜ao Mes- sage Queuing Telemetry Transport (MQTT), que vem ganhando um espa¸co con- sider´avel no ambiente IoT(Internet of Things), onde o interesse ´e conectar dispo- sitivos e hardwares na internet. ´E abordado o seu funcionamento e analisado o comportamento do mesmo em situa¸c˜oes onde a banda ´e um fator limitante, tanto para conex˜oes ´unicas quanto para conex˜oes simultˆaneas, sendo assim, verificando se a finalidade ao qual ele foi criado, ´e atendida satisfatoriamente. O presente tra- balho tem por objetivo fazer uma avalia¸c˜ao de desempenho do protocolo, variando a carga a ser transmitida, o n´umero de clientes que fazem requisi¸c˜oes de um servi¸co e a banda disponibilizada.
  10. 10. 9 1 Considerações iniciais 1.1 Introdução Durante as ´ultimas d´ecadas, ´e poss´ıvel ver um enorme crescimento no uso e na complexidade na troca de informa¸c˜oes nos v´arios n´ıveis de arquitetura de comunica¸c˜ao. Segundo Venkataram e Manvi (2004), um protocolo de comunica¸c˜ao ´e a gram´atica 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 conte´udo de dados e o controle de informa¸c˜ao s˜ao montados na fonte e em seguida s˜ao transmitidos atrav´es de alguma rede e desmontados em seus destinos, fazendo as entidades usar o mesmo padr˜ao de comunica¸c˜ao. Os elementos chaves de um protocolo s˜ao, na maioria das vezes: • Sintaxe que inclui o formato de dados e o n´ıvel do sinal; semˆantica que controla a informa¸c˜ao e erros; • Timming que diz respeito ao tempo correspondente; • Sequˆencia de controle; Desde quando a pilha de protocolos TCP/IP foi definida, ela permite a conex˜ao de dispositivos a diversas redes e com isso uma enorme quantidade de protocolos foram criados na camada de aplica¸c˜ao para atender as necessidades de cada cliente, sendo um deles o MQTT. Basicamente, a maioria dos protocolos seguem a ideia de fragmentar a informa¸c˜ao em v´arios pacotes de tamanho relativamente menor, cada
  11. 11. 10 um deles, possuindo um cabe¸calho onde carregam informa¸c˜oes b´asicas para troca de dados. O tamanho desse cabe¸calho varia de protocolo para protocolo, um grande numero de bytes no cabe¸calho pode causar overhead na rede, necessitando assim, uma largura de banda maior para dar suporte ao devido protocolo. Em ambientes hostis com conex˜oes fr´ageis, a largura de banda costuma ser baixa, impossibilitando o uso geral de um ´unico protocolo para todos os tipos de comunica¸c˜oes. Nesses cen´arios, os dispositivos costumam sofrer frequentemente desconex˜oes tempor´arias, 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 publica¸c˜ao 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 n˜ao 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 mem´oria. A escolha de ser open-source, garante que adapta¸c˜oes possam ser feitas para projetos espec´ıficos. O MQTT foi desenvolvido para atuar sobre v´arios proto- colos de comunica¸c˜ao. O principal deles, como dito anteriormente, ´e a pilha de protocolos TCP/IP que provˆe a conex˜ao b´asica com a internet. Deriva¸c˜oes do MQTT foram criadas para trabalharem em outras pilhas de protocolo, como o MQTT-SN (Message Queuing Telemetry Transport for Sensor Networks) onde a comunica¸c˜ao ´e feita usando r´adio frequˆencia (Bluetooh, ZigBee, Xbee, RFID e outros). A padroniza¸c˜ao do MQTT ´e feita pela (OASIS, 2014), ´org˜ao respons´avel pelo desenvolvimento de especifica¸c˜oes para protocolos como SOA(Service-oriented
  12. 12. 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 m´aximo 10 mil dispositivos. Para aumen- tar essa quantidade de usu´arios, pode-se adicionar um servidor em modo bridge, garantindo assim uma boa escalabilidade. Cada cliente se conecta ao servidor, denominado Broker, onde o usu´ario tem um ID ´unico para conex˜ao. O Broker ´e respons´avel pela aplica¸c˜ao das regras, conex˜ao de novos clientes e a transferˆencia de mensagens entre eles. Com todos esses recursos o MQTT vem ganhando grandes propor¸c˜oes devido ao crescimento de dispositivos conectados `a internet (Internet of Things), onde o mercado a cada dia exige seguran¸ca e m´axima eficiˆencia, sem deixar de garantir a entrega da informa¸c˜ao. 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 aplica¸c˜ao. Um dos protocolos que vem ganhando espa¸co na ´area de IoT, ´e o COAP(Constrained Application Protocol), que diferente do MQTT, utiliza pacotes UDP para enviar e receber informa¸c˜oes. Apesar desse diferen¸ca, a finalidade dos dois protocolos ´e a mesma, assim, compara¸c˜oes s˜ao 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 aplica¸c˜oes 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 est˜ao limitados a uma pequena largura de banda e ao mesmo tempo, avaliar esse desempenho em conex˜oes simultˆaneas, o qual esse trabalho avalia.
  13. 13. 12 1.2 Objetivo O objetivo dessa monografia ´e fazer um estudo e uma an´alise de desempenho do protocolo MQTT. Pretende-se avaliar o comportamento do protocolo quando se varia o n´umero de clientes conectados, a carga transferida e qualidade do servi¸co na entrega das mensagens, podendo assim, verificar onde ao uso do protocolo ´e mais vi´avel ou n˜ao.
  14. 14. 13 2 Arquitetura do Protocolo MQTT Considerando a discuss˜ao 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 seguran¸ca e como ´e feita toda a comunica¸c˜ao entre clientes e servidor. 2.1 Funcionalidades do MQTT 2.1.1 Publish, Subscribe and Topic O protocolo MQTT ´e baseado no padr˜ao de publica¸c˜ao de mensagens e assi- natura de t´opicos, tipicamente denominado padr˜ao Publish/Subscribe. O provedor das informa¸c˜oes ´e denominado Publisher e o consumidor desses dados ´e chamado Subscriber. O Publisher simplesmente envia as mensagens para o servidor com um identificador denominado t´opico, conforme indicado na figura 1. O Broker fica respons´avel por redistribuir todas as mensagens para os clientes que escolheram ser assinantes daquele t´opico correspondente. Esse mecanismo de t´opico pelo qual os clientes fazem a troca de dados ´e tecni- camente uma fila de mensagens. Esse padr˜ao tamb´em ´e conhecido como Observer (Observador), pois o cliente fica na observa¸c˜ao do t´opico ao qual ele est´a inte- ressado em receber a mensagem. Para o cliente assinante, n˜ao interessa quem
  15. 15. 14 Figura 1: Publicar uma mensagem para todos os assinantes. est´a publicando, mas somente a informa¸c˜ao, dando um car´acter 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 n˜ao foi e nem ser´a usada por outros clientes. Ele restringe o ID com tamanho m´aximo de 23 caracteres, mas existem situa¸c˜oes em que o cliente pode encurtar o tamanho do seu identificador. Para garantir que o ID seja ´unico, aproveita-se o endere¸co MAC que ´e dife- rente para cada dispositivo de rede. Mesmo assim, erros podem ocorrer com uso de identificadores duplicados, logo, executa-se uma sequˆencia de a¸c˜oes 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 conex˜ao do novo cliente e a desconex˜ao do antigo ou o bloqueio do cliente novo e a permiss˜ao do cliente antigo.
  16. 16. 15 2.1.3 Assinantes Duráveis e não duráveis Assinantes dur´aveis s˜ao aqueles clientes que podem receber todas as mensagens publicadas, incluindo aquelas que foram publicadas quando ele estava desconectado do Broker. No caso n˜ao-dur´avel, o Broker n˜ao retransmite as mensagens perdidas durante o per´ıodo que o cliente assinante esteve desconectado. Essa fun¸c˜ao ´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 seguran¸ca QoS 1 e QoS 2. Apenas no n´ıvel QoS 0 que o Flag n˜ao ´e ativado, os detalhes sobre os n´ıveis de QoS ser˜ao apresentados na se¸c˜ao 2.8. 2.1.4 Keep Alive Time Pelo lado do servidor, existe a necessidade que ele saiba quando seus clientes est˜ao ativos ou n˜ao. Mandar requisi¸c˜oes para seus clientes perguntando se eles est˜ao conectados tem um enorme custo operacional quando se trata de milhares de clientes. Por essa quest˜ao, fica como responsabilidade do cliente enviar uma mensagem em um certo per´ıodo de tempo, denominado como constante Keep Alive, dizendo que ainda est´a conectado. Essa situa¸c˜ao ´e ´util no caso onde o cliente n˜ao 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 intera¸c˜ao do tempo de Keep Alive, e s˜ao 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 s˜ao curtas de tamanho m´aximo de 2-bytes e elas n˜ao est˜ao associadas a nenhum n´ıvel de seguran¸ca QoS. Portanto, existe um temporizador no cliente que envia a mensagem PINGREQ e s´o ir´a disparar outro ap´os receber o PINQRESP do servidor. Caso o Broker n˜ao receba o PINQREQ, o cliente ´e
  17. 17. 16 desconectado. O servidor oferece uma carˆencia para receber o ping que vem do cliente, adicionando mais 50 por cento de tempo em rela¸c˜ao 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 n˜ao, como mostrado na figura 2. Todo Publisher pode marcar a sua devida mensagem como retida para que os novos Subscribers possam recebˆe-la no momento de sua conex˜ao, n˜ao tendo necessidade do Subscribers esperar por uma nova mensagem. Figura 2: Mensagem retidas. 2.1.6 Tópicos A distribui¸c˜ao de mensagens por t´opicos ´e organizada como uma ´arvore onde cada n´ıvel ´e dividido pelo car´acter “/” para criar seus sub-n´ıveis. T´opicos podem conter outros caracteres que ajudam na integra¸c˜ao de um cen´ario onde um assi- nante quer obter informa¸c˜oes de v´arios t´opicos combinando alguns padr˜oes. Para esse tipo de necessidade, foi definido mais dois caracteres especiais no protocolo MQTT, conhecidos como wildcards que s˜ao utilizados para navegar entre os n´ıveis em que o cliente deseja assinar, s˜ao eles o Multilevel e Unilevel.
  18. 18. 17 Multilevel: ´E definido pelo car´acter curinga “#” onde ´e usado para navegar em todas as combina¸c˜oes poss´ıveis do t´opico pai. Por exemplo, se for assinado o t´opico “A/#” por um cliente, significa que esse assinante ir´a receber as mensagens de todas as combina¸c˜oes de t´opicos poss´ıveis partindo de A. S˜ao 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 car´acter curinga (+) onde ´e usado para assinar todas as combina¸c˜oes poss´ıveis de t´opicos dentro de um ´unico n´ıvel. Por exemplo, se for assinado o t´opico “A/+/D” por um cliente, significa que esse assinante ir´a receber as mensagens de todas as combina¸c˜oes de t´opicos poss´ıveis partindo de A e terminando em D. S˜ao eles “A/B/D” e “A/C/D” conforme figura 4. Figura 4: Exemplo de assinatura Unilevel.
  19. 19. 18 2.2 Broker O Broker ´e o servidor do MQTT, ele ´e respons´avel por gerenciar os publican- tes e assinantes, ou seja, ele disponibiliza todos os recursos e servi¸cos para que as mensagens sejam entregues. Quando um cliente quer enviar uma mensagem para um t´opico qualquer, o servidor retransmite a devida mensagens para os seus respectivos assinantes. O MQTT disponibiliza uma hierarquia de t´opicos atrav´es da palavra $SYS para os clientes acompanharem o status atual do servidor. Esses t´opicos s˜ao atualizados de acordo com a constante everysys-interval em segun- dos, contida no arquivo “mosquitto.conf”. Caso ela seja setada como 0, nenhuma atualiza¸c˜ao ´e enviada para os clientes. A seguir tem-se alguns t´opicos de exemplos: • $SYS/broker/bytes/received - Retorna o n´umero de bytes recebidos desde quando o Broker foi iniciado. • $SYS/broker/bytes/sent - Retorna o n´umero de bytes enviados desde quando o Broker foi iniciado. 2.3 Autenticação e Segurança O protocolo MQTT tem dois mecanismos de seguran¸ca para autentica¸c˜ao do cliente: client ID e user. Quando o cliente se conecta ao servidor, ele possui uma identifica¸c˜ao ´unica dentre todos os clientes, como sitado no item 2.4.2. Al´em do mais, a mensagem de autentica¸c˜ao pode conter um username e um password para identifica¸c˜ao do cliente. Lembrando que o MQTT n˜ao possui uma camada de seguran¸ca pr´opria, ou seja, ele utiliza a camada do TCP/IP, assim, pode-se usar a criptografia de dados atrav´es da rede, por exemplo, usando SSL/TLS onde utiliza-se certificados para autentica¸c˜ao, o que ´e mais seguro e melhor do que um simples username/password. Tamb´em pode-se usar uma camada de aplica¸c˜ao do pr´oprio MQTT para fazer a criptografia das mensagens lan¸cando m˜ao dos recursos SSL/TLS.
  20. 20. 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 situa¸c˜oes que podem ocorrer, o cliente pode: • Assinar um t´opico e receber mensagens dessa assinatura. • Publicar uma mensagem em um t´opico. • Manter a conex˜ao viva entre o cliente e o servidor. • Fechar a conex˜ao. Quando o cliente se conecta com o servidor, ele envia a mensagem CONNECT e o servidor responde com a mensagem CONNACK. Ap´os a conex˜ao, inicia-se uma nova sess˜ao e o cliente pode assinar um ou mais t´opicos dentro dessa sess˜ao. A mensagem CONNECT possui o Flag Clean Session citado no item 2.4.3, o que garante que o cliente n˜ao perca todas as assinaturas quando se desconectar do servidor. Caso o Flag Clean Session seja marcado como verdadeiro, as assinaturas s˜ao v´alidas somente dentro daquela sess˜ao, ou seja, caso o cliente se desconecte sem se desfazer de todos os t´opicos, o servidor ir´a cancelar a assinatura dos t´opicos na pr´oxima conex˜ao 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 t´opico que ele deseja assinar e caso ele obtenha sucesso, o cliente recebe uma mensagem SUBACK do servidor, a partir desse momento, o cliente receber´a todas as mensagens relativas ao t´opico que ele assinou at´e o momento em que ele cancele a assinatura com a mensagem UNSUBSCRIBE e receba a confirma¸c˜ao
  21. 21. 20 Figura 5: Conex˜ao do cliente com o servidor com clean session = 1 com a mensagem UNSUBACK do servidor. Quando o cliente n˜ao envia nenhuma mensagem na rede, ´e necess´ario manter a conex˜ao ativa usando mensagens de ping para evitar que o servidor feche as conex˜oes, 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 requisi¸c˜ao para que o servidor desligue o cliente de sua assinatura, conforme a figura 6. Se ele n˜ao receber uma resposta, ele se desconecta em um tempo limite. Um recurso interessante do MQTT s˜ao as mensagens denominadas will. Quando o cliente se conecta usando essa op¸c˜ao, o servidor guarda essa informa¸c˜ao e no caso em que o cliente seja desconectado sem mandar a mensagem DISCONNECT, o servidor automaticamente avisa os outros assinantes que houve uma desconex˜ao inesperada por parte do primeiro assinante.
  22. 22. 21 Figura 6: Assinando e cancelando assinatura de um t´opico 2.6 Qualidade de Serviço (QoS) Segundo o site Embedded101 (2013), o MQTT define trˆes n´ıveis de qualidade na entrega de mensagens, onde cada n´ıvel possui os seus respectivos m´etodos para garantir que a qualidade do servi¸co de entrega seja atendida. Lembrando que o protocolo ´e baseado na pilha TCP/IP, o que garante a entrega da mensagem mas n˜ao garante perdas caso a conex˜ao com a rede venha a falhar. Quanto mais alto o n´ıvel, mais recursos s˜ao necess´arios. 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 n˜ao ao seu destino conforme figura 7.
  23. 23. 22 Figura 7: A mensagem enviada pode ou n˜ao chegar ao destino. QoS Level 1 (At lest once ): Neste n´ıvel, o MQTT garante que a mensagem chegue aos assinantes, por´em, ela pode ser enviada mais de uma vez conforme figura 8. Figura 8: A mensagem enviada certamente chegar´a ao destinat´ario, por´em pode chegar duplicada.
  24. 24. 23 QoS Level 2 (Exactly once): Neste caso, a mensagem chega para os assinantes apenas uma vez. Assim, o gasto com recursos ´e m´aximo 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 ser´a 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 ser´a Npt. Agora, no caso do QoS 1, tem-se uma
  25. 25. 24 mensagem a mais, que ´e a resposta do servidor para o cliente e cont´em apenas 2 bytes. Denomina-se o tempo de resposta dessa mensagem por mt. Assim sendo, o tempo necess´ario levado para N mensagens ser´a N(pt + mt). Analisa-se agora o QoS 2, que utiliza outras trˆes 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. Ent˜ao, se 10 mensagens s˜ao enviadas e tem-se um caso onde pt ´e 1.0 segundo e mt equivale a 0.4 segundos, assim, substituindo na f´ormula para cada caso, obt´em-se os seguintes tempos hipot´eticos: • QoS 0: 10 segundos • QoS 1: 14 segundos • QoS 2: 22 segundos Comparando a perda de pacotes em rela¸c˜ao ao n´ıvel QoS, segundo Lee et al. (2013), para pacotes de at´e 4,000 bytes a perda utilizando uma conex˜ao a cabo ´e praticamente zero, como mostrado na figura 10 (LEE et al., 2013), por´em, h´a um acr´escimo significativo na perda para pacotes acima do tamanho citado. Em um cen´ario onde a conex˜ao ´e atrav´es de telefonia m´ovel, existe uma breve perda de pacotes, mas o tamanho do pacote n˜ao influˆencia significativamente na perda, conforme figura 11 (LEE et al., 2013). 2.8 Formato da Mensagem O cabe¸calho da mensagem do protocolo MQTT carrega uma quantidade de informa¸c˜oes necess´arias, para o controle do pr´oprio. O protocolo pode adotar cabe¸calhos de tamanho variavel, dependendo da aplica¸c˜ao. No caso do MQTT, o cabe¸calho tem um tamanho fixo, de acordo com a ilustra¸c˜ao da figura 12.
  26. 26. 25 Figura 10: Rela¸c˜ao entre tamanho e perda de pacotes em conex˜ao a cabo. Figura 11: Rela¸c˜ao entre tamanho e perda de pacotes em conex˜ao 3G.
  27. 27. 26 7 6 5 4 3 2 1 0 Byte 1 Byte 2 QoS Level RETAIN Remaining Length Figura 12: Cabe¸calho 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 cabe¸calho para conter o tipo de mensagem que o protocolo est´a enviando no momento. Os tipos poss´ıveis s˜ao: CONNECT: A carga de informa¸c˜ao contida nessa mensagem pode ser uma ou trˆes strings com codifica¸c˜ao UTF-8. A primeira string apenas identifica o cliente para o servidor o qual ele est´a se conectando. A segunda string ´e o t´opico Will e a terceira strings ´e a mensagem Will. A terceira e a segunda string s´o vai estar presente se o flag will for marcada como TRUE na mensagem CONNECT. CONNACK: Reconhece um pedido de conex˜ao. ´E uma mensagem enviada do servidor ao cliente em resposta a um pedido CONNECT. SUBSCRIBE: A carga dessa mensagem cont´em a lista de t´opicos que o cliente pode assinar e o n´ıvel QoS utilizado nesta assinatura. Utiliza codifica¸c˜ao UTF. SUBACK: Est´a mensagem cont´em 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 est´a ativo. PUBLISH: ´E a mensagem que faz o pedido de publica¸c˜ao. ´E enviada do cliente para o servidor e cada mensagem desse tipo est´a associada a um t´opico para poder diferenciar o destino e os interessados em recebˆe-la.
  28. 28. 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 publica¸c˜ao 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 publica¸c˜ao 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 t´opico. 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: Est´a ´e a mensagem de notifica¸c˜ao de desconex˜ao. Ela ´e envi- ada do cliente para o servidor para notificar que est´a prestes a encerrar a conex˜ao. Isso permite que a desconex˜ao seja limpa, ou seja, n˜ao seja uma queda de conex˜ao 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 test´a-lo e extrair informa¸c˜oes a respeito do seu desempenho, que ´e o assunto do cap´ıtulo seguinte.
  29. 29. 28 3 Ambiente de Experimento 3.1 Considerações Iniciais Conforme mencionado no Cap´ıtulo 1, o objetivo da presente disserta¸c˜ao ´e avaliar o desempenho do protocolo MQTT em ambientes diversos onde a banda pode ser um fator limitante, variando tamb´em o QoS (Quality of Service), n´umero de usu´arios 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 considera¸c˜ao para obten¸c˜ao dos resultados e o ambiente onde esses teste foram realizados. Na defini¸c˜ao dos testes, relevou-se a importˆancia de verificar o impacto quando n˜ao h´a limita¸c˜ao de banda, variando somente o QoS e o tamanho do arquivo. Foram criados ent˜ao, diversos cen´arios, assim, com os dados obtidos, pode-se fazer uma avalia¸c˜ao do protocolo e extrair diversas informa¸c˜oes, com as quais, ´e poss´ıvel dizer onde o uso do MQTT ´e mais vi´avel. Os testes s˜ao 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 pr´oprio recebe uma confirma¸c˜ao do servidor. • Tempo de resposta total - Avaliar o comportamento quando v´arios clien- tes se conectam a um ´unico broker, enviando dados e analisar o throughput
  30. 30. 29 (quantidade de requisi¸c˜oes atendidas em determinado intervalo de tempo) atrav´es de conex˜oes simultˆaneas. O tempo coletado se inicia quando o pri- meiro cliente se conecta ao servidor e termina quando o ´ultimo cliente recebe a resposta de confirma¸c˜ao vinda do servidor. Para o ambiente de teste, utilizou-se o laborat´orio Cluster da UNIFEI, con- tendo as seguintes configura¸c˜oes: • M´aquinas 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 transmiss˜ao de dados. • Utilizou-se trˆes 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 publica¸c˜oes simultˆaneas aumentando o n´umero de threads e finalmente a ´ultima m´aquina como assinante, onde era poss´ıvel criar v´arios assinantes simultˆaneos. • 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 atrav´es do gerenciamento da quantidade de dados que ´e lido e escrito no socket, usando uma vers˜ao alternativa da API do BSD Socket. • Mosquitto 3.1.1- Vers˜ao do MQTT usado tanto como cliente e servidor. A escolha do Mosquitto se deu pela finalidade e facilidade do uso. Outros servidores open-source s˜ao dispon´ıveis, como RabbitMQ (COMPANY, 2014) e Paho (FOUNDATION, 2014). A figura 13 mostra a topologia implementada para avaliar o desempenho do protocolo em fun¸c˜ao dos v´arios fatores a serem alterados.
  31. 31. 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 m´aximo 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 v´arios clientes, ent˜ao usou-se uma m´aquina Quad-Core para simular as conex˜ao simultˆaneas. 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 pr´oprio 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 necess´ario 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 tendˆencia de minimizar os custos computacionais dos clientes e ao mesmo tempo garantir uma confiabilidade alta do sistema na
  32. 32. 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, h´a trˆes n´ıveis que definem a qualidade da entrega das mensagens. Como cada um possui em sua arquitetura um conjunto de mensagens necess´arias para opera¸c˜ao de envio, decidiu-se medir o quanto cada n´ıvel impacta no tempo de resposta ao cliente. Bandwidth: Como um dos principais fatores da cria¸c˜ao do protocolo MQTT foi aumentar o desempenho em redes hostis e limitadas, escolheu-se variar a lar- gura de banda para aproximar-se ao m´aximo de uma situa¸c˜ao 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 aplica¸c˜oes reais, o tamanho de um arquivo em uma mensagem ´e vari´avel, 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. N´umero de Clientes Assinantes e Publicadores: O n´umero de clientes foi um fator determinante para a divis˜ao das duas linhas frontais de testes, onde, na primeira utiliza-se conex˜ao individual que possibilita avaliar o tempo de resposta. J´a na segunda linha de testes, utiliza-se conex˜oes simultˆaneas com 10, 100 e 200 clientes e podendo assim avaliar o desempenho e a capacidade do servidor de atender todas as requisi¸c˜oes simultˆaneamente, assim como uma aplica¸c˜ao real. Pode-se observar que nessa segunda linha de testes, onde ´e feita a simula¸c˜ao de v´arios clientes, n˜ao ´e poss´ıvel analisar o tempo de resposta de cada processo individualmente utilizando o modelo de testes proposto, pois h´a uma concorrˆencia entre os processos, como ilustrado na figura 14, impossibilitando a escrita no ar- quivo de sa´ıda. Para trabalhos futuros, pretende-se utilizar um servi¸co de banco
  33. 33. 32 de dados, que gerencie essa concorrˆencia e, dessa maneira, seja poss´ıvel obter mais um dado para a pesquisa. Figura 14: Sobreposi¸c˜ao no tempo de envio e resposta quando h´a mais de um cliente se conectando simultˆaneamente. 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 combina¸c˜ao gera um total de 504 testes. Para se alcan¸car um ´otimo resultado, foi executado pelo menos 10 vezes cada teste, com isso chegou-se a um total de 5040 execu¸c˜oes. Para facilitar, criou-se ent˜ao um prot´otipo gen´erico de um script, onde era poss´ıvel fazer os diversos testes em sequˆencia, 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 $!
  34. 34. 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 vari´avel inicio. • Linha 4: Loop usado para determinar o n´umero clientes que se conectam simultˆaneamento 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 respons´avel por publicar a mensagem onde Q corresponde a qualidade de servi¸co (QoS) e A o arquivo a ser enviado. O trecho sensor/temp corresponde ao t´opico hipot´etico ao qual queremos publicar. • Linha 9: O c´odigo wait $! faz com que o c´odigo s´o prossiga ap´os o termino de todos os processos descritos pelo caracter &, descrito no final da linha 6. • Linha 10: Guarda o tempo final do teste na vari´avel fim. • Linha 11: A diferen¸ca ´e calculada e armazenada na vari´avel 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 ser´a deixado um exemplo. No caso, um publicante envia uma mensagem para o t´opico hipot´etico
  35. 35. 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 t´opico sensor/temp na m´aquina local com o comando da figura 16. Figura 16: Assinante. Agora um publicante deve enviar uma mensagem para o respectivo t´opico na m´aquina 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.
  36. 36. 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 significˆancia de 0,05 para calcular o intervalo de confian¸ca, ou seja, 95% de confian¸ca. Com a metodologia descrita acima, iniciou- se os testes, no laborat´orio Cluster. Os resultados obtidos foram analisados e ser˜ao apresentados no cap´ıtulo seguinte.
  37. 37. 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 trˆes 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 instru¸c˜oes, com a justificativa de oferecer diferentes tipos de qualidade na entrega de men- sagens. Al´em das instru¸c˜oes, o cabe¸calho da mensagem varia para cada n´ıvel, alterando tamb´em 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 m´aximo de 1 GigaByte. Conforme o gr´afico da figura 19 percebe-se que o MQTT praticamente atende os requisitos te´oricos mencionados no primeiro cap´ıtulo, ou seja, quanto maior o QoS utilizado mais recursos s˜ao necess´arios e consequentemente mais tempo ´e gasto para transmiss˜ao de um arquivo. Apesar do QoS2 consumir mais recursos do que o QoS1 eles est˜ao estatisticamente empatados.
  38. 38. 37 Figura 19: Diferen¸ca de tempo entre os n´ıveis de Qos. A diferen¸ca de tempo ´e mais vis´ıvel quanto maior a carga do arquivo anexo a mensagem. Analisando o gr´afico da figura 20, que utiliza o QoS0 como base de compara¸c˜ao, percebe-se uma diferen¸ca de 2% at´e 7% quando comparado com o QoS1 e de 3% at´e 9%, quando a compara¸c˜ao ´e feita com o QoS2.
  39. 39. 38 Figura 20: Diferen¸ca em percentagem em rela¸c˜ao aos n´ıveis de servi¸co QoS. 4.1.2 Arquivo Como a diferen¸ca observada entre os QoS foi de no m´aximo 9%, adotou-se o QoS2 como padr˜ao para analizar o impacto do tamanho do arquivo no tempo de resposta quando n˜ao h´a restri¸c˜oes de banda. Com isso, obteve-se o gr´afico da figura 21.
  40. 40. 39 Figura 21: Compara¸c˜ao do tempo de resposta com rela¸c˜ao a carga enviada quando n˜ao ocorre limita¸c˜ao de banda. Pode-se perceber que quando a banda n˜ao ´e um fator limitante e o interesse est´a apenas no tamanho do arquivo, n˜ao h´a 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 influˆencia em rela¸c˜ao ao tamanho do arquivo enviado. Ap´os os dados serem coletados, foi poss´ıvel verificar: • O tempo de resposta; • A taxa de transferˆencia real, verificando se a devida banda foi totalmente
  41. 41. 40 utilizada pelo processo; • Percentagem da velocidade utilizada em rela¸c˜ao ao te´orico, verificando se o incremento de banda corresponde ao incremento real na transferˆencia do arquivo. Para todos os itens citados anteriormente, usou-se o QoS2, pois a diferen¸ca de resultados entre os demais n´ıveis eram m´ınimos e a maioria das aplica¸c˜oes que utilizam o MQTT usam esse n´ıvel de servi¸co. Apenas um cliente foi usado para esse teste, assim, futuramente pode-se avaliar e comparar o desempenho do servidor com conex˜oes simultˆaneas analisando o tempo de resposta separadamente. Para o seguinte teste, dividiu-se o gr´afico em dois para facilitar a leitura. Nos gr´aficos 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.
  42. 42. 41 Apesar das bandas com valores mais altos terem um tempo de resposta me- lhor, para arquivos com carga at´e 10 KB percebe-se que o tempo de resposta em segundos n˜ao ´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 at´e 200 KB, percebe-se que o incre- mento na banda influˆencia relativamente no tempo de resposta. Considerando os dados obtidos, analisou-se a afirma¸c˜ao da seguinte hip´otese: • Dobrar a banda implica em obter um tempo de resposta pela metade Para an´alise da afirma¸c˜ao acima, utilizou-se a banda de 50 KB/s como referˆen- 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 lentid˜ao em percentagem em rela¸c˜ao ao te´orico. Para melhorar o entendimento do gr´afico, o
  43. 43. 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 te´orico. Quando ´e disponibilizado para um servi¸co uma dada banda, espera-se que todo esse recurso disponibilizado seja utilizado quando requisitado, ou seja, se h´a uma banda de 1 MB/s est´a dispon´ıvel para um recurso e este necessite utiliz´a-la para a transferˆencia de um arquivo, espera-se que essa transmiss˜ao seja realizada na velocidade citada acima, ou seja, a velocidade te´orica ´e a velocidade total disponi- bilizada para o servi¸co. O gr´afico da figura 24 mostra o quanto uma transferˆencia ´e mais lenta do que a te´orica, assim, um ponto com 500% significa que o dado foi transferido 5 vezes mais lento do que o esperado. Analisando os resultados,
  44. 44. 43 percebe-se que, quando ocorre um aumento na banda, melhora-se o tempo de res- posta, por´em, essa melhora s´o satisfaz parcialmente a hip´otese citada, quando o tamanho do arquivo ´e maior ou igual a 50 KB, pois nesse ponto o arquivo come¸ca a ser igual ou maior que as bandas disponibilizadas. 4.1.4 Velocidade do Processamento de requisição Aplica¸c˜oes que utilizam requisi¸c˜ao por uso de servidores dependem muitas vezes da qualidade do servi¸co prestado. O hardware utilizado nessas m´aquinas costuma ser robusto para que a velocidade de processamento seja maior ou igual a velocidade de transmiss˜ao da rede, fazendo com que n˜ao ocorra atrasos no tempo de resposta ao cliente. Nesse atual experimento, o interesse ´e verificar a capacidade do protocolo MQTT de gerenciar essas requisi¸c˜oes. Inicialmente o teste se d´a pelo uso de apenas um usu´ario publicante e um assinante, o gr´afico da figura 25 mostra os detalhes desse resultado.
  45. 45. 44 Figura 25: Velocidade em que o dado foi transmitido de acordo com a carga e a banda disponibilizada. Percebe-se, pelo gr´afico, que o protocolo MQTT responde satisfatoriamente ao processo de requisi¸c˜ao 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 transmiss˜ao. ´E intuitivo inferir que arquivos com cargas menores sejam transferidos a uma taxa de transferˆencia maior, por´em percebe-se que quanto maior o arquivo, maior ´e a taxa de transferˆencia disponibilizada para o processo. Isso se d´a pela quebra de pacotes do protocolo TCP, onde s˜ao divididos em quantidade maiores e podem ser simultaneamente enviados atrav´es da rede.
  46. 46. 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 conex˜oes ao mesmo tempo. Para esses testes, foram criados trˆes cen´arios onde variou-se o n´umero de clientes. Para cada quantidade N de publicadores, utilizou-se a mesma quantidade de assinantes, onde N ´e igual a 10, 100 e 200 usu´arios. Separou-se os testes em trˆes etapas. Novamente, adotou-se para os pr´oximos testes, o n´ıvel QoS2 pois a diferen¸ca notada entre os demais n´ıveis n˜ao foi t˜ao significativa. 4.2.1 10 Clientes Para esse teste, o servidor teve que atender 10 requisi¸c˜oes simultˆaneas dos publicadores e fornecer a resposta para 10 assinantes. No ambiente atual, variou-se apenas a banda dos usu´arios publicadores, mantendo os assinantes sem restri¸c˜oes. Com o intuito de obter mais resultados, o tamanho do arquivo foi alterado para cada teste. Os gr´aficos da figura 26 e figura 27 tratam-se do tempo resposta para 10 usu´arios 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 n´umero de 10 usu´arios 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.
  47. 47. 46 Figura 26: Tempo de resposta quando 10 requisi¸c˜oes s˜ao 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 requisi¸c˜oes s˜ao feitas ao mesmo tempo para uma carga total 0.1 MB, 0.5 MB, 1 MB e 2 MB.
  48. 48. 47 Comparando os resultados atuais com os obtidos no item 4.1.3, onde se faz o uso de apenas um usu´ario, percebe-se que o protocolo responde de forma similar, mostrando um ´otima desempenho no caso de 10 conex˜oes simultˆaneas. Conse- quentemente, o gr´afico da figura 28, que mostra a raz˜ao entre o tempo de resposta das bandas usando 50 KB/s como referˆencia, demonstrou-se com valores similares ao caso de um cliente. Figura 28: Percentagens maiores indicam o quanto o valor ficou abaixo do te´orico. No gr´afico 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, por´em, percebe-se que o protocolo MQTT responde satisfatoriamente ao processo de requisi¸c˜ao 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 gr´afico se encontram em MegaBytes.
  49. 49. 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 pr´oximo experimento, o objetivo ´e sobrecarregar ainda mais o servidor com um total de 100 usu´arios publicantes. ´E importante relembrar que antes do in´ıcio do teste, foram acionados 100 assinantes que ficararam respons´aveis de receber os dados publicados. Para o teste do tempo de resposta, obteve-se os seguintes gr´aficos da figura 34 e figura 35. As bandas totais mencionadas no gr´afico s˜ao bandas virtuais, onde foi disponibilizado no m´aximo 1 MB/s para cada processo, totalizando 100 MB/s para o caso mais robusto.
  50. 50. 49 Figura 30: Tempo de resposta quando 100 requisi¸c˜oes s˜ao feitas ao mesmo tempo para uma carga total de 0.1 MB, 0.3 MB, 0.4 MB, 0.5 MB e 1 MB.
  51. 51. 50 Figura 31: Tempo de resposta quando 100 requisi¸c˜oes s˜ao feitas ao mesmo tempo para uma carga total 1 MB, 5 MB, 10 MB, 15 MB e 20 MB. Com rela¸c˜ao 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 consider´avel para um n´umero de requisi¸c˜oes 10 vezes maior. J´a com rela¸c˜ao a raz˜ao te´orica entre as bandas, percebe-se uma grande diferen¸ca em compara¸c˜ao com aos valores te´oricos, 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 gr´afico da figura 32.
  52. 52. 51 Figura 32: Percentagens maiores indicam o quanto o valor ficou abaixo do te´orico. Outra diferen¸ca percebida, ´e a velocidade do processo de requisi¸c˜ao, conforme gr´afico da figura 33, onde a taxa n˜ao alcan¸ca 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.
  53. 53. 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 inten¸c˜ao de sobrecarregar mais ainda o servidor, o pr´oximo teste utilizou 200 requisi¸c˜oes simultˆaneas de publicadores e, ao mesmo tempo, 200 assinantes. Para o experimento de tempo total de resposta, percebe-se um grande aumento em rela¸c˜ao ao teste com 10 clientes. Lembrando que as velocidades das bandas totais fornecidas no gr´afico s˜ao 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, por´em, a banda f´ısica real dispon´ıvel foi de 100 MB/s. Nesse ponto, pode-se levar a pensar que existe uma satura¸c˜ao da rede, o que n˜ao ´e verdade visto que: • Para 100 clientes tanto a banda virtual quando a banda real m´axima s˜ao de
  54. 54. 53 100 MB/s e a velocidade m´axima de requisi¸c˜ao de servi¸co foi de 35 MB/s, mostrando claramente que os recursos dispon´ıveis n˜ao s˜ao 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 n˜ao foram utilizados em sua totalidade, sendo assim, n˜ao h´a satura¸c˜ao da rede. Figura 34: Tempo de resposta quando 200 requisi¸c˜oes s˜ao feitas ao mesmo tempo para uma carga total de 0.2 MB, 0.6 MB, 0.8 MB, 1 MB e 2 MB..
  55. 55. 54 Figura 35: Tempo de resposta quando 200 requisi¸c˜oes s˜ao feitas ao mesmo tempo para uma carga total de 2 MB, 10 MB, 20 MB, 30 MB e 40 MB. Mesmo que o n´umero de clientes tenha sido incrementado em 20 vezes, o tempo de resposta para atender todas as requisi¸c˜oes n˜ao teve um aumento proporcional. Com esse aumento, o protocolo MQTT ainda foi capaz de atender todas as requi- si¸c˜oes sem nenhuma falha, sendo assim, entregando a todos os assinantes os dados enviados pelos publicantes. Em rela¸c˜ao a raz˜ao te´orica, o gr´afico da figura 36 apresenta com mais detalhes os valores obtidos em compara¸c˜ao ao tempo de resposta da Banda de 50 KB/s, sendo que em nenhum caso o protocolo conseguiu atingir a velocidade de requisi¸c˜ao te´orica para 200 clientes.
  56. 56. 55 Figura 36: Percentagens maiores indicam o quanto o valor ficou abaixo do te´orico. No gr´afico da figura 37, onde demonstra-se a velocidade do processo de re- quisi¸c˜ao para 200 clientes, ´e alcan¸cado um limite para essa velocidade que chega em torno de 35 MB/s. Esse valor ´e obtido perante a compara¸c˜ao com o gr´afico 33 onde s˜ao executadas 100 requisi¸c˜oes simultˆaneas, 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 requisi¸c˜ao foi a mesma.
  57. 57. 56 Figura 37: Velocidade em que o dado foi transmitido de acordo com a carga e a banda disponibilizada para 200 clientes.
  58. 58. 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 conex˜oes ´unicas e simultˆaneas com diferentes cargas. Alguns testes iniciais sem o uso de restri¸c˜ao 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 cen´arios descritos no Cap´ıtulo 4, o estudo contemplou: • An´alise da influˆencia dos fatores QoS e Tamanho de Carga, no tempo de resposta, sem limita¸c˜oes de banda. • An´alise da influˆencia dos fatores Largura de Banda e Tamanho de Carga, no tempo de resposta. • An´alise da influˆencia da rela¸c˜ao da quantidade de usu´arios se conectando ao servidor ao mesmo tempo, em ambientes de banda limitada. Todas as an´alises aqui apresentadas junto com os resultados obtidos nesse trabalho, permitiu concluir que:
  59. 59. 58 • Existe uma pequena diferen¸ca entre o tempo de resposta para os trˆes n´ıveis de QoS, comprovando o fato te´orico. • A diferen¸ca do QoS 1 e QoS 2 com rela¸c˜ao ao QoS 0, varia de no m´aximo 9%, indicando-se o uso do n´ıvel QoS 2 para aplica¸c˜oes 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 rela¸c˜ao ao QoS 1. • O protocolo MQTT n˜ao apresenta um bom comportamento quando a carga chega na grandeza dos MegaBytes, isso se d´a pela divis˜ao do arquivo em v´arios pacotes feita pela pilha de protocolo TCP/IP. • Do ponto de vista do cliente, a banda n˜ao tem um impacto significativo para transferˆencia 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 quest˜ao. • 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 requisi¸c˜ao, o MQTT n˜ao utiliza toda a banda fornecida. O servidor atende os clientes na velocidade descrita acima, quando na verdade a banda disponibilizada ´e a m´axima, 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, n˜ao ´e limitada pelo n´umero de usu´arios que fazem a requisi¸c˜ao do servi¸co e sim pela carga de dados a qual ´e necess´aria que o servidor processe simultˆaneamente. Essa conclus˜ao parte da seguinte observa¸c˜ao: tanto para 100 ou 200 clientes o Broker foi capaz de atender sem perdas todas as solicita¸c˜oes, por´em, com a mesma velocidade. Assim, chegou-se a uma carga limite a qual o MQTT consegue processar e n˜ao h´a um limite de clientes que fazem a requisi¸c˜ao de um servi¸co ao mesmo tempo.
  60. 60. 59 5.2 Trabalhos Futuros A partir dos resultados e conclus˜oes 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 te´orico de publicantes e assinantes os quais o servidor hipoteticamente pode atender, e n˜ao um n´umero de conex˜oes simultˆaneas. • Verificar o tempo de resposta separadamente para cada cliente, quando h´a muitas requisi¸c˜oes ao mesmo tempo.
  61. 61. 60 Referências CARO, N. D. et al. Comparison of two lightweight protocols for smartphone-based sensing. 20th Symposium Communications and Vehicular Technology in the Benelux (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 IBM WebSphere MQ Telemetry. IBM: http://www.redbooks.ibm.com/, 2012. LEE, S. et al. Correlation analysis of mqtt loss and delay according to qos level. 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 common middleware. Ninth International Conference on Intelligent Sensors, Sensor Networks and Information Processing (ISSNIP), National University of Singapore, Singapore, 2014.
  62. 62. 61 VENKATARAM, P.; MANVI, S. S. Communication Protocol Engineering. New Delhi: Prentice/HALL, 2004. WIRESHARK. Wireshark. https://Wireshark.org, 2013.

×