SEAN CARLISTO DE ALVARENGA TECNOLOGIAS PUSH E UMA ARQUITETURA DE NOTIFICAÇÃO PARA CIDADES INTELIGENTES

Transcrição

1 SEAN CARLISTO DE ALVARENGA TECNOLOGIAS PUSH E UMA ARQUITETURA DE NOTIFICAÇÃO PARA CIDADES INTELIGENTES LONDRINA PR 2013

2 SEAN CARLISTO DE ALVARENGA TECNOLOGIAS PUSH E UMA ARQUITETURA DE NOTIFICAÇÃO PARA CIDADES INTELIGENTES Trabalho de Conclusão de Curso apresentado ao curso de Bacharelado em Ciência da Computação da Universidade Estadual de Londrina para obtenção do título de Bacharel em Ciência da Computação. Orientador: Prof. Dr. Bruno Bogaz Zarpelão LONDRINA PR 2013

3 Sean Carlisto de Alvarenga Tecnologias Push e uma arquitetura de notificação para cidades inteligentes/ Sean Carlisto de Alvarenga. Londrina PR, p. : il. (algumas color.) ; 30 cm. Orientador: Prof. Dr. Bruno Bogaz Zarpelão Universidade Estadual de Londrina, Push Server. 2. Comet. 3. WebSocket. 4. Cidade inteligente. I. Bruno Bogaz Zarpelão. II. Universidade Estadual de Londrina. III. Push Technologies CDU 02:141:005.7

4 SEAN CARLISTO DE ALVARENGA TECNOLOGIAS PUSH E UMA ARQUITETURA DE NOTIFICAÇÃO PARA CIDADES INTELIGENTES Trabalho de Conclusão de Curso apresentado ao curso de Bacharelado em Ciência da Computação da Universidade Estadual de Londrina para obtenção do título de Bacharel em Ciência da Computação. BANCA EXAMINADORA Prof. Dr. Bruno Bogaz Zarpelão Universidade Estadual de Londrina Orientador Prof. Msc. Fábio Cezar Martins Universidade Estadual de Londrina Prof. Msc. Fábio Sakuray Universidade Estadual de Londrina Londrina PR, 24 de novembrode 2013 LONDRINA PR 2013

5 AGRADECIMENTOS Agradeço à minha família, em especial a minha mãe, pelo apoio e suporte em toda essa jornada. Agradeço também aos meus amigos por me aguentarem por todos esses anos. Agradeço aos Professores Bruno e Daniel, pelas conversas, as ajudas e por todos ensinamentos.

6 O que mais surpreende é o homem, pois perde a saúde para juntar dinheiro, depois perde o dinheiro para recuperar a saúde. Vive pensando ansiosamente no futuro, de tal forma que acaba por não viver nem o presente, nem o futuro. Vive como se nunca fosse morrer e morre como se nunca tivesse vivido. (Dalai Lama)

7 ALVARENGA, S. C.. Tecnologias Push e uma arquitetura de notificação para cidades inteligentes. 62 p. Trabalho de Conclusão de Curso (Graduação). Bacharelado em Ciência da Computação Universidade Estadual de Londrina, RESUMO O modelo de comunicação push server é ideal para notificações de eventos e transferência de dados em tempo real, permitindo que o servidor envie dados para o cliente sem que ele tenha explicitamente requisitado. Este trabalho explora o modelo push server, apresentando os principais conceitos das tecnologias Comet e WebSocket. Além disso, o trabalho apresenta uma aplicação de notificação de eventos em tempo real em cidades inteligentes, um conceito que surge da necessidade em gerenciar problemas decorrentes do crescimento populacional e urbanização em que a comunicação em tempo real é imprescindível. A aplicação desenvolvida utiliza o modelo push server através da tecnologia WebSocket. Palavras-chave: Push Server. Comet. WebSocket. Cidade inteligente.

8 ALVARENGA, S. C.. Push Technology and an notification architecture for smart cities. 62 p. Final Project (Undergraduation). Bachelor of Science in Computer Science State University of Londrina, ABSTRACT Real-time event notification and data delivery allows a web server to push data to a client, without the client explicitly request it. Push server model is used for this porpose. This paper explores push server model, presenting the main concepts of Comet and WebSocket technology. Furthermore, this paper presents an application that uses push server model through WebSocket technology to send real time event notification on smart cities, a concept that arises from the need to manage problems caused by population growth and urbanization where real time communication is essential. Keywords: Push Server. Comet. WebSocket. Cidade inteligente.

9 LISTA DE ILUSTRAÇÕES Figura 1 Exemplo do modelo cliente-servidor tradicional Figura 2 Um sistema de interação publish/subscribe Figura 3 Publish-Subscribe baseado em tópico Figura 4 Reverse Ajax com Comet Figura 5 Conexão TCP entre hosts Figura 6 Comunicação entre cliente e servidor com polling Figura 7 WebSocket vs Polling Figura 8 Comparação do tráfego de rede entre polling e WebSocket Figura 9 Campos obrigatórios e opcionais na requisição do opening handshake.. 36 Figura 10 WebSocket Frame Figura 11 Framework de coleta e disseminação de dados em cidades inteligentes.. 50 Figura 12 Visão geral da aplicação Figura 13 Monitoramento do trânsito das ruas e avenidas do estado da Califórnia. 52 Figura 14 Tela de login Figura 15 Conexão WebSocket com servidor Figura 16 Mapa com os sensores VDS Figura 17 Configuração de filtro Figura 18 Recebimento de notificação Figura 19 Dados da VDS que geraram a notificação Figura 20 Fluxo de mensagens entre cliente e servidor no cenário

10 LISTA DE TABELAS Tabela 1 Gerenciador de eventos Tabela 2 Opcodes e suas descrições Tabela 3 Status Code e suas descrições Tabela 5 Status Code e suas descrições Tabela 6 Valores e descrições do atributo readystate Tabela 7 Tipos de eventos e seus respectivos manipuladores Tabela 8 Dados coletados pelos sensores Tabela 9 Resultados para 252 notificações Tabela 10 Resultados sem notificações

11 LISTA DE ABREVIATURAS E SIGLAS AJAX AMQP API DOM GUID HTML HTTP IETF IP RFB RFC STOMP TCP UTF-8 WHATWG WWW W3C Asynchronous Javascript and XML Advanced Message Queuing Protocol Application Programming Interface Document Object Model Globally Unique Identifier HyperText Markup Language Hypertext Transfer Protocol Internet Engineering Task Force Internet Protocol Remote Frame Buffer Request for Comments Streaming Text Oriented Messaging Protocol Transmission Control Protocol 8-bit Unicode Transformation Format Web Hypertext Application Technology Working Group World Wide Web World Wide Web Consortium

12 SUMÁRIO 1 Introdução Tecnologia Push O modelo push server Aplicações Vídeo vigilância em tempo real Push Technology no World Bike Tour Monitoramento de pacientes SCADA em tempo real para parques eólicos Framework para jogos multiplayer online Publish/Subscribe O paradigma publish/subscribe Variações do modelo Publish/Subscribe Baseado em tópico Publish/Subscribe Baseado em conteúdo Comet Reverse Ajax O Protocolo HTTP Polling Comet Long Polling Comet HTTP Streaming WebSocket HTML 5 WebSocket WebSocket Protocol Opening handshake Mensagem WebSocket Closing Handshake API WebSocket Tecnologias Push e Cidades Inteligentes Cidades Inteligentes Implementação e resultados Implementação Resultados Conclusão

13 Referências

14 13 1 INTRODUÇÃO Aplicações Web utilizam o protocolo HTTP (Hypertext Transfer Protocol), um protocolo de request-response para o modelo cliente-servidor. Neste modelo, toda comunicação e transferência de dados entre cliente e servidor deve ser iniciada pelo cliente [1]. A comunicação é realizada de forma síncrona, onde o cliente requisita uma informação e fica completamente ocioso esperando pela resposta do servidor [2]. O protocolo HTTP possui uma solução simples para a troca de documentos na Web, motivo pelo qual foi desenvolvido. Contudo, aplicações clássicas que antes exibiam páginas com conteúdo estático, agora se tornaram aplicações Web dinâmicas em que tomar a iniciativa da comunicação com o cliente é essencial para uma experiência mais interativa e responsiva. Algumas aplicações exigem que em resposta a mudanças no estado do servidor, todos clientes sejam notificados. Por exemplo: um site de leilões, onde o usuário precisa ser notificado se outro apostador fez uma oferta maior [1]; preços de ações que são frequentemente atualizados; site de notícias que precisam atualizar os clientes sobre novas publicações, etc. Porém, o modelo cliente-servidor impede que o servidor tome a iniciativa pela comunicação com o cliente, impedindo a realização de notificação de eventos e transferência de dados em tempo real. Um modelo de comunicação baseado em push server permite que o servidor envie dados para o cliente assim que ocorra uma mudança em seu estado sem que este último tenha explicitamente requisitado, sendo ideal para comunicação em tempo real. Este trabalho explora o modelo push server, apresentando os principais conceitos das tecnologias Comet e WebSocket. O trabalho apresenta uma aplicação de envio de notificações de eventos em tempo real em cidades inteligentes utilizando a tecnologia WebSocket. Cidades inteligentes é um conceito que surge da necessidade em gerenciar problemas decorrentes do crescimento populacional e urbanização que afetam diretamente os serviços das cidades como transporte e segurança, além de causarem problemas relacionados a infraestrutura como a escassez de recursos, moradias em áreas de risco, aumento no tráfego de veículos e poluição. O modelo de cidades inteligentes busca soluções capazes de atenuar esses problemas em que a comunicação em tempo real e, portanto, o modelo push server são essenciais. O trabalho apresenta também resultados de testes realizados com dados de sensores reais que monitoram o tráfego de veículos de ruas e avenidas do estado da Califórnia. A organização do trabalho é como segue. O capítulo 2 apresenta em mais detalhes o contexto onde o modelo push server se encontra, o porque de sua necessidade e alguns exemplos de aplicações. O capítulo 3 apresenta o paradigma de interação chamado publush/subscribe que desempenha um papel importante no modelo push server. O ca-

15 Capítulo 1. Introdução 14 pítulo 4 e 5 apresentam as duas técnicas abordadas. O capítulo 6 mostra a aplicação desenvolvida e o resultado dos testes realizados.

16 15 2 TECNOLOGIA PUSH O protocolo HTTP possui limitações que impedem que o servidor tome a iniciativa na comunicação com o cliente. Com isso, não é possível que o servidor notifique os clientes assim que ocorrer alguma mudança em seu estado, característica exigida por aplicações que realizam notificações em tempo real. Tecnologias push utilizam um modelo de comunicação conhecido como push server que busca resolver essas limitações. Nesse capítulo, a organização é como segue. A seção 2.1 mostra uma visão geral do protocolo HTTP e quais suas limitações, contextualizando com a necessidade do modelo push server. A seção 2.2 mostra alguns exemplos de aplicações que utilizam o modelo. 2.1 O modelo push server O conteúdo da Web está hospedado em servidores, que fornecem seu conteúdo para clientes Web. Os clientes Web, por sua vez, solicitam dados para os servidores através de requisições e os servidores respondem aos clientes com os respectivos dados solicitados. Clientes e servidores possuem um acordo na forma em que se comunicam, um protocolo, comum para ambos. O Hypertext Transfer Protocol (HTTP) é o protocolo usado para se comunicar através da World Wide Web [3]. HTTP é um protocolo de request-response para o modelo tradicional clienteservidor [4]. Neste modelo, o cliente Web (geralmente um web browser) envia uma requisição para o servidor, que faz algum processamento e retorna uma resposta (uma página HTML, por exemplo). HTTP é um protocolo half-duplex, ou seja, tanto o cliente quanto o servidor podem enviar e receber dados, mas não simultaneamente. A figura 1 ilustra esse modelo. Figura 1 Exemplo do modelo cliente-servidor tradicional. Fonte: [3] p. 4. No modelo cliente-servidor tradicional, toda comunicação deve ser iniciada pelo cliente, impedindo que o servidor envie notificações sem uma requisição. Isso se torna uma desvantagem do modelo, pois há diversas situações nas quais se deseja atualizar os

17 Capítulo 2. Tecnologia Push 16 dados do cliente no momento em que ocorrerem essas atualizações no servidor. Preço de ações, notícias, informações sobre o clima [4], site de leilões e bate-papos [5], são alguns exemplos de informações que podem envelhecer se não são enviadas imediatamente aos clientes. Se o cliente deseja esses dados em tempo real, deve atualizar constantemente a página manualmente, uma solução ruim que pode gerar diversas requisições desnecessárias que irão aumentar a latência, o consumo da banda da rede e o consumo da CPU do servidor. Aplicações baseadas no modelo tradicional cliente-servidor que exigem notificações de eventos e transferência de dados em tempo real, na maioria das vezes, são implementadas utilizando a técnica de polling. Com polling, o cliente envia requisições HTTP para o servidor em intervalos regulares, verificando se houve atualizações. Se houver atualizações disponíveis, o servidor envia uma resposta com os dados para o cliente. Caso não haja alterações, a requisição do cliente foi desnecessária. O problema do uso da técnica de polling para notificações de eventos em tempo real é saber determinar qual intervalo de envio das requisições. A fim de se obter as atualizações mais recentes, esse intervalo precisa ser pequeno e, portanto, a frequência de verificações por atualizações será alta. Isso vai gerar um número muito grande de requisições (e possivelmente requisições desnecessárias) que podem causar sobrecarga no servidor. Porém, por outro lado, se esse intervalo for muito grande, a frequência de verificações será baixa e o cliente pode perder diversas atualizações. Polling é uma boa solução quando se sabe exatamente qual o intervalo em que as atualizações ocorrem no servidor, permitindo sincronizar as requisições HTTP do cliente nesse mesmo intervalo. Porém, dados em tempo real não são tão previsíveis, resultando em requisições desnecessárias e muitas conexões são abertas e finalizadas sem necessidade [6]. Um modelo de comunicação entre cliente-servidor baseado em push inverte o modelo tradicional. Push refere-se a um modelo de comunicação entre cliente-servidor onde é o servidor que inicia a comunicação. Neste modelo, é possível que o servidor envie dados para o cliente (push server) sem que ele tenha explicitamente solicitado [2]. Diferente do modelo tradicional, onde o cliente era responsável por fazer as requisições de dados ao servidor, no modelo push, é o servidor que empurra os dados para os clientes, utilizando um padrão chamado publish/subscribe. No padrão publish/subscribe (mais detalhes no capítulo 3), o cliente se registra em um ou mais serviços de seu interesse presentes no servidor e aguarda por atualizações. No momento em que ocorrerem atualizações em algum desses serviços, o servidor notifica todos os clientes que estão registrados nele. Com isso, o cliente não precisa mais buscar por atualizações, enviando requisições HTTP periodicamente ao servidor (polling). Ele será notificado pelo servidor assim que as atualizações ocorrerem.

18 Capítulo 2. Tecnologia Push Aplicações O protocolo HTTP impede que servidores Web iniciem uma comunicação com clientes. Uma alternativa para contornar essas limitações é através do uso de técnicas como Comet ou tecnologias como WebSocket. Exemplos de algumas aplicações onde são empregadas essas abordagens nas mais diversas áreas, são exibidos a seguir Vídeo vigilância em tempo real O trabalho proposto por [7] utiliza WebSocket para vídeo vigilância em tempo real. O trabalho argumenta que muitos dos reprodutores de mídia (media player) atuais são baseados em DirectX, Flash e ActiveX e possuem falhas na instalação, problemas na manutenção, defeitos de segurança, etc. O trabalho então propõe um novo reprodutor de mídia, baseado nos recursos do HTML 5 para vídeo vigilância em tempo real, utilizando WebSocket para enviar dados dos vídeos aos browsers sem a necessidade da utilização de plug-ins Push Technology no World Bike Tour A aplicação desenvolvida por [8] foi utilizada no evento World Bike Tour 2011 realizado em São Paulo. A aplicação tinha como objetivo mostrar um mapa no site do evento, que exibisse a posição de 12 bicicletas estacionárias, equipadas com sensores que mediam a distância percorrida. A implementação utilizou Comet para ler a distância percorrida das bicicletas de um banco de dados e, após projetar a posição dessas bicicletas no mapa, enviar essas informações para os clientes assim que disponíveis Monitoramento de pacientes A aplicação apresentada por [9] propõe um sistema complexo de monitoramento de eletrocardiograma de baixo custo. A ideia da aplicação é coletar dados de eletrocardiogramas através de um dispositivo conectado a pacientes, e enviar esses dados em tempo real para um servidor utilizando WebSocket para o monitoramento dos pacientes SCADA em tempo real para parques eólicos O aplicação desenvolvida por [10] propõe um Sistema de Supervisão e Aquisição de dados (SCADA) para parques éolicos, utilizados para produzir energia elétrica através do vento. SCADA permite monitorar os parques onde as informações coletadas seriam enviadas a um servidor e disponibilizadas em tempo real para os clientes através de uma aplicação Web utilizando Comet.

19 Capítulo 2. Tecnologia Push Framework para jogos multiplayer online O trabalho apresentado por [11], propõe um framework para jogos multiplayer online em browsers. O framework utiliza WebSocket para a comunicação entre clientes e servidores em tempo real.

20 19 3 PUBLISH/SUBSCRIBE O paradigma de interação publish/subscribe desempenha um papel fundamental no modelo push server, relacionando produtores de informações com consumidores. Nesse paradigma, clientes se registram no servidor para receber notificações em tempo real somente se essas notificações forem de eventos de seu interesse. Nesse capítulo, é abordado o paradigma de interação publish/subscribe. A seção 3.1 mostra o funcionamento do paradigma através de um exemplo de notificação em tempo real baseado em dados de sensores. A seção 3.2 mostra as variações do modelo que representam as diferentes formas de registro dos clientes no servidor. 3.1 O paradigma publish/subscribe O paradigma de interação publish/subscribe relaciona produtores de informações com consumidores [12]. Consumidores (subscribers assinantes) expressam seu interesse em um ou mais serviços, para que possam vir a ser notificados quando informações geradas nesses serviços por um produtor (publisher publicador), combinem com os de seu interesse. Para entendermos melhor o paradigma publish/subscribe, considere a figura 2, que ilustra um sistema de interação para o modelo publish/subscribe relacionado a dados de sensores. Figura 2 Um sistema de interação publish/subscribe. Produtores de informações sensores, publicam suas leituras (onde no modelo são tratados como eventos) em um banco de dados. Cada leitura é compostas pelo identificador do sensor mote_id, o dado da leitura data e quando foi realizado a leitura reading_time. mote_id: 1, data: 27.83, reading_time: :17:40 mote_id: 2, data: 47.47, reading_time: :17:41

21 Capítulo 3. Publish/Subscribe As leitura são enviadas do banco de dados para um gerenciador de eventos localizado no servidor. Consumidores de informações clientes assinam nesse gerenciador, para quais sensores desejam receber leituras. A função do gerenciador de eventos seria de receber e rotear as leituras dos sensores para seus respectivos assinantes, como ilustra a tabela 1. Tabela 1 Gerenciador de eventos. Sensor Assinantes 1 Cliente 1, 2 2 Cliente 3 3 Cliente 1, Em um modelo publish/subscribe, algumas operações são necessárias para a interação entre publicadores e assinantes. A operação Publish() é usada pelos publicadores para gerar um evento. Esse evento será propagado para todos assinantes por meio da operação Notify(). A operação Subscribe() registra um assinante em algum evento de seu interesse e Unsubscribe() remove esse assinante. O uso de um gerenciador de eventos como mediador proporciona um desacoplamento entre publicadores e assinantes. Esse desacoplamento elimina qualquer dependência entre eles, aumenta a escalabilidade (a adição ou remoção de publicadores ou assinantes são independentes da interação) e o ambiente dinâmico resultante se adapta bem em redes móveis onde há frequentes conexões e desconexões [12]. O desacoplamento pode ser descritos a partir de três variáveis [13]: Desacoplamento espacial: Publicadores e assinantes não precisam ter conhecimento uns dos outros. Publicadores não guardam referências de nenhum assinante e vice-versa. Publicadores e assinantes não sabem quantos membros participam da interação. Desacoplamento temporal: Publicadores e assinantes não precisam estar ativos ao mesmo tempo, ou seja, participar da interação simultaneamente. Publicadores podem gerar eventos, enquanto os assinantes interessados nesses eventos estão desconectados. Da mesma maneira, assinantes podem ser notificados por um evento enquanto o publicador desse evento está desconectado. Desacoplamento de sincronização: Publicadores não sofrem bloqueio ao gerar eventos e assinantes podem receber notificações de forma assíncrona mesmo realizando uma operação concorrente.

22 Capítulo 3. Publish/Subscribe Variações do modelo Assinantes recebem notificações apenas de eventos específicos nas quais se registraram. A forma do assinante representar seu interesse em algum evento, será usada como filtro de suas notificações e pode variar de acordo com diferentes esquemas da operação Subscribe() Publish/Subscribe Baseado em tópico O primeiro esquema publish/subscribe que surgiu é baseado na noção de tópicos ou assuntos. Em um publish/subscribe baseado em tópicos, cada publicador ou assinante gera ou declara interesse em tópicos identificados por palavras-chave. Cada tópico pode ser visto como um grupo, logo assinar um tópico T significa se tornar membro do grupo T [13]. A figura 3 ilustra esse modelo. Figura 3 Publish-Subscribe baseado em tópico. Fonte: Imagem retirada do site [14]. Considere o modelo de interação publish/subscribe relacionado a dados de sensores do início do capítulo. A listagem 3.1 mostra um exemplo onde um assinante se registra para receber leituras de sensores de dados climáticos (tópico). Caso o dado da leitura seja maior que 29, o assinante recebe um alarme. 1 public class SensorReading { 2 public int moteid ; // identificador do sensor 3 public float data ; // dados do monitoramento 4 } 5 6 public class SensorManager implements Subscriber { 7 // List < Object > contem as leituras dos sensores 8 public void update ( List < Object > list ) { 9 for ( Object obj : list ) { 10 if ((( SensorReading ) obj ). moteid == 1 11 && (( SensorReading ) obj ). data > 29) { 12 alarm ();

23 Capítulo 3. Publish/Subscribe } 14 } 15 } 16 } // Cria novo assinante 19 SensorManager sub = new SensorManager (); 20 // Registra novo assinante no gerenciador de eventos 21 EventManager. getarea (" weather "). subscribe ( sub ); Listagem 3.1 Exemplo de assinatura publish/subscribe baseado em tópico Publish/Subscribe Baseado em conteúdo O esquema publish/subscribe baseado em conteúdo difere do esquema publish/subscribe baseado em tópico por considerar o conteúdo dos eventos em vez de algum critério predefinido (nome do tópico) como filtro para a operação Subscribe(). Nesse esquema, os eventos são classificados de acordo com suas propriedades. Os assinantes se registram nos eventos passando algum filtro como parâmetro. Os filtros são restrições geralmente em pares nome-valor (moteid = 1) e com operadores de comparação (data > 29). Os filtros podem ser combinados com operadores lógicos (AND, OR, NOT, etc.) para formarem padrões de registro (moteid = 1 AND data > 29). A representação desses filtros pode variar, sendo na maioria das vezes representados por strings [13] que são interpretados pelo programa. O listagem 3.2 mostra um exemplo de uma assinatura baseada em conteúdo. 1 public class SensorReading { 2 public int moteid ; // identificador do sensor 3 public float data ; // dados do monitoramento 4 } 5 6 public class SensorManager implements Subscriber { 7 public void update ( List < Object > list ) { 8 alarm (); 9 } 10 } // Cria filtro 13 String filter = " moteid = 1 and data > 100 "; 14 // Cria novo assianante 15 SensorManager sub = new SensorManager (); 16 // Registra novo assinante no gerenciador de eventos 17 EventManager. getarea (" weather "). subscribe (sub, filter ); Listagem 3.2 Exemplo de assinatura publish/subscribe baseado em conteúdo.

24 Capítulo 3. Publish/Subscribe 23 Outros esquemas para assinaturas incluem Broadcast-Based Publish/Subscribe [14], List-Based Publish/Subscribe (conhecido como Observer Pattern [15]) e Type-Based Publish/Subscribe [13].

25 24 4 COMET No capítulo 2, vimos que a comunicação na Web é realizada pelo protocolo HTTP, um protocolo de request-response para o modelo cliente-servidor. O protocolo HTTP não permite que servidores iniciem a comunicação com os clientes e, portanto, aplicações que exigem essa característica precisam de alternativas como o modelo de comunicação push server. Nesse capítulo, é apresentada a tecnologia Comet, um conjunto de técnicas nas quais é possível utilizar o modelo push server. Comet também é conhecido como Reverse Ajax, por utilizar Ajax dentre outras tecnologias para permitir que o servidor tome a iniciativa na comunicação com o cliente. A seção 4.1 mostra uma visão geral do funcionamento das tecnicas de Comet. A seção 4.2 discorre em mais detalhes sobre o funcionamento do protocolo HTTP. As seções 4.3, 4.4 e 4.5 mostram as diferentes tecnicas utilizadas por Comet através de exemplos. 4.1 Reverse Ajax Aplicações Web, que antes exibiam páginas com conteúdo estático, onde cada requisição do usuário gerava uma nova a página HTML, agora se tornaram aplicações mais dinâmicas e interativas. Um dos responsáveis que proporcionou tais mudanças foi o Ajax (Asynchronous JavaScript and XML), um grupo de tecnologias que permite enviar e receber dados do servidor através de requisições assíncronas em segundo plano, com o objeto XMLHttpRequest. Isso evita que clientes fiquem ociosos a espera da resposta do servidor aumentando, portanto, a interatividade. Ajax possibilita atualizar pequenos fragmentos da página dinâmicamente através da manipulação do DOM com JavaScript, diminuindo tráfego de dados desnecessários e aumentando a responsividade das páginas. Porém, algumas aplicações Web como software colaborativos, site de notícias, informações sobre o clima [4], site de leilões, bate-papos [5], etc., exigem que em resposta a mudanças nos dados no lado do servidor, atualizações sejam enviadas imediatamente aos clientes, ou mais precisamente, em tempo real. Comet é um termo que foi cunhado em 2006 pelo Engenheiro de Software Alex Russell [16] que descreve um modelo de comunicação entre cliente e servidor onde a cada requisição do cliente, a conexão HTTP é persistida por um certo tempo, permitindo assim que nesse período o servidor envie dados para o cliente sem uma requisição explicita [2], ténica conhecida como push server. A figura 4 mostra as interações entre clientes e servidores utilizando Comet. Porém, para entendermos melhor porque é preciso utilizar técnicas como Comet para notificações em tempo real, precisamos entender a história da Internet e do protocolo

26 Capítulo 4. Comet 25 Figura 4 Reverse Ajax com Comet. Fonte: Imagem retirada do site [17]. HTTP. 4.2 O Protocolo HTTP A Internet é uma insfraestrutura de rede de comunicação entre computadores interconectados em escala mundial. Qualquer computador, onde ele estiver, pode se comunicar com outro em qualquer lugar do mundo contanto que ambos estejam conectados na Internet. Computadores conectados na rede são conhecidos como host. Cada host possuí uma forma de identificação única na rede, chamado de endereço IP (Internet Protocol). Através do endereçamento IP é possível localizar qualquer host na rede e iniciar uma comunicação para o compartilhamento de informações e recursos. O responsável pela comunicação, que realiza o transporte das informações entre hosts é o protocolo TCP (Transmission Control Protocol). O protocolo TCP pode ser visto como uma canal que transmite correntes de bytes (streams) em qualquer sentido como mostra a figura 5. O protocolo TCP utiliza o endereço IP para determinar a quem enviar as informações, encapsuladas em pequenos pacotes chamados de IP packages [3]. Juntos, o protocolo TCP sobre IP (TCP/IP) são usados por diversas aplicações na rede [4] como camada de transporte de dados. Figura 5 Conexão TCP entre hosts. Fonte: [3] p. 76.

27 Capítulo 4. Comet 26 Uma vez estabelecida a conexão TCP entre hosts, ambos podem enviar dados ao outro a qualquer momento de forma bidirecional (em qualquer sentido) e de maneira assíncrona (ao mesmo tempo). Muitos protocolos que exigem essa forma de comunicação entre as partes são construídos sobre o protocolo TCP/IP. Esses protocolos são conhecidos como protocolos de aplicação, como por exemplo, o IRC (Internet Relay Chat), utilizado basicamente como bate-papo. Outro protocolo bastante conhecido sobre TCP/IP é o protocolo HTTP, utilizado na World Wide Web. World Wide Web ou simplesmente Web, é um sistema de compartilhamento de documentos no formato hipertexto. A Web é construída sobre a Internet e a utiliza como meio onde serão compartilhados esses documentos. Os documentos na Web são conectados uns aos outros através de hiperlinks URLs (Universal Resource Locator), utilizados para o acesso a seus recursos. Os locais onde esses documentos estão hospedados na Web são chamados de servidores Web. O acesso a esses documentos é feito através de requisições de clientes Web para esses servidores, que retornam uma resposta com o respectivo recurso (HTML, imagem, audio, etc.). É razoável, portanto, um protocolo para essa comunicação (busca e transferência) entre clientes e servidores. Esse protocolo é conhecido como HTTP (Hypertext Transfer Protocol) e é amplamente usado na Web. O protocolo HTTP é um protocolo sobre TCP/IP. Antes do cliente enviar requisições ao servidor, uma conexão TCP precisa ser estabelecida. O protocolo HTTP utiliza o protocolo TCP/IP para localizar o servidor Web e transferir aos clientes os recursos solicitados. Uma vez que os recursos na Web são localizados por URLs, o protocolo HTTP precisa determinar qual IP do servidor através delas. Isso é realizado pelo DNS (Domain Name System), um sistema de gerenciamento de nomes capaz de resolver nomes de hosts em endereço IP, como mostra o exemplo a seguir: http : / /www. google. com. br http : / / Assim, de maneira simplificada, a comunicação entre clientes e servidores na Web realiza os seguintes passos: 1. O cliente (browser) extrai da URL o nome do host do servidor. 2. O DNS converte o nome do host no endereço IP do servidor. 3. O cliente estabelece uma conexão TCP com o servidor. 4. O cliente envia um requisição para o servidor. 5. O servidor retorna uma resposta ao cliente com o recurso solicitado. 6. A conexão TCP é finalizada.

28 Capítulo 4. Comet 27 Toda conexão é iniciada pelo cliente que endereça recursos no servidor através da URL. O servidor só pode retornar uma resposta ao cliente mediante a uma requisição, o que faz a comunicação ser realizada de forma síncrona (half-duplex). Além disso, após a comunicação a conexão é finalizada. Dessa maneira, o servidor trata cada requisição como única e independente e não guarda nenhuma informação sobre ela (stateless). Essas características do protocolo se tornam limitações para aplicações Web que necessitam comunicação bidirecional. Comet é uma das técnologias que contorna essas limitações através de técnicas de long polling e streaming. 4.3 Polling A forma mais simples e de fácil implementação para se obter atualizações o mais recente possível do servidor é através do polling [18]. A técnica de polling consiste em enviar requisições HTTP para o servidor em intervalos predefinidos como mostra a figura 6. Quanto menor for intervalo entre as requisições, mais rapidamente serão obtidas as atualizações do servidor, porém, mais requisições serão enviadas. Quanto maior for o número de requisições enviadas, maior será o tráfego da rede e o consumo de CPU do servidor e, se pensarmos em um número grande de clientes, a sobrecarga será ainda maior. A listagem 4.1 mostra um exemplo de polling com Ajax onde o intervalo entre as requisições são de 10 segundos. Figura 6 Comunicação entre cliente e servidor com polling. Fonte: Imagem retirada do site [17]. 1 jquery ( function ($) { 2 3 setinterval ( function () { 4 $. getjson ( webresources / android / sensor - get, function ( event ) { 5 if ( event. length ) { 6 for ( var i in event ) { 7 console. log ( Novas atualizacoes : + JSON. stringify ( event [i ])); 8 } 9 } else {

29 Capítulo 4. Comet // requisicao desnecessaria 11 console. log ( Nenhuma atualizacao disponivel ); 12 } 13 }); 14 }, 10000) ; 15 }); Listagem 4.1 Exemplo da técnica de polling. 4.4 Comet Long Polling Uma das técnicas utilizadas por Comet é a técnica de long polling. Long polling é uma técnica de fácil implementação no lado do cliente, mas que necessita de recursos especiais no lado do servidor. Uma requisição Ajax é enviada ao servidor onde será suspensa deixando assim uma conexão aberta. Com isso, no momento em que ocorrer alguma atualização no lado do servidor, é possível enviá-la ao cliente por essa conexão. Após o envio da resposta do servidor, a conexão é finalizada e uma nova requisição Ajax é realizada. A figura 4 mostra as requisições Ajax (Long-lived request #) e o momento em que são finalizadas (Long-lived request completes). A listagem 4.2 mostra um exemplo da técnica de long polling. 1 jquery ( function ($) { 2 3 function processevents ( events ) { 4 console. log ( processevents () ); 5 6 if ( events. length ) { 7 for ( var i in events ) { 8 console. log ( Novas atualizacoes : + JSON. stringify ( events [i])); 9 } 10 } 11 } function long_ polling () { 14 console. log ( long_polling () ); $. getjson ( long - polling, function ( event ) { 17 processevents ( event ); 18 long_ polling (); 19 }); 20 } long_ polling ();

30 Capítulo 4. Comet }); Listagem 4.2 Exemplo da técnica de long polling. 4.5 Comet HTTP Streaming A ténica de streaming consiste em abrir apenas uma conexão persistente, onde qualquer notificação do servidor será enviada por ela. Uma das formas de implementar essa técnica é através do objeto XMLHttpRequest, configurando a requisição com a flag multi-part. O cliente envia uma requisição ao servidor que será suspensa. Quando ocorrer qualquer atualização no lado do servidor, a conexão suspensa é utilizada para enviar os dados ao cliente. Uma das vantagens da técnica é o fato de utilizar apenas uma conexão persistente, o que economiza banda [17]. Porém, nem todos browsers suportam a flag multi-part, onde os dados enviados pelo servidor (multi-part) podem ser armazenados em um buffer e enviados aos clientes somente quando a conexão for finalizada ou quando o buffer estiver cheio [17]. A listagem 4.3 mostra um exemplo da tecnica streaming. 1 jquery ( function ($) { 2 3 if (!( XMLHttpRequest in window && multipart in window. XMLHttpRequest. prototype )) { 4 alert ( Seu browser nao suporta HTTP Streaming! ); 5 throw new Error ( Seu browser nao suporta HTTP Streaming! ); 6 } 7 8 function processevents ( events ) { 9 console. log ( processevents () ); if ( events. length ) { 12 for ( var i in events ) { 13 console. log ( Novas atualizacoes : + JSON. stringify ( events [i])); 14 } 15 } 16 } var xhr = $. ajaxsettings. xhr (); 19 xhr. multipart = true ; 20 xhr. open ( GET, streaming, true ); 21 xhr. onreadystatechange = function () { 22 if ( xhr. readystate == 4) { 23 processevents ($. parsejson ( xhr. responsetext )); 24 } 25 }; 26 xhr. send ( null );

31 Capítulo 4. Comet }); Listagem 4.3 Exemplo da técnica de streaming. Alguns servidores disponibilizam APIs que facilitam a implementação das técnicas Comet. O servidor Jetty possui a Continuation API que permite que requisições sejam pausadas e retomadas depois. O servidor Tomcat possui a API Advanced I/O. Outros servidores também dão suporte ao Comet através da implementação de APIs Non-blocking I/O (NIO). Porém, o uso dessas APIs faz com que as aplicações fiquem dependentes de características específicas de cada servidor. Um protocolo, em forma de especificação, denominado Bayeux Protocol [19] foi criado para padronizar a forma como se utiliza Comet e permitir a interoperabilidade entre aplicações. Além disso, alguns frameworks implementam o cliente Comet, onde o mais conhecido é CometD 1, que implementa o protocolo Bayeux e utiliza o padrão publish/subscribe para notificação de eventos. 1 <

32 31 5 WEBSOCKET WebSocket é uma tecnologia que permite a comunicação bidirecional entre clientes e servidores através de um canal full-duplex sobre um único socket. Após estabelecida a conexão WebSocket, clientes e servidores podem se comunicar de forma assíncrona, permitindo então que servidores envie notificações aos clientes a qualquer momento, possibilitando a comunicação em tempo real. Nesse capítulo, a seção 5.1 aborda a tecnologia WebSocket e mostra uma comparação no volume de tráfego na rede da tecnologia em relação a técnica de polling. A seção 5.2 aborda o protocolo WebSocket que define as regras de comunicação entre clientes e servidores, tais como regras para o estabelecimento de conexão, o formato das mensagens e o encerramento da conexão. A seção 5.3 aborda a API WebSocket, uma interface que permite que aplicações Web utilizem o protocolo WebSocket e controlem o canal bidirecional. 5.1 HTML 5 WebSocket O WebSocket faz parte da área de conectividade da especificação do HTML 5, que integra as técnologias: Cross Document Messaging, XMLHttpRequest Level 2, Server- Sent Events e WebSocket. O HTML 5 foi desenvolvido em conjunto por três organizações: Web Hypertext Application Technology Working Group (WHATWG), World Wide Web Consortium (W3C) e Internet Engineering Task Force (IETF). Seu desenvolvimento é baseado nos princípios de compatibilidade, utilidade, interoperabilidade e acesso universal [20]. A área de conectividade do HTML 5 tornou as conexões Web (entre cliente e servidor) mais eficientes, viabilizando o desenvolvimento de aplicações em tempo real como chat, jogos online, software colaborativos, etc., de uma forma mais fácil e simples em relação a ténicas (alternativas) usadas até então, como por exemplo, Comet (apresentado no capítulo 4). O WebSocket define uma conexão através de um único socket nativo, bidirecional (assíncrono). Após estabelecer uma conexão WebSocket, ao contrário do modelo clienteservidor tradicional descrito no capítulo 2, o servidor pode enviar mensagens aos clientes assim que atualizações estiverem disponíveis e não somente quando houver uma requisição. Da mesma maneira, o cliente pode enviar mensagens ao servidor a qualquer momento, sem a necessidade de esperar por uma resposta. Essa comunicação bidirecional reduz a latência, uma vez que não é mais necessário diversas requisições para verificar se ocorreram atualizações no servidor. A figura 7, mostra uma comparação da comunicação entre cliente e servidor utilizando a técnica de polling e WebSocket.

33 Capítulo 5. WebSocket 32 Figura 7 WebSocket vs Polling. Fonte: [4] p. 7. As requisições com polling são enviadas em intervalos (100 milisegundos), onde uma resposta é retornada pelo servidor nesse período. Isso, porém, nem sempre acontece, como no caso em que o servidor não possua atualizações para enviar ao cliente, tornando a requisição desnecessária. Com WebSocket, é necessária apenas uma requisição para atualizar a conexão e, após isso, cliente e servidor podem enviar mensagens utilizando o mesmo socket. GET / PollingStock // PollingStock HTTP / 1. 1 Host : localhost : 8080 User - Agent : Mozilla /5.0 ( Windows ; U; Windows NT 5.1; en -US; rv : ) Gecko / Firefox /3.5.5 Accept : text /html, application / xhtml +xml, application / xml ;q =0.9,*/*; q =0.8 Accept - Language : en -us Accept - Encoding : gzip, deflate Accept - Charset : ISO , utf -8; q =0.7,*; q =0.7 Keep - Alive : 300 Connection : keep - alive Referer : http :// www. example. com / PollingStock / Cookie : showinheritedconstant = false ; showinheritedprotectedconstant = false ; showinheritedproperty = false ; showinheritedprotectedproperty = false ; showinheritedmethod = false ; showinheritedprotectedmethod = false ; showinheritedevent = false ; showinheritedstyle = false ; showinheritedeffect =

34 Capítulo 5. WebSocket 33 false Listagem 5.1 Request Header. Fonte: [4], [21] e [6]. HTTP /1. x 200 OK X-Powered -By: Servlet /2.5 Server : Sun Java System Application Server 9.1 _02 Content - Type : text / html ; charset =UTF -8 Content - Length : 21 Date : Sat, 07 Nov : 32: 46 GMT Listagem 5.2 Response Header. Fonte: [4], [21] e [6]. As listagens 5.1 e 5.2 mostram o cabeçalho de uma única requisição e resposta de uma aplicação que exibe preços de ações em tempo real [6] [21]. A quantidade de informações dos cabeçalhos contém 871 bytes, sem incluir qualquer tipo de dado. Os exemplos a seguir, mostram o overhead no tráfego da rede (apenas com as informações dos cabeçalhos), quando ocorre 1 atualização por segundo, utilizando a técnica de polling para diferentes números de clientes. Caso de uso A: 1,000 clientes usando polling: tráfego da rede é ( ) = 871,000 bytes = 6,968,000 bits por segundo (6.6 Mbps) Caso de uso B: 10,000 clientes usando polling: tráfego da rede é ( ) = 8,710,000 bytes = 69,680,000 bits por segundo (66 Mbps) Caso de uso C: 100,000 clientes usando polling: tráfego da rede é ( ) = 87,100,000 bytes = 696,800,000 bits por segundo (665 Mbps) Considerando uma nova aplicação utilizando WebSocket onde a cada atualização do preço das ações, 1 mensagem WebSocket fosse enviada aos clientes. As mensagens WebSocket são frames que possuem apenas 2 bytes de informações (mais detalhes na seção API WebSocket 5.3). A figura 8 mostra um gráfico com os resultados da diferença de tráfego desnecessário entre polling e WebSocket. Caso de uso A: 1,000 clientes recebem 1 mensagem por segundo: tráfego da rede é ( ) = 2,000 bytes = 16,000 bits por segundo (0.015 Mbps) Caso de uso B: 10,000 clients recebem 1 mensagem por segundo: tráfego da rede é ( ) = 20,000 bytes = 160,000 bits por segundo (0.153 Mbps) Caso de uso C: 100,000 clientes recebem 1 mensagem por segundo: tráfego da rede é ( ) = 200,000 bytes = 1,600,000 bits por segundo (1.526 Mbps)

35 Capítulo 5. WebSocket 34 Figura 8 Comparação do tráfego de rede entre polling e WebSocket. Fonte: Imagem retirada do site [6]. 5.2 WebSocket Protocol O protocolo WebSocket define como clientes e servidores devem se comunicar pela rede [4]. O protocolo foi publicado pela IETF (Internet Engineering Task Force), uma comunidade internacional aberta que padroniza os protocolos usados na Internet. A IETF publica RFCs (Request for Comments) dos protocolos, que especificam precisamente cada um deles. O RFC 6455, foi publicado em dezembro de 2011 e é o RFC que determina o The WebSocket Protocol [22]. O RFC 6455 define as regras para implementação do protocolo WebSocket tanto para o lado do cliente quanto do servidor. O protocolo WebSocket consiste basicamente de um opening handshake seguido por mensagens constituídas de frames e utiliza o estilo de comunicação do protocolo TCP [22], que serve de base para o WebSocket. Na seção 4.2, vimos que o modelo HTTP possui limitações que impedem que servidores tomem a iniciativa na comunicação com clientes, impedindo assim que aplicações Web possuam comunicação bidirecional. Algumas das alternativas é a utilização de técnicas como Comet, que possui alguns métodos para contornar essas limitações. Contudo, essas técnicas são realizadas sobre o próprio protocolo HTTP, que foi projetado para o simples compartilhamento de documentos. Assim, obter uma comunicação assíncrona sobre um protocolo de natureza síncrona, faz com que essas técnicas sejam complexas e ineficientes [4]. Esses motivos levaram a criação de um novo protocolo, o protocolo WebSocket Opening handshake O protocolo WebSocket mantém algumas características do HTTP, como as URLs e mensagens do tipo texto. A conexão ainda precisa ser iniciada pelo cliente, porém, o

36 Capítulo 5. WebSocket 35 protocolo possui o estilo de comunicação do TCP, ou seja, uma vez estabelecida a conexão, as mensagens são enviadas de forma biderecional. Uma conexão WebSocket é estabelecida após a realização de um opening handshake. O handshake é iniciado por uma requisição HTTP do cliente para o servidor, com o campo Upgrade no cabeçalho. Esse campo sinaliza que o cliente deseja atualizar a conexão para um outro procolo, nesse caso WebSocket, como mostra a listagem 5.3. Cache - Control :no - cache Connection : Upgrade Cookie : utma = ; utmz = utmcsr = websocket. org utmccn =( referral ) utmcmd = referral utmcct =/ echo. html Host : echo. websocket. org Origin : chrome :// newtab Pragma :no - cache Sec - WebSocket - Extensions :x-webkit - deflate - frame Sec - WebSocket - Key : beghyslwev57edxqng43qa == Sec - WebSocket - Version :13 Upgrade : websocket User - Agent : Mozilla /5.0 ( X11 ; Linux x86_64 ) AppleWebKit / ( KHTML, like Gecko ) Chrome / Safari / Listagem 5.3 Opening handshake do cliente. No cabeçalho da requisição, alguns campos relacionados ao opening handshake do WebSocket são obrigatórios e outros opcionais, como mostra figura 9. Os campos opcionais são usados para selecionar preferências no protocolo WebSocket [22]. Os três campos são: Sec-WebSocket-Origin, Sec-WebSocket-Protocol e Sec-WebSocket-Extensions. O campo Sec-WebSocket-Origin é usado para proteção contra o uso de crossorigin não autorizado do WebSocket por scripts que usam a API WebSocket [22]. A maioria dos browsers possuem uma política de segurança que permite o acesso a recursos de um domínio (host), somente de requisições HTTP geradas por esse mesmo domínio. Por exemplo, aplicações que fazem requisições por script (usando XMLHttpRequest, como em Comet), só podem acessar recursos que estejam no mesmo domínio onde o script foi carregado. Portando, o servidor é informado pelo campo Sec-WebSocket-Origin qual a origem do script que gerou a requisição para estabelecer a conexão WebSocket. O servidor então pode optar por aceitar ou rejeitar essa requisição. O campo Sec-WebSocket-Protocol é usado para negociação de protocolos, ou seja, indica quais os protocolos serão usados sobre o protocolo WebSocket. Assim como o TCP, o WebSocket pode ser usado como uma camada de transporte para outros protocolos como XMPP (Extensible Messaging and Presence Protocol) e STOMP (Streaming Text Orientated Messaging Protocol). Esse campo é enviado do cliente para o servidor

37 Capítulo 5. WebSocket 36 Figura 9 Campos obrigatórios e opcionais na requisição do opening handshake. Fonte: [4]. p. 41. especificando quais protocolos o cliente poder usar e, do servidor para o cliente, onde o servidor escolhe no máximo um protocolo que entende e que será usado sobre o WebSocket (mais detalhes na seção 5.3). O campo Sec-WebSocket-Extensions é enviado do cliente para o servidor e depois do servidor para o cliente, como um acordo no conjunto de extensões de protocolos que serão usadas nessa conexão [22]. Após o envio da requisição do cliente para o servidor, é preciso que o servidor comprove o recebimento. Isso garante que o servidor entende o protocolo WebSocket e também funciona como uma medida de segurança, onde somente conexões WebSocket serão aceitas. Para comprovar o recebimento, o servidor utiliza o valor do campo Sec-WebSocket-Key do cabeçalho enviado pelo cliente e concatena com uma constante GUID (Globally Unique Identifier) 258EAFA5-E914-47DA-95CA-C5AB0DC85B11 que todo servidor WebSocket deve conhecer [4]. Após a concatenção, é preciso aplicar o hash SHA-1 (160 bits) e finalmente no resultado do hash, a codificação Base64. O resultado desse valor é o valor do campo Sec-WebSocket-Accept no cabeçalho do servidor. Para exemplificar: na listagem 5.3, o valor do campo Sec-WebSocket-Key é beghyslwev57edxqng43qa==. Concatenando esse valor com o valor do GUID resulta em beghyslwev57edxqng43qa==258eafa5-e914-47da-95ca-c5ab0d Aplicando o hash SHA-1, obtêm-se 37cb e536ff728d adf6a4dcea e finalmente codificando na Base64 resulta em N8t2dxJhXlNv9yjQMimFrfak3Oo=, como mostra a listagem 5.4.

38 Capítulo 5. WebSocket 37 Access - Control - Allow - Credentials : true Access - Control - Allow - Headers : content - type Access - Control - Allow - Origin : chrome :// newtab Connection : Upgrade Date : Thu, 31 Oct : 03: 57 GMT Sec - WebSocket - Accept : N8t2dxJhXlNv9yjQMimFrfak3Oo = Server : Kaazing Gateway Upgrade : WebSocket Listagem 5.4 Opening handshake do servidor. Se o opening handshake foi realizado com sucesso, um código de status 101 é retornado pelo servidor como mostra a figura 5.5. Se o valor do Sec-WebSocket-Accept não for igual ao valor esperado, ou se o campo estiver faltando ou o código de retorno não for 101, a conexão WebSocket não será estabelecida [22]. Request URL :ws :// echo. websocket. org / Request Method : GET Status Code : 101 Web Socket Protocol Handshake Listagem 5.5 WebSocket opening handshake realizado com sucesso Mensagem WebSocket Após a realização do handshake com sucesso, a conexão WebSocket é estabelecida e mensagens podem ser trocadas entre cliente e servidor. WebSocket usa um formato de mensagem binária de frames para a comunicação pela rede. Cada mensagem é dividida em um ou mais frames, onde são reagrupadas ao chegar no destinatário. A figura 10 mostra um frame WebSocket. Figura 10 WebSocket Frame. Fonte: Imagem retirada do site [23]. e Payload. Cada frame é composto pelos campos: FIN, Opcodes, Mask e Lenght, Masking-key

39 Capítulo 5. WebSocket 38 FIN : O primeiro bit do cabeçalho do frame. Esse campo indica se esse frame representa o último frame de uma mensagem. O primeiro frame de uma mensagem pode também ser o último caso tenha sido utilizado apenas um frame por mensagem. RSV1, RSV2, RSV3 : 1 bit cada campo, após o campo FIN. O valor desses campos devem ser 0 caso não tenha sido negociado nenhuma extensão no opening handshake. Caso o valor desses campos sejam diferente de 0 e esse valor não corresponda ao valor da extensão negociada, cliente ou servidor que receber esse frame deve encerrar a conexão. Opcode: São os últimos quatro bits do primeiro byte. Esse campo é um valor númerico que indica qual o tipo de mensagem está sendo transferido pelo frame. Com a utilização de quatro bits, é possível a combinação de 16 valores, como mostra a tabela 2. Mask: 1 bit que indica se o frame está usando máscara ou não. Máscaras são usadas para ofuscar o conteúdo dos frames, como medida de segurança e compatibilidade com proxies HTTP [4]. Se o valor do campo for definido como 1, uma chave é armazenada no campo Masking-key do frame que será usada para decodificar (unmask) o conteúdo original. Todas mensagens do cliente devem ter o valor do campo definido como 1. Length: 7 bits, 7+16 bits ou 7+64 bits. Esse campo indica qual o comprimento das mensagens em bytes: Para mensagens entre 0 e 125 bytes, o comprimento será armazenado nos 7 últimos bits do segundo byte do frame. Mensagens de 126 bytes, os próximos 2 bytes (7+16 bits) determinam o seu comprimento. Mensagens de 127 bytes, os próximos 8 bytes (7+64 bits) determinam o seu comprimento. O valor do comprimento é necessário para determinar a quantidade de bits que será decodificada para obter o conteúdo original dos dados. Mensagens maiores de 127 bytes serão fragmentadas em mais frames. Masking-key: Esse campo contém um valor de 32-bit utilizados como máscara dos dados caso o bit do campo Mask for 1. Esse valor será ausente caso o bit do campo Mask for 0. Payload: O campo Payload contém os dados transmitidos pela rede (dados das mensagens) mais os dados adicionais de extensões (se o cliente e servidor negociaram alguma extensão no opening handshake).

40 Capítulo 5. WebSocket 39 Tabela 2 Opcodes e suas descrições. Opcode (Hexadecimal) Tipo da mensagem Descrição 0 Frame de continuação Esse frame possui dados que devem ser agrupados com o frame anterior. 1 Texto O tipo de dado da mensagem é texto. 2 Binário O tipo de dado da mensagem é binário. 3-7 Reservado para futuras extensões. 8 Close Closing handshake para encerrar a conexão. 9 Ping Mensagem para verificar se a conexão está viva. 0xA Pong Mensagem para verificar se a conexão está viva. 0xB-F Reservado para futuros frames de controle (utilizados para comunicar estado do WebSocket) Closing Handshake Após completar a comunicação entre cliente e servidor, a conexão WebSocket pode ser finalizada. Esse cenário representa que o propósito da conexão foi realizado com sucesso. Porém, outros motivos podem levar ao encerramento da conexão. O Close handshake do protocolo WebSocket finaliza a conexão através de um frame, com o campo Opcode 8, e uma mensagem onde são especificados o código de status (um inteiro de 16-bits sem sinal) e a razão (uma string codificada em UTF-8) pelo término da conexão. Isso permite à aplicação diferenciar se uma conexão foi finalizada intencionalmente ou por alguma falha. A tabela 3 mostra os códigos de status ( ) definidos pelo RFC-6455 [22] e a suas descrições. Tabela 3 Status Code e suas descrições. Código Significado Descrição 1000 Normal close Indica que o propósito da conexão WebSocket foi realizado com sucesso.

41 Capítulo 5. WebSocket Going Away Indica que não é mais possível atingir cliente ou servidor. Por exemplo, quando o cliente deixa a página onde foi estabelecida a conexão Protocol Error Indica que cliente ou servidor encerrará a conexão devido a erro de protocolo Unacceptable Data Type Indica que cliente ou servidor encerrará a conexão por ter recebido um tipo de dado que não entende, como por exemplo, mensagens do tipo texto quando deveriam ser mensagens binárias Reserved Reservado Invalid Data Indica que cliente ou servidor encerrará a conexão por receber o conteúdo de uma mensagem não compatível com seu tipo. Por exemplo, mensagem de texto não UTF Message Violates Policy Código genérico para ser usado quando não houver nenhum outro status code mais adequado Message Too Large Indica que cliente ou servidor encerrará conexão devido o recebimento de uma mensagem muito grande Extension Required Indica que o cliente encerrará a conexão por requisitar alguma extensão específica que o servidor não negociou Unexpected Condition Indica que o servidor encerrará a conexão devido a condições inesperadas que o impedem de cumprir a requisição TLS Failure (reserved) Valor reservado para indicar a aplicação que a conexão foi finalizada devido a falha do TSL handshake. a tabela 5. Outros códigos de status são reservados para propósitos específicos, como mostra

42 Capítulo 5. WebSocket 41 Tabela 5 Status Code e suas descrições. Código Significado Descrição Proibido Status code abaixo de 1000 são inválidos e não devem ser usado para nenhum propósito Reservado Reservado para futuras revisões e extensões do protocolo Registro obrigatório Reservado para o uso de bibliotecas, frameworks e aplicações registrados diretamente no IANA (Internet Assigned Numbers Authority) Privado Reservado para o uso privado pelas aplicações e não podem ser registrados. 5.3 API WebSocket A API WebSocket é uma interface que permite que aplicações Web utilizem o protocolo WebSocket e controlem um canal de comunicação biderecional com servidores para enviar e receber mensagens. A interface especifica os métodos dos clientes e como ele interage com a rede. A listagem 5.6 mostra a interface WebSocket. 1 [ Constructor ( in DOMString url, in optional DOMString protocols )] 2 [ Constructor ( in DOMString url, in optional DOMString [] protocols )] 3 interface WebSocket { 4 readonly attribute DOMString url ; 5 6 // ready state 7 const unsigned short CONNECTING = 0; 8 const unsigned short OPEN = 1; 9 const unsigned short CLOSING = 2; 10 const unsigned short CLOSED = 3; 11 readonly attribute unsigned short readystate ; 12 readonly attribute unsigned long bufferedamount ; // networking 15 attribute Function onopen ; 16 attribute Function onmessage ; 17 attribute Function onerror ; 18 attribute Function onclose ; 19 readonly attribute DOMString protocol ; 20 void send ( in DOMString data ); 21 void close (); 22 };

43 Capítulo 5. WebSocket WebSocket implements EventTarget ; Listagem 5.6 Interface WebSocket W3C [24]. A interface WebSocket possui dois construtores (linhas 1 e 2 da listagem 5.6). Uma chamada ao construtor abre uma conexão WebSocket, que retorna um objeto WebSocket, como mostra a figura // new WebSocket (" url "); 2 var websocket = new WebSocket ("ws :// echo. websocket. org "); 3 // new WebSocket (" url ", protocols ); 4 var ws = new WebSocket ("ws :// echo. websocket. org ", [" protocolone ", " protocoltwo "]); Listagem 5.7 Os contrutores do WebSocket. O construtor tem como parâmetro um ou dois argumentos. O primeiro argumento (URL) é obrigatório e representa o local onde se quer conectar (servidor, por exemplo). A URL deve ter o esquema ws:// ou wss:// (análogo ao HTTP e HTTPS). O segundo argumento é opcional, uma string ou um vetor de string que representa um protocolo (ou vetor de protocolos, respectivamente) para negociação. Caso não haja argumentos, é considerado um vetor vazio. Os protocolos que podem ser usados incluem: Extensible Messaging and Presence Protocol (XMPP), Advanced Message Queuing Protocol (AMQP), Remote Frame Buffer (RFB) e Streaming Text Oriented Messaging Protocol (STOMP). Esses são alguns protocolos padrões, o que garante a interoperabilidade entre aplicações de diferentes organizações [21]. Dessa maneira, quando fornecido um protocolo, a conexão irá se estabelecer somente quando o servidor escolher um deles. Isso é necessário para garantir que cliente e servidor entendam o mesmo protocolo e também permite maior flexibilidade ao cliente por poder fornecer ao servidor todos os protocolos que implementa, onde o servidor opta por um. Após tentar estabelecer a conexão, o atributo readystate (linha 11 da listagem 5.6), assume diferentes valores, dependendo em qual evento do ciclo de vida da conexão ele se encontra. A tabela 6 mostra esses valores. Tabela 6 Valores e descrições do atributo readystate. Constante Valor Status CONNECTING 0 A conexão ainda não foi estabelecida. OPEN 1 A conexão foi estabelecida e a comunicação já é possível. CLOSING 2 A conexão se encontra no closing handshake. CLOSED 3 A conexão finalizou ou não foi possível estabelecê-la.

44 Capítulo 5. WebSocket 43 Se a conexão foi estabelecida com sucesso, o atributo protocol (linha 19 da listagem 5.6) contém o nome do protocolo escolhido pelo servidor na negociação, se houver. A API WebSocket é puramente orientada a eventos. O objeto WebSocket (retornado pelo construtor após estebelecer a conexão) escuta a eventos para receber mensagens e notificações no mesmo momento em que ocorrerem, em vez de repetidamente pedir atualizações para o servidor. Os eventos definidos pela interface são: Open - Quando a conexão é aberta. Message - Quando recebe mensagens. Error - Quando acontece um erro. Close - Quando a conexão é finalizada. As linhas 15 à 18 mostram os quatro manipuladores de eventos callbacks da interface que são disparados a esses quatro eventos. A tabela 7 mostra os tipos de eventos e seus respectivos manipuladores. Tabela 7 Tipos de eventos e seus respectivos manipuladores. Manipulador do evento onopen onmessage onerror onclose Tipo do evento Open Message Error Close O callback onopen é disparado assim que a conexão é estabelecida, ou seja, a partir daí já é possível o envio e recebimento de mensagens entre cliente e servidor. 1 var ws = new WebSocket ("ws :// echo. websocket. org "); 2 3 ws. onopen = function (e) { 4 alert (" Conexao aberta. Protocolo : " + e. target. protocol ); 5 }; Listagem 5.8 Callback onopen. O callback onmessage, é disparado ao receber mensagens. Apesar das mensagens WebSocket serem constituídas de frames, a API WebSocket expõe somente mensagens completas [4]. A API WebSocket suporta diferentes tipos de mensagens: string, e mensagens binárias que são tratadas como Blob ou ArrayBuffer.

45 Capítulo 5. WebSocket 44 1 ws. onmessage = function ( message ) { 2 if ( message. data == " string ") { 3 alert (" Mensagem recebida : " + message. data ); 4 } 5 }; Listagem 5.9 Mensagens do tipo string. Para mensagens binárias, é necessário definir na aplicação pelo atributo binarytype como tratar o tipo binário, uma vez que isso afetará as mensagens recebidas. As listagens 5.10 e 5.11 mostram um exemplo. 1 ws. binarytype = " blob "; 2 3 ws. onmessage = function ( message ) { 4 if ( message. data instanceof Blob ) { 5 var data = new Blob ( message. data ); 6 //... 7 } 8 }; Listagem 5.10 Mensagens do tipo blob. 1 ws. binarytype = " arraybuffer "; 2 3 ws. onmessage = function ( message ) { 4 if ( message. data instanceof ArrayBuffer ) { 5 var data = new Uint8Array ( message. data ); 6 7 for ( var i = 0; i < data. bytelength ; i ++) { 8 // byte a byte do array 9 } 10 } 11 }; Listagem 5.11 Mensagens do tipo ArrayBuffer. O evento Error, dispara o callback onerror quando alguma falha acontece no objeto WebSocket e encerra a conexão (através do evento Close). Os atributos code e reason da interface CloseEvent podem ajudar a sinalizar qual foi a causa do erro. 1 ws. onerror = function ( reason ) { 2 alert (" Erro! Motivo : " + reason ); 3 }; Listagem 5.12 Callback onerror.

46 Capítulo 5. WebSocket 45 O último evento, Close, que dispara o callback onclose, possui uma interface como mostra a listagem Essa interface possui os atributos wasclean, code e reason, linhas 2 à 4. O atributo wasclean é um boolean que indica se a conexão foi finalizada por motivos normais (pelo closing handshake, após a chamada do método close()) ou por alguma eventualidade (falha na conexão, por exemplo). O atributo code é um valor numérico indicando o status code explicando o motivo do encerramento da conexão. O atributo reason é uma representação em texto String que contém o motivo do encerramento da conexão (representação para humanos) [25]. 1 interface CloseEvent : Event { 2 readonly attribute boolean wasclean ; 3 readonly attribute unsigned long code ; 4 readonly attribute DOMString reason ; 5 void initcloseevent ( in DOMString typearg, in boolean canbubblearg, in boolean cancelablearg, in boolean wascleanarg, in unsigned long codearg, in unsigned long reasonarg ); 6 }; Listagem 5.13 Interface do evento Close. O objeto WebSocket possui dois métodos (linhas 20 e 21 da listagem 5.6) send() e close(). Esses métodos não são métodos callback de eventos e são usados para o envio de mensagens e para encerrar a conexão WebSocket respectivamente. O método send() é usado após estabelecido a conexão bidirecional para enviar mensagens - string ou binária - para o servidor. O método possui um argumento data, que é a mensagem a ser enviada, como mostra a listagem Normalmente, os browsers (clientes) utilizam um buffer para os dados de saída. O atributo bufferedamount, mostra a quantidade de bytes que foram enfileirados por chamadas ao método send() mas não enviados ainda para a rede. 1 // mensagem texto 2 var message = " Mensagem para o servidor "; 3 4 // mensagem binaria 5 var binarymessage = new Uint8Array ([1,2,3,4,5]) ; 6 7 if ( ws. readystate == WebSocket. OPEN ) { 8 ws. send ( message ); 9 ws. send ( binarymessage. buffer ); 10 } else { 11 // conexao nao esta aberta 12 } Listagem 5.14 Exemplo de envio de uma mensagem texto e binária.

47 Capítulo 5. WebSocket 46 O método close() é usado para encerrar uma conexão ou uma tentativa de conexão. Caso contrário, o método close() nada faz. Uma vez encerrada a conexão, o envio e recebimento de mensagens entre cliente e servidor não é mais possível. O método possui dois argumentos opcionais: code e reason (discutidos anteriormente). Se o argumento code não for especificado, é assumido o valor default 1000, como mostra a listagem // encerrar a conexao 2 // 1000 = CLOSE_ NORMAL 3 ws. close (1000, " Finalizando normalmente "); Listagem 5.15 Exemplo de encerramento de conexão. Existem bibliotecas que implementam WebSocket tanto o lado do cliente como servidor na maioria das linguagens. Além disso, alguns browsers não possuem suporte para WebSocket 1. A listagem 5.16 mostra um exemplo em Java para Android, utilizando a biblioteca Autobahn 2, que estabelece uma conexão WebSocket com um servidor que recebe e envia todas mensagens recebidas de volta para o cliente. 1 private final WebSocketConnection mconnection 2 = new WebSocketConnection (); 3 4 private void start () { 5 final String wsuri = "ws :// echo. websocket. org "; 6 7 try { 8 mconnection. connect ( wsuri, new WebSocketHandler () { 9 Override 11 public void onopen () { 12 Log.d(" onopen ", " Status : Conectado a: " + wsuri ); 13 mconnection. sendtextmessage ("Ola, mundo!"); 14 } 15 Override 17 public void ontextmessage ( String payload ) { 18 Log.d(" ontextmessage ", " Eco : " + payload ); 19 } 20 Override 22 public void onclose ( int code, String reason ) { 23 Log.d(" onclose ", " Conexao finalizada." + reason ); 24 } 25 }); 1 < 2 <

48 Capítulo 5. WebSocket } catch ( WebSocketException e) { 27 Log.d(" Exception : ", e. tostring ()); 28 } 29 } Listagem 5.16 Cliente WebSocket para Android utilizando a biblioteca Autobahn.

49 48 6 TECNOLOGIAS PUSH E CIDADES INTELI- GENTES Nesse capítulo, é apresentada uma aplicação que utiliza o modelo de comunicação push server no contexto de cidades inteligentes. Como discutido nos capítulos anteriores, o modelo push server permite que aplicações realizem a notificação de eventos e transferência de dados em tempo real. Uma das características inerentes a cidades inteligentes é o monitoramento e disseminação de dados em tempo real. Em cidades inteligentes, o monitoramento em tempo real produz informações relevantes que devem ser disseminadas imediatamente aos usuários. A organização do capítulo é como segue. A seção 6.1 aborda o conceito sobre cidades inteligentes, o porque de sua necessidade e qual o seu propósito. A seção 6.2 apresenta uma aplicação de notificação em tempo real desenvolvida nesse trabalho que utiliza o modelo de comunicação push server através da tecnologia WebSocket, bem como a arquitetura da aplicação e as tecnologias utilizadas. 6.1 Cidades Inteligentes Tornar uma cidade inteligente é uma estratégia já usada por alguns países com o objetivo de atenuar problemas gerados pelo crescimento populacional e pela urbanização. Segundo dados das Nações Unidas, em 2050, 70% da população mundial viverá em áreas urbanas [26]. Esse rápido processo de urbanização tende a criar transtornos para as cidades, afetando diretamente diversos serviços como transporte, segurança, fornecimento e consumo de água e energia [27]. Com esse rápido crescimento, surgem também problemas relacionados a infraestrutura como a escassez de recursos, moradias em áreas de risco, aumento no tráfego de veículos e poluição [28]. O conceito de cidades inteligentes envolve realizar o gerenciamento dos serviços fornecidos pelas cidades a fim de atenuar esses problemas. O gerenciamento dos serviços nas cidades inteligentes requer constante monitoramento e coleta de dados, realizados com a utilização de Tecnologias da Informação e Comunicação (TIC). Os dados coletados passam por um processo de análise onde uma decisão em tempo real pode ser tomada com o objetivo de reduzir custos, melhorar a eficiência e fornecer serviços de qualidade para a população. A coleta e análise dos dados são processos que devem ser integrados onde os dados coletados precisam ser relacionados e as decisões tomadas devem considerar fatores externos e outros serviços [27]. O conceito de cidades inteligentes ajuda a atenuar os problemas citados no inicio da seção. O monitoramento de ruas e avenidas das cidades podem fornecer informações sobre o trânsito lento para outros motoristas; o monitoramento do nível de água de rios

50 Capítulo 6. Tecnologias Push e Cidades Inteligentes 49 fornecem informações que ajudam a antecipar um possível transbordamento no caso de chuvas; o monitoramento da qualidade ar em tempo real pode fornecer informações aos cidadãos quando o índice de poluição estiver muito elevado, etc. As peculiariedades das cidades como o clima, tamanho, os problemas sociais e de infraestrutura, restrições financeiras e ambientais, dificulta a criação de uma arquitetura de um sistema que possa ser generalizado para qualquer cidade. Algumas condições, porém, são características de domínios inerentes as cidades, como características sociais, tecnológicas, culturais e de infraestrutura. O trabalho de [27] faz o levantamento de diversas arquiteturas de cidades inteligentes e com base nas arquiteturas analisadas, propõe quais são as condições necessárias ao projetar uma cidade inteligente: interoperabilidade dos objetos, sustentabilidade, monitoramento em tempo real, histórico dos dados, mobilidade, disponibilidade, privacidade, detecção e processamento distribuído, composição de serviços e gestão urbana integrada, aspectos sociais, flexibilidade/extensabilidade. Na próxima seção, um projeto de um framework de cidades inteligentes que busca atender algumas dessas condições é apresentado junto a uma aplicação de notificação em tempo real desenvolvida para esse projeto. 6.2 Implementação e resultados O projeto intitulado Framework para serviços de coleta e disseminação de dados em cidades inteligentes da Universidade Estadual de Londrina, propõe um framework de cidades inteligentes. O projeto é ilustrado pela figura 11. Esse framework é dividido em alguns processos: Coleta dos dados em tempo real: elementos denominados coletores - sensores, microfone, câmera, radares, etc. - são utilizados para adquirir dados do espaço urbano. Posteriormente, esses dados são enviados para o serviço apropriado no Smart City Web Services (SCWS), um ambiente que reúne serviços de cadastramento de novos coletores, recebimento armazenamento dos dados coletados, consulta pelos usuários dos dados coletados e serviços de notificação em tempo real para disseminação de eventos importantes. Análise dos dados coletados: a análise dos dados está ligado com a natureza das informações obtidas. Por exemplo, é possível analisar o fluxo de carros em ruas e avenidas e determinar se há ou não um congestionamento. Disseminação dos dados aos cidadãos: após a análise dos dados, notificações são enviadas aos clientes caso seja detectado algum evento importante (congestionamento de uma avenida).

51 Capítulo 6. Tecnologias Push e Cidades Inteligentes 50 Figura 11 Framework de coleta e disseminação de dados em cidades inteligentes. A aplicação desenvolvida neste trabalho integra o projeto intitulado Framework para serviços de coleta e disseminação de dados em cidades inteligentes e consiste em uma aplicação para disseminação de dados para os usuários de cidades inteligentes através de notificações enviadas em tempo real. Como visto na seção 6.1 uma das condições essenciais para um projeto de cidades inteligentes é a mobilidade. A utilização de dispositivos móveis permite aos usuários das cidades a receber informações a qualquer momento e em qualquer lugar. Com isso, os clientes alvos da aplicação desenvolvida foram dispositivos móveis. Quando falamos em dispositivos móveis, o consumo de bateria é uma das maiores preocupações. A comunicação em rede, com o envio e recebimento de dados, pode ter impacto direto na performance da bateria. Uma medida para poupar o consumo é limitar a comunicação em rede somente para o necessário. Portanto, aplicações que dependem da rede, como por exemplo, para notificações de eventos e transferência de dados em tempo real, precisam se preocupar na forma em que será implementado esse serviço. O uso da técnica de polling gera um volume desnecessário de tráfego na rede. Para se obter as atualizações mais recentes no servidor, o intervalo entre as requisições deve ser pequeno. Se o intervalo entre as requisições for definido em 1 minuto, em 1 hora, aproximadamente 3% da bateria será consumida [29]. Logo, para esses tipos de aplicações, é preferível que em vez de diversas requisições em busca por atualizações, somente quando alguma ocorrer, o servidor notifique o cliente em tempo real, outra condição necessária em projeto de cidades inteligentes. Uma das alternativas, então, é utilizar o modelo de comunicação push server, onde a aplicação desenvolvida o utiliza através da tecnologia

52 Capítulo 6. Tecnologias Push e Cidades Inteligentes 51 WebSocket Implementação Figura 12 Visão geral da aplicação. A arquitetura da aplicação é ilustrada pela figura 12. Clientes abrem uma conexão WebSocket com o servidor estabelecendo um canal bidirecional que será utilizado para o envio das notificações em tempo real. Dados coletados por sensores são armazenados em um banco de dados e enviados por um Poller para um RESTful Webservice localizado no servidor. O Poller foi desenvolvido para buscar e enviar os dados dos sensores armazenados no banco de dados para o servidor em intervalos predefinidos, simulando o monitoramento em tempo real de sensores que também realizam o monitoramento em intervalos. No servidor, os dados são repassados para um gerenciador de eventos que tem como função realizar a análise e disseminação dos dados. Caso seja detectado algum evento importante, o gerenciador notifica os clientes utilizando a conexão WebSocket estabelecida. Os filtros utilizados pelo gerenciador de eventos para determinar o envio de uma notificação são criados pelo próprio usuário. Ele cria estes filtros por meio de um cliente instalado no dispositivo móvel que acessa um serviço Web RESTful no servidor para cadastro dos filtros. Nos testes realizados para validação deste trabalho, as notificações geradas pela aplicação são sobre dados de sensores que monitoram informações sobre o trânsito nas ruas e avenidas do estado da Califórnia, Estados Unidos. O conjunto de dados utilizados foi cedido pelo Caltrans 1 (California Departament of Transportation) e são dados de monitoramento coletados no período de 11/10/2013 à 13/10/2013. O conjunto de dados da Caltrans é coletado em sensores reais denominados VDS (Vehicular Detection Station) espalhados pelas ruas e avenidas do estado, como mostra a figura <