IMPLEMENTAO E ANLISE DA UTILIZAO DE WEBSOCKETS EM SISTEMAS COMPUTACIONAIS

Thiago Daniel R. Varela Orientador: Stanley Loh Universidade Luterana do Brasil (ULBRA) Cincia da Computao Canoas RS Brasil
thiagodrv AT gmail.com, loh AT ulbra.br

RESUMO
As transformaes sofridas pela web, que a tornaram uma plataforma para aplicaes distribudas e altamente dinmicas, obrigaram o surgimento de alternativas ao padro de simples requisio/resposta do HTTP. A mais amplamente utilizada nos dias de hoje um conjunto de tecnologias que, quando empregadas simultaneamente e com este propsito, recebem o nome de AJAX. Entretanto, mesmo esta soluo representa apenas um passo na evoluo da web, pois apresenta limitaes j que, em ltima anlise, ainda se baseia no modelo de requisio/resposta. Neste contexto, surge o Websocket, um novo padro que possibilita comunicaes de duas vias reais e de maneira eficiente, atravs de um protocolo de encapsulamento simples, de modo a proporcionar a interatividade e dinamismo que a web atual exige alm da eficincia na utilizao dos recursos computacionais, que uma necessidade diante do nmero cada vez mais crescente de usurios. Este artigo prope a implementao de bibliotecas implementado o protocolo, de maneira que possam ser utilizadas para a construo de novas aplicaes utilizando a tecnologia de Websockets. Palavras-chave: websocket, web, http, ajax, interatividade, web dinmica

1 INTRODUO
A web sofreu grandes mudanas em seu padro de utilizao desde que foi criada, especialmente na ltima dcada. Inicialmente utilizada para transferir simples pginas estticas compostas principalmente por texto, hoje a web serve de plataforma para sistemas com alta interatividade e cada vez mais dinmicos. O modelo de comunicao baseado em Requisio/Resposta, sobre o qual a web foi construda, passou a mostrar-se inadequado para este novo paradigma. Em resposta a estas necessidades, surgiram diversas tcnicas com o objetivo de simular uma comunicao bidirecional atravs deste modelo de requisio/resposta, utilizando para isso alguma variao de tcnicas de polling. Entretanto, por possurem natureza no disruptiva, estas solues no puderam resolver a causa do problema, apenas trabalharam para contorn-lo criando mecanismos que operassem sobre a tecnologia j existente e em utilizao, o que faz com que estas solues percam em eficincia e limitem a evoluo para sistemas mais interativos e mais dinmicos. neste cenrio que surge a proposta do Websocket, um mecanismo para comunicao bidirecional que tenta tornar simples e eficiente esta interao, resolvendo o problema em sua causa mas ao mesmo tempo buscando funcionar juntamente com a estrutura atual.

2 MOTIVAO
Apesar de ser um padro relativamente novo e ainda em especificao, o Websocket j possui um nmero razovel de implementaes funcionais, por exemplo nos navegadores Chrome e diversos outros

baseados em WebKit. Entretanto, uma segunda utilidade para protocolos Web so os chamados Webservices, que nada mais do que a utilizao de protocolos e padres Web para a comunicao entre dois ou mais sistemas ou programas, ao invs de ser uma interao sistema-usurio (como na Web). Este ramo de aplicao ainda carece de implementaes prticas do protocolo Websocket, que poderia trazer grandes benefcios em diversas aplicaes com o seu modelo de comunicao bidirecional de conexo nica.

3 OBJETIVOS
Os objetivos que desejam-se atingir com este trabalho so, primariamente, a criao de uma implementao genrica e funcional do protocolo Websocket, tanto do cliente quanto do servidor, na forma de bibliotecas independentes, j que hoje as nicas implementaes completas do protocolo so embutidas dentro de grandes sistemas j prontos (como navegadores de internet), o que torna a sua utilizao muito difcil para novos sistemas que queiram tirar proveito desta nova tecnologia, permitindo, desta forma, a criao, de maneira relativamente simples, de programas e sistemas utilizando este novo protocolo. Esta implementao ser licenciada sob uma licena livre (reconhecida como tal pela OSI Open Source Initiative) e permissiva, efetivamente tornando estas bibliotecas um software livre e de cdigo aberto, de maneira a poder ser utilizado pelo maior nmero de sistemas possvel (comerciais ou livres), e possibilitando tambm contribuies que podero melhorar mais rapidamente a qualidade da implementao. O objetivo ltimo deste trabalho a disseminao desta nova tecnologia para que o maior nmero possvel de pessoas possa se beneficiar dela.

4 REFERENCIAL TERICO
Nas subsees a seguir, descrevem-se as principais tecnologias relacionadas ou abordadas neste artigo.

4.1 HTTP
O HTTP o protocolo que serve de base para toda a web. um protocolo de camada de aplicao, em uso na World-Wide Web global information initiative desde 1990. um protocolo sem estado (stateless), baseado no modelo de Requisio/Resposta. Um cliente estabelece uma conexo com o servidor e envia uma requisio, que consiste de um mtodo, um URI, e a verso do protocolo, seguidos possivelmente por modificadores de requisio e informaes sobre o cliente. O servidor responde com uma linha de status, incluindo a verso do protocolo e um cdigo de erro ou sucesso, seguidos por uma mensagem contendo informaes sobre o servidor e o corpo de dados do objeto requisitado. (Berners-Lee et al, 1996). A figura 1 mostra um exemplo de uma requisio HTTP em sua forma mnima e sua respectiva resposta.

4.2 Sistemas Web Dinmicos

As transformaes no padro de utilizao da web na ltima dcada, impulsionadas principalmente pelo surgimento de diversas plataformas cada vez mais dinmicas e interativas, como Gmail, Facebook e Orkut (surgidos em 2004), MySpace (criado em 2003) e Twitter (surgido em 2006), apontam para a transformao da web, de uma simples rede de transferncia de documentos estticos, em uma verdadeira plataforma para sistemas de larga escala, dinmicos, sociais e interativos. Diante deste novo paradigma, as antigas solues comearam a mostrar-se inadequadas, pois o modelo de requisio/resposta passou a no mais se enquadrar ao perfil destas novas plataformas, que requerem um nvel cada vez maior de interatividade, alm do suporte a um nmero rapidamente crescente de usurios.

Requisio: GET /exemplo HTTP/1.0 Resposta: HTTP/1.0 200 <contedo do objeto /exemplo> Figura 1 Exemplo de requisio e resposta HTTP

4.3 A Soluo Atual para Comunicaes Dinmicas via Web

Com o surgimento desta demanda por maior interatividade, surgiram solues para tornar a interao com a web mais dinmica. A tecnologia predominantemente empregada nestes casos algo que se chama de AJAX, que na verdade no constutui por si uma tecnologia, mas sim vrias tcnicas diferentes sendo empregadas em conjunto. Consiste basicamente em criar um motor de renderizao da tela (na maioria dos casos em Javascript), que quem faz a interao com o usurio, interagindo com o servidor (na maioria dos casos utilizando XML) assincronamente no plano de fundo. Desta maneira, o usurio no tem mais a necessidade de ficar aguardando a resposta do servidor aps cada requisio, pois o motor de renderizao pode previamente solicitar os recursos necessrios, alm de possibilitar a atualizao de apenas partes da tela, permitindo que o usurio continue interagindo com parte da aplicao enquanto outra parte est sendo processada pelo servidor. (Jesse J. Garrett, 2005) Entretando, este tipo de tecnologia ainda no permite uma comunicao de duas vias real (onde qualquer um dos lados pode enviar dados quando desejar), pois as comunicaes com o servidor ainda acontecem sobre HTTP, e portanto, o servidor no consegue iniciar um envio de dados, apenas pode responder a requisies efetuadas pelo cliente. (Coach K. Wei, 2005) De modo a simular uma comunicao de duas vias, as aplicaes cliente frequentemente utilizam-se de uma tcnica denominada polling, que consiste no envio peridico de requisies para o servidor para permitir que ele envie novas informaes, caso existam. Desta maneira, pode-se simular uma conexo de duas vias j que, do ponto de vista do usurio, novas informaes aparecem sem que ele tenha que explicitamente fazer uma nova requisio por elas. Esta soluo, entretanto, no eficiente em termos de recursos computacionais, uma vez que sero realizadas inmeras requisies inteis, quando o servidor ainda no tiver novas informaes para responder. Tambm no representa uma via de comunicao de tempo real, j que quando houver nova informao no servidor, ela s ir mostrar-se para o usurio depois de decorrido o intervalo at a prxima requisio peridica da aplicao cliente. Outra tcnica tambm utilizada no propsito de tornar a web mais dinmica, um conceito que recebe o nome de Comet, que engloba um conjunto de solues que so tecnicamente diferentes mas conceitualmente semelhantes. Seu princpio de funcionamento baseia-se em efetuar uma requisio HTTP para o servidor, e, ao receber a resposta, nenhum dos lados encerra a conexo, mantendo-a aberta para que o servidor possa enviar os eventos subsequentes dentro da mesma conexo, sem precisar aguardar que o cliente faa uma nova requisio. Esta tcnica principalmente utilizada em conjunto com as tecnologias que formam o Ajax, apenas substituindo o mecanismo de polling por este mecanismo de conexo longa.

Os mecanismos para a utilizao de Comet podem englobar diferentes tecnologias, as principais so a utilizao de um Iframe oculto na pgina, implicitamente declarado com tamanho infinito, que ficaria em estado carregando indefinidadamente, por onde o servidor enviaria seus dados, ou utilizando uma tcnica denominada long-polling, que consiste em uma variao do conceito de polling, porm cada requisio efetuada pelo cliente mantida aberta at que o servidor tenha alguma informao para enviar, aps isto, a conexo encerrada e o cliente deve estabelecer uma nova conexo. A vantagem neste caso que no h requisies desperdiadas enquanto o servidor no tem novas informaes. Estas solues, apesar de representarem uma evoluo sobre o modelo de polling comum, ainda apresentam problemas. No caso do Iframe oculto, no existe maneira de saber o estado atual do objeto, nem existe um mtodo para realizar tratamento de erros, alm de ser uma distoro em relao ao objetivo da utilizao de Iframes. A tcnica de long-polling ainda requer o estabelecimento de mltiplas conexes e a troca de cabealhos HTTP, portanto perdendo no que tange a eficincia computacional. (Anthony T. Holdener III, 2008)

4.4 Websocket
O Websocket um protocolo que prov um canal de comunicao de duas vias entre um agente de usurio e um host remoto, cujo objetivo prover um mecanismo para aplicaes web que necessitam de comunicao bidirecional sem ter que depender da abertura de mltiplas conexes HTTP (p. ex. Usando XMLHttpRequest ou long polling). (Hickson, 2010) Foi desenvolvido com o princpio de que deve existir apenas um enquadramento ( framing) mnimo, de modo a economizar recursos e simplificar as implementaes. esperado que um subprotocolo seja utilizado sobre o Websocket pela camada de aplicao, da mesma forma que o HTTP utilizado sobre o TCP. Tecnicamente, o Websocket apenas uma camada sobre o TCP que adiciona um modelo de segurana web baseado em origem, um esquema de nomes e endereamento (para suportar mltiplos servios em uma mesma porta e mltiplos nomes de host em um mesmo endereo IP), encapsula um simples mecanismo de enquadramento e reimplementa o handshake de fechamento. Nada alm disto. A inteno torn-lo o mais prximo possvel do TCP puro, mas levando em conta os requerimentos da web. Tambm desenvolvido de forma tal que, pelo fato de o handshake possuir um cabealho HTTP vlido, possa dividir uma mesma mesma porta com servidores HTTP. (Hickson, 2010) O protocolo consiste de um handshake inicial seguido da tranferncia dos dados propriamente dita. Caso o handshake tenha sucesso, inciada a transferncia de dados. Sendo este um canal de comuncao de duas vias, cada lado da conexo pode enviar dados a qualquer momento, diferentemente do HTTP, onde o servidor no consegue enviar dados para o cliente no momento em que desejar, precisando aguardar que o cliente faa uma requisio para que s ento ele consiga transmitir qualquer informao para o cliente. Os dados so transmitidos na forma de texto codificado em UTF-8. Cada quadro (frame) de dados inicia com um byte 0x00 e termina com um byte 0xFF, contendo o texto UTF-8 no meio. O Websocket prov este enquadramento para que as implementaes do protocolo possam expor tais conexes utilizando um modelo baseado em eventos, ao invs de requerer a utilizao de buffering e agrupamento manual de mensagens. (Hickson, 2010) Para encerrar uma conexo, um quadro consistido apenas por um byte 0xFF seguindo por um byte 0x00 enviado por um par (peer) para pedir que o outro encerre a conexo. O outro par ento envia um quadro idntico, que indicando que a conexo pode ser encerrada. (Hickson, 2010)

Campos adicionais so usados para selecionar opes do protocolo Websocket. Na verso atual, os campos adicionais suportados so Cookie, que pode ser utilizado para enviar cookies para o servidor (p. ex. como mecanismo de autenticao) e Sec-WebSocket-Protocol, que contm uma string arbitrria que descreve o subprotocolo (o protocolo da aplicao utilizado sobre o Websocket) que o cliente pretende utilizar. O servidor ecoa este campo na sua resposta para indicar que ele suporta este subprotocolo especificado. Os outros campos do handshake so todos relativos segurana. O campo Host serve como proteo contra adulterao de DNS e para permitir que mltiplos domnios sejam atendidos em um mesmo endereo. O campo Origin usado para proteger o servidor contra acesso cruzado no autorizado. O servidor especifica de qual origem ele est disposto a receber conexes incluindo um campo Sec-WebSocket-Origin informando esta origem. Se mltiplas origens forem aceitas, o servidor apenas ecoa o valor do campo Origin presente na requisio do cliente. A figura 2 ilustra o funcionamento do handshake enviado pelo cliente:

GET /demo HTTP/1.1 Upgrade: WebSocket Connection: Upgrade Origin: http://exemplo.com Host: exemplo.com Sec-WebSocket-Key2: 12998 5 Y3 1 Sec-WebSocket-Key1: 4 @1 Sec-WebSocket-Protocol: teste ^n:ds[4U Figura 2: handshake Websocket enviado pelo cliente para estabelecer uma conexo com um servidor .P00 46546xW%0l 1 5

Por fim, o servidor deve provar ao cliente que ele recebeu o seu handshake (de maneira a evitar que um servidor aceite conexes que no so uma conexo Websocket). Para faz-lo, o servidor deve pegar trs peas de informao e combin-las para formar uma resposta. As primeiras duas informaes vm dos campos Sec-WebSocket-Key1 e Sec-WebSocket-Key2 do handshake do cliente. Para cada um destes campos, o servidor deve retirar apenas os nmeros, e ento dividir este nmero formado pelo nmero de caracteres de espao contidos no campo. Estes dois nmeros resultantes so ento utilizados no handshake do servidor. A terceira informao so os ltimos 8 bytes do handshake, aps todos os campos. Ela concatenada com os dois nmeros resultantes obtidos anteriormente, formando uma string de 128 bits cuja soma MD5 usada pelo servidor para provar que ele leu o handshake. A figura 3 ilustra o handshake do servidor:

HTTP/1.1 101 WebSocket Protocol Handshake Upgrade: WebSocket Connection: Upgrade Sec-WebSocket-Origin: http://exemplo.com Sec-WebSocket-Location: ws://exemplo.com/demo Sec-WebSocket-Protocol: teste 8jKS'y:G*Co,WxaFigura 3: Exemplo do handshake Websocket por parte do servidor.

A primeira linha uma linha de status padro HTTP, contendo sempre o status 101 (os outros campos desta linha no so importantes). As duas linhas seguintes so apenas para compatibilidade com o HTTP. A quarta e quinta linhas fazem parte do modelo de segurana descrito acima, a primeira ecoando o host e a segunda especificando exatamente o host, porta e nome do recurso Websocket. A sexta linha o campo de opo Websocket, que indica qual o subprotocolo que o servidor ir utilizar (o cliente deve verificar se este valor o mesmo enviado por ele durante o seu handshake) Aps os campos, enviada a supracitada soma MD5. Se este valor no corresponder o que o cliente espera, ele ir efetuar a desconexo. Uma vez estabelecida a conexo, no mais necessrio utilizar estes cabealhos a cada pacote enviado, apenas o esquema de enquadramento descrito anteriormente, constutudo simplesmente por um byte 0x00 no incio e um byte 0xFF ao final do pacote. Percebe-se, portanto, que o Websocket visa solucionar o problema da comuncao bidirecional em tempo real ao prover um mtodo de conexo permanente que permite o trfego em duas vias ( full duplex), iniciado a partir de uma conexo HTTP, e portanto capaz de funcionar normalmente utilizando a estrutura j presente na web, como roteadores, balanceadores de carga e proxies. E, por dispensar a utilizao dos cabealhos HTTP uma vez que estabelecida a conexo, e no lugar deles utilizar um simples enquadramento de dois bytes, mostra-se tambm mais eficiente no que tange a utilizao dos recursos computacionais.

4.4.1 Aplicaes para Websockets

As aplicaes que mais poderiam se beneficiar da implementao de Websockets num primeiro momento, so as que envolvem comunicaes. O Gmail, um dos protagonistas no ramo de clientes de email web, que hoje utiliza tcnicas de polling para determinar quando o usurio recebeu novas mensagens, teria grandes vantagens utilizando um sistema com Websockets, pois poderia oferecer maior interatividade com mais eficincia de recursos. Poderia at mesmo aproveitar a mesma conexo para o cliente de Gtalk integrado, que atualmente utiliza tcnicas de Comet (Alex Russell, 2006), atravs de uma conexo diferente da que o cliente de email utiliza (j que cada um deles, na verdade, utiliza mltiplas conexes), economizando assim ainda mais recursos ao mesmo tempo que aumenta o dinamismo proporcionado ao usurio, alm de simplificar a implementao. O Websocket tambm permitir a criao de uma nova gerao de servios web interativos, como o acompanhamento em tempo real de mercados, valores de cmbio e bolsas de valores. Este tipo de

aplicaes precisam hoje utilizar complexos sistemas prprios para atender suas necessidades de curta latncia, e por isso seriam altamente beneficiados ao poderem utilizar um protocolo web, padronizado e com implementaes livres e facilmente disponveis, sem abrir mo dos seus requisitos. Sistemas de monitoramento tambm seriam beneficiados ao poder exibir alertas na tela em tempo real sem sobrecarca excessiva nos servidores. Alm disso, o Websocket tambm poder proporcionar vantagens a inmeros sistemas que utilizam Webservices (que consiste na interao entre sistemas computacionais utilizando protocolos web), que passaro a poder utilizar uma nica conexo permanente para a comunicao, alm de passar a permitir que, uma vez estabelecida a conexo, qualquer um dos lados envie informaes a qualquer momento, alm de eliminar a necessidade de trafegar os cabealhos HTTP a cada requisio e resposta efetuadas.

5 PROPOSTA DE SOLUO
A proposta deste trabalho a implementao de um mdulo (biblioteca), implementando as funes de servidor Websocket e as de cliente, cada um em sua respectiva classe, que podem ser utilizadas individualmente dependendo da finalidade do sistema em questo (cliente ou servidor). O objetivo criar um mdulo simples, que implemente o protocolo e proveja uma API (Aplication Programming Interface - Interface de Programao de Aplicao) simples e genrica para ser utilizada com facilidade por outros sistemas, alm de ser licenciado sob uma licensa livre, o que permite que qualquer tipo de sistema se beneficie das vantagens desta nova tecnologia sem necessidade de desenvolvimento prprio ou de pesados investimentos financeiros em solues proprietrias.

5.1 Licena
Todo o cdigo produzido neste trabalho est licenciado sob uma licena livre e open-source, reconhecida pela Open Source Initiative e amplamente utilizada em projetos de software livre pelo mundo. A licena escolhida foi a MIT License, por sua simplicidade (possui apenas uma clusula) e sua permissividade (no limita a utilizao sob nenhum aspecto). Com esta licena, so permitidos quaisquer tipos de utilizao do cdigo, modificao, redistribuio e incorporao em outros projetos, livres ou proprietrios, com a nica exigncia de que, no trecho de cdigo utilizado, seja mantida a nota de copyright original e o trecho com clausula nica da licena. A referncia para o texto da licena pode ser encontrada na seo correspondente do site da Open Source Initiative, em http://www.opensource.org/licenses/MIT.

5.2 Modelagem e Metodologia

Os mdulos criados so implementados na linguagem Python, constituindo o que se chama de mdulo python, cujo funcionamento semelhante ao de uma biblioteca comum, entretanto para programas escritos em Python. 5.2.1 API O mdulo implementa uma interface (API) baseada, dentro do possvel - levando em considerao as diferenas em cada linguagem na API que especificada para o Javascript pelo W3C no HTML5 (em http://dev.w3.org/html5/websockets), de modo a manter uma certa compatibilidade com outras implementaes e simplificar o desenvolvimento. Portanto, segundo a especificao, a classe do cliente implementa o objeto WebSocket, que contm:

Construtor: o construtor (funo executada quando o objeto criado) do objeto WebSocket recebe os parmetros url e protocol, que so strings que representam a URL (servidor, caminho e, opcionalmente, porta) e o subprotocolo utilizado, respectivamente. Recebe tambm, opcionalmente, como parmetro, funes que sero executadas em circunstncias especficas dentro do funcionamento do programa. So elas, nesta ordem: onopen: executada quando a conexo for estabelecida. Recebe como parmetro o objeto WebSocket criado (para que, caso desejado, possa chamar os mtodos de envio de dados ou encerramento da conexo) onmessage: executada quando uma mensagem for recebida. Recebe como parmetro o objeto WebSocket e uma string UTF-8 contendo os dados recebidos. onerror: executada quando ocorrer algum erro. Recebe como parmetro o objeto WebSocket e a conexo socket estabelecida com o servidor (para que medidas possam ser tomadas caso os mtodos de acesso via Websocket tenham falhado) onclose: executada quando a conexo for encerrada. No recebe parmetros.

Atributo readyState: informa o estado da conexo. Se contiver o valor 0, indica que a conexo ainda est por ser estabelecida. O valor 1 indica que a conexo est estabelecida e a comunicao possvel. O valor 2 indica que a conexo est sendo ecerrada e o valor 3 indica que a conexo j foi encerrada ou no pde ser estabelecida. Mtodo send: utilizado para enviar os dados desejados para o servidor. Recebe por parmetro os dados na forma de string codificada em UTF-8. Mtodo close: encerra a conexo Websocket.

A interface da classe do servidor semelhante do mdulo cliente, com diferenas apenas no construtor: Construtor: o construtor (funo executada quando o objeto criado) do servidor WebSocket recebe os parmetros connection e port, que so, respectivamente, uma conexo via socket j estabelecida com um cliente (os mtodos para estabelecer esta conexo com o cliente atravs de sockets so comuns e j existentes na linguagem) e a porta na qual o servidor est trabalhando (necessrio no handshake). Recebe tambm, opcionalmente, como parmetro, funes que sero executadas em circunstncias especficas dentro do funcionamento do programa. So elas: onopen: executada quando a conexo for estabelecida. Recebe como parmetro o objeto WebSocket criado (para que, caso desejado, possa chamar os mtodos de envio de dados ou encerramento da conexo) onmessage: executada quando uma mensagem for recebida. Recebe como parmetro o objeto WebSocket e uma string UTF-8 contendo os dados recebidos. onerror: executada quando ocorrer algum erro. Recebe como parmetro o objeto WebSocket e a conexo socket estabelecida com o cliente (para que medidas possam ser tomadas caso os mtodos de acesso via Websocket tenham falhado) onclose: executada quando a conexo for encerrada. No recebe parmetros.

Atributo readyState: informa o estado da conexo. Se contiver o valor 0, indica que a conexo ainda est por ser estabelecida. O valor 1 indica que a conexo est estabelecida e a

comunicao possvel. O valor 2 indica que a conexo est sendo ecerrada e o valor 3 indica que a conexo j foi encerrada ou no pde ser estabelecida. Mtodo send: utilizado para enviar dados para o cliente. Recebe por parmetro os dados na forma de string codificada em UTF-8. Mtodo close: encerra a conexo Websocket.

5.2.2 Demonstrao de implementao de um cliente Websocket A biblioteca de cliente Websocket produzida ao longo deste trabalho pode ser facilmente utilizada por qualquer programa desenvolvido atravs da linguagem Python. Para isto, deve-se primeiramente importar a classe WebsocketClient do mdulo libwebsocket, como mostra a figura 4:
from libwebsocket import WebsocketClient

Figura 4 Importando a classe cliente do mdulo libwebsocket

Com isto, na seo do programa onde se desejar iniciar a conexo Websocket com o servidor, basta instanciar um novo objeto da classe WebsocketClient, observando que sejam passados os devidor parmetros para o construtor, conforma a seo 6.2 API especifica e a figura 5 exemplifica. O prprio construtor da classe quem estabelece a conexo com o servidor, o que significa que basta instanciar o objeto e a conexo dever ser estabelecida.

ws = WebsocketClient('ws://127.0.0.1:1234/teste', 'teste', None, onmessage, onerror, None)

Figura 5 Instanciando o objeto WebsocketClient e efetuando a conexo

Observa-se que no exemplo da figura 5 acima, no foi especificado um mtodo onopen e nem um mtodo onclose. Como foi dito na especificao da API, qualquer um deste mtodos opcional, e no caso de no se desejar implement-lo, basta passar um None em seu lugar (em Python, None o mesmo que o NULL presente em outras em outras linguagens). Feito isto, pode-se opcionalmente verificar o estado do atributo readyState no objeto instanciado. Se o valor for 1, a conexo foi estabelecida com sucesso. Pode-se ento envar dados para o servidor, bastando invocar o mtodo send do objeto criado, passando como parmetro umas string UTF-8 representando os dados que se quer enviar. Se houver uma resposta do servidor e um mtodo onmessage tiver sido especificado, este mtodo ser invocado e receber como parmetro, alm do prprio objeto WebsocketClient, tmbm uma string UTF-8 representando a informao enviada pelo servidor. Uma implementao completa de um cliente Websocket exibida na figura 7. Este simples programa apenas estabelece uma conexo Websocket com um servidor rodando na mesma mquina, na porta TCP 1234. Envia ento uma pequena mensagem para o servidor e aguarda uma resposta. Quando a resposta recebida, ela exibida na tela e a conexo encerrada.

5.2.3 Demonstrao de implementao de um servidor Websocket A biblioteca de servidor Websocket produzida ao longo deste trabalho, assim como a de cliente, pode ser facilmente utilizada por qualquer programa desenvolvido atravs da linguagem Python. Para fins didticos, o servidor que ser demonstrado neste captulo no utilizar threads, o que significa que ele no conseguir atender a mais de um cliente simultneo. Contudo, as instrues para que se crie um servidor deste tipo no so especficas para a utilizao de Websockets e podem ser facilmente encontradas nas documentaes apropriadas. Primeiramente, deve-se importar a classe WebsocketServer do mdulo libwebsocket, como mostra a figura 6:
from libwebsocket import WebsocketServer

Figura 6 Importando a classe servidor do mdulo libwebsocket

import sys from libwebsocket import WebsocketClient

def onopen(ws): print "conexao estabelecida"

def onmessage(ws, data): print "mensagem recebida:" print data ws.close()

def onerror(ws, conn): print "erro. encerrando conexao" ws.readyState = 3 conn.close() sys.exit(1)

def onclose (): print "conexao encerrada"

if __name__=='__main__': ws = WebsocketClient('ws://127.0.0.1:1234/teste', 'teste', onopen, onmessage, onerror, onclose) ws.send('teste msg') while ws.readyState == 1: pass

Figura 7 Exemplo de programa cliente Websocket

10

Agora, deve-se abrir um socket TCP, e coloc-lo em bind na interface e porta desejadas. Em seguida, deixa-se o socket em listen, indicando que ele est pronto para receber conexes. Depois disto, invoca-se o mtodo accept, que ficar esperando at que um cliente se conecte a este servidor e retornar um novo socket atravs do qual se pode mandar e receber dados com o cliente, alm do endereo deste cliente. Este procedimento exibido na figura 8:

s = socket.socket(socket.AF_INET, socket.SOCK_STREAM) s.bind(('', 1234)) s.listen(1) conn, cli_addr = s.accept()

Figura 8 Preparando a conexo com o cliente

Aps isto, quando o mtodo accept retornar, tem-se um cliente conectado ao socket do servidor. O que significa que est na hora de invocar o servidor Websocket. Para isto, basta instanciar um objeto da classe WebsocketServer, passando os parmetros conforme especifica a seo 5.2.1 API e exemplificado pela figura 9:

ws = WebsocketServer(conn, 1234, onopen, onmessage, onerror, onclose)

Figura 9 Criando o servidor Websocket

Aps isto, pode-se opcionalmente verificar se o atributo readyState possui o valor 1, o que significa que a conexo Websocket foi estabelecida com sucesso. Neste ponto j tem-se uma conexo Websocket estabelecida com o cliente. J pode-se, ento, enviar dados a qualquer momento invocando o mtodo send. Toda informao que for recebida do cliente ser passada para o mtodo onmessage, caso ele tenha sido passado adequadamente como parmetro para o construtor do servidor Websocket. Uma implementao funcional de demonstrao do servidor Websocket exibida na figura 10. Este programa extremamente simples apenas abre um servidor na porta 1234, e quando a conexo Websocket estabelecida, aguarda por uma mensagem do cliente, que, ao ser recebida, exibida na tela e uma resposta enviada de volta ao cliente. Aps isto, o servidor aguarda o encerramento da conexo por parte do cliente. Novamente, importante ressaltar que a implementao dos mtodos onopen, onmessage, onerror e onclose completamente opcional. No caso de algum destes mtodos no ser implementado, basta passar como parmetro um None para o construtor do objeto Websocket. Vale notar, entretanto, que se um mtodo onmessage no for especificado, nenhum dado ser recebido do cliente.

11

import socket from libwebsocket import WebsocketServer

def onopen(ws): print "conexao estabelecida" def onmessage(ws, data): print "mensagem recebida:" print data ws.send('resposta teste') def onerror(ws, conn): print "erro. encerrando conexao" ws.readyState = 3 conn.close() def onclose(): print "conexao encerrada" if __name__=='__main__': port = 1234 s = socket.socket(socket.AF_INET, socket.SOCK_STREAM) s.bind(('', port)) s.listen(1) conn, cli_addr = s.accept() server = WebsocketServer(conn, port, onopen, onmessage, onerror, onclose)

Figura 10 Exemplo de programa servidor Websocket

6 TESTES E COMPARATIVOS
J que o principal concorrente do Websocket, tecnologicamente falando, o prprio HTTP, os testes foram realizados no intuito de promover uma comparao entre estes dois. H duas modalidades bsicas de testes. O primeiro uma troca de mensagens (aqui chamadas desta forma, mas que, na prtica, podem ser qualquer coisa, at mesmo o contedo de arquivos) de maneira sncrona, ou seja, o cliente envia uma requisio e aguarda a resposta do servidor. Este o modo de operao clssico do HTTP e serve para comparar o Websocket em um cenrio de utilizao simples e comum (que no exatamente o ambiente para o qual ele foi projetado e no tira proveito das facilidades que este novo protocolo pode oferecer). O segundo cenrio uma troca de mensagens assncronas entre cliente e servidor, ou seja, o cliente efetua uma requisio, mas o servidor no possui aquele recurso disponvel naquele momento (na prtica, poderia ser uma operao ainda no concluda, ou, em um caso mais especfico, uma verificao por novos e-mails que podem chegar a qualquer momento para o usurio no servidor). Este cenrio mais prximo do ambiente para o qual o Websocket foi criado, e deve tirar vantagens do novo paradigma de comunicao por ele proposto. O HTTP, neste caso, precisa ficar fazendo constantes requisies para o servidor para verificar se o recurso j est disponvel (o teste foi executado com diferentes intervalos entre estas requisies), enquanto que o Websocket faz a primeira requisio e apenas aguarda o retorno do servidor quando o recurso solicitado estiver disponvel.

12

O ambiente onde estes testes foram executados consiste de duas mquinas virtuais utilizando o virtualizador Virtualbox, funcionando em uma mesma mquina fsica. Cada uma destas mquinas virtuais roda o sistema operacional Fedora Linux 15. O sistema foi instalado apenas com os componentes mais bsicos necessrios e no rodavam nenhum tipo de servio adicional durante os testes. Para a medio de trfego, utilizou-se o utilitrio Etherape, que livre e amplamente disponvel. Para a medio de outras mtricas (tempo, requisies), foram construdas medies dentro dos prprios scripts de teste.

6.1 Comparativo com troca de mensagens sncronas

Neste teste comparado o desempenho de cada um dos protocolos no mtodo de utilizao clssico do HTTP, uma requisio de recurso enviada para o servidor e imediatamente uma resposta retornada para o cliente. Este procedimento executado dez vezes, em sequncia imediata. Deve-se notar, antes de tudo, que este no o cenrio para o qual o Websocket foi desenvolvido. Ele foi desenvolvido para operar assincronamente e possibilitar que o servidor possa enviar dados a qualquer momento sem depender de uma requisio imediata do cliente. Ainda assim, os testes foram realizados para analisar o comportamento do Websocket em um ambiente web clssico. Neste teste, foram medidos o nmero de pacotes TCP trafegados, o nmero de bytes trafegados, e o tempo de execuo do cliente. Os resultados esto exibidos nos grficos representados abaixo pelas figuras 11, 12 e 13.

Figura 11 Nmero total de pacotes trafegados (ambos o sentidos)

13

Figura 12 Quantidade total de bytes trafegados (nos dois sentidos)

Aqui podemos comear a perceber uma vantagem do Websocket. Apesar do nmero de requisies e respostas ter sido o mesmo nos dois protocolos (devido natureza do teste, foram dez requisies e dez respostas), o trfego de rede foi consideravelmente melhor quando se utilizou Websockets. Isto pode ser explicado pelo fato de o Websocket no precisar trafegar os cabealhos em todas as requisies e respostas: eles so trocados apenas no estabelecimento da conexo, e, aps isto, as informaes podem ser trocadas livremente entre os dois lados.

Figura 13 Tempo de execuo do cliente

Na figura 13, v-se a desvantagem do Websocket com relao ao HTTP neste cenrio de execuo. Como viu-se anteriormente, o handshake mnimo do HTTP extremamente simples, se comparado ao relativamente complexo do Websocket. Isto porque no Websocket a troca de cabealhos

14

no incio da conexo tem diversas medidas de segurana, para evitar que a conexo seja estabelecida com um host cuja implementao do protocolo seja incompatvel, ou at mesmo que a conexo sofra um ataque de interceptao. Isto faz com que a abertura da conexo no Websocket seja mais demorada, e por isto o tempo total de execuo do cliente tambm acaba sendo maior. Quando da considerao acerca da utilizao do Websocket em um cenrio como o descrito neste teste, deve-se avaliar o tempo mdio previsto para a durao de cada conexo: se forem conexes relativamente longas e duradouras, o Websocket pode ser considerado uma alternativa vlida, pois a pequena diferena de tempo durante o estabelecimento da conexo pode ser facilmente dissolvida durante toda a durao desta, e a o menor trfego de rede apresentado pelo Websocket pode representar uma vantagem definitiva. No entanto, se a previso forem conexes pequenas e muito curtas, provavelmente o Websocket no seja a melhor escolha para este cenrio, pois o maior tempo durante o estabelecimento da conexo pode fazer uma grande diferena se a durao destas conexes for muito curta.

6.2 Comparativo com troca de mensagens assncronas

Neste teste, simulado o funcionamento de um servio de notcias: no servidor, notcias novas chegam em intervalos aleatrios, medida que fatos acontecem e as manchetes vo sendo publicadas pela operadora do servio. Do outro lado, existe um cliente interessado em acompanhar estas notcias. Ele deve se conectar ao servidor e buscar qualquer notcia nova que este possua. Este um ambiente favorvel ao Websocket pois o seu funcionamento basicamente assncrono. Para a finalidade dos testes, o servio simulado rodou por 20 minutos, e novas notcias eram inseridas no servidor em um intervalo randmico de 110 a 130 segundos. Para cada um dos testes, foram medidos os pacotes TCP trafegados (o nmero apresentado a quantidade trafegada em ambos os sentidos), os bytes trafegados (tambm a quantidade total), o nmero de requisies enviadas pelo cliente (que influencia diretamente nos dois grficos anteriores) e o tempo da atualizao, ou seja, o delay do cliente, que significa quanto tempo decorreu entre o servidor ter uma nova notcia e o cliente receber esta atualizao. Todos os resultados apresentados so uma mdia do total do teste dividido pelo nmero de notcias, para dar uma viso individual do resultado. Como o HTTP necessita utilizar mtodo de polling para este perfil de servio, o teste foi executado com trs configuraes distintas de intervalos entre as requisies, a saber, 5, 10 e 30 segundos. Os resultados esto exibidos nos grficos representados abaixo pelas figuras 14, 15, 16 e 17.

15

Figura 14 Quantidade de pacotes trafegados em mdia por notcia

Figura 15 Quantidade de bytes trafegados em mdia por notcia

16

Figura 16 Quantidade de requisies feitas pelo cliente por notcia em mdia

Observa-se a clara vantagem do Websocket nestes resultados, ainda maior que no teste sncrono realizado anteriormente. Isto porque o Websocket no precisa realizar polling, ele envia apenas uma requisio de nova notcia para o servidor, e quando o servidor receber uma notcia nova, este ir responder para o cliente com a atualizao solicitada.

Figura 17 Tempo mdio para o cliente receber uma nova notcia

Neste ltimo grfico pode-se ver a maior vantagem do Websocket quando se trata de comunicao assncrona. O tempo entre a nova notcia estar disponvel no servidor e o cliente receb-la praticamente nulo, e proporcionalmente to pequeno ao lado dos delays do HTTP que sequer aparece no grfico como uma barra.

17

Observa-se nestes grficos tambm o clssico dilema do mtodo polling: quanto menor o intervalo entre cada requisio, menor o delay, mas maior o trfego de rede (mais requisies so feitas). Quanto maior o intervalo, menor o trfego de rede (menos requisies), mas o tempo para que o cliente perceba a disponibilidade do recurso solicitado aumenta significativamente.

7 CONCLUSES
Atravs deste trabalho, criou-se uma implementao simples, genrica e funcional do protocolo Websocket, tanto de cliente como de servidor. Atravs desta implementao, puderam ser realizados testes que comprovam a viabilidade do Websocket como protocolo web, que mostrou ser uma alternativa vantajosa ao HTTP, principalmente em ambientes assncronos, onde atualmente o HTTP necessita utilizar-se de tcnicas de polling, que o tornam bastante ineficiente nesta funo. O protocolo Websocket neste mesmo ambiente mostrou-se muitas vezes mais econmico em termos de recursos de rede, alm de prover a resposta para o cliente quase que instantneamente. Com HTTP, atravs de polling, a resposta demora vrios segundos para efetivamente chegar at o cliente desde o momento em que o servidor tem o recurso disponvel. Alm de apresentar vantagens nas reas hoje cobertas pelo HTTP, o Websocket permite a criao de uma nova gama de servios via web com funcionalidades que simplesmente no so possveis de se conseguir via HTTP, onde qualquer um dos lados pode enviar dados a qualquer momento, aumentando a interatividade significativamente e diminuindo delays. No modelo de utilizao tradicional de requisio-resposta, o Websocket mostrou ser uma alternativa vivel, vantajosa em alguns casos por ser mais eficiente quanto ao trfego de rede. Contudo, devido ao maior tempo necessrio para o estabelecimento da conexo, dependendo do perfil da aplicao a ser considerada, o Websocket pode se tornar a alternativa menos vantajosa com relao ao HTTP, caso o perfil de funcionamento da aplicao em questo envolva um nmero grande de conexes curtas (por exemplo, uma nova conexo estabelecida e apenas uma requisio trafega por ela, quando ela ento encerrada e a prxima requisio precisa abrir uma nova conexo). Este trabalho atingiu seu objetivo ao fornecer uma implementao funcional do protocolo Websocket, disponvel livremente, que pode ser facilmente utilizada em qualquer sistema desenvolvido em Python. Alm disso, pode servir como base ou referncia para facilitar a implementao de Websockets em outras linguagens. As oportunidades que o Websocket abre para a utilizao de protocolos web so bastante amplas. Pode ser implementado na comunicao entre sistemas das mais diversas aplicaes (no modelo de webservices) pois so conexes que tendem a durar bastante tempo (a no ser que a conectividade entre os nodos seja interrompida, o que relativamente raro) possibilitando uma comunicao mais rpida e eficiente. Em termos de aplicaes que interagem diretamente com o usurio, a gama de possibilidades tambm variada. Pode-se imaginar diversos sistemas que hoje utilizam HTTP cuja interatividade poderia ser melhorada na utilizao de Websockets. Por exemplo, o acompanhamento de uma partida de futebol em um site de esportes, ou as manchetes importantes em um site de notcias, poderiam estar sendo fornecidas em tempo real para o usurio, sem que este precise atualizar a pgina manualmente, e sem ter de utilizar ineficientes mtodos de polling com HTTP. possvel ainda imaginar novos tipos de aplicaes, por exemplo, um site de busca na web onde, aps digitada uma busca, no se tenha uma lista de resultados estticos, mas um fluxo em tempo real medida que novas atualizaes sobre o assunto buscado forem sendo realizadas. Outras oportunidades tambm existem em ramos onde hoje no so utilizados protocolos web, devido necessidade de baixo tempo de resposta, como o acompanhamento de mercados de cmbio e de

18

aes. Os home brokers disponibilizados pelas operadoras de investimentos hoje precisam ser complexas aplicaes desenvolvidas a partir do zero, tanto o cliente como o servidor, pois necessrio implementar um protocolo prprio sobre TCP para que se consiga o baixo tempo de resposta necessrio neste tipo de aplicao. Com a utilizao de Websocket este sistema seria drasticamente simplificado, pois poder ia-se ento utilizar um protocolo web, que j possui implementaes de servidor (servidores web) e cliente (navegadores) prontas, alm de poder disponibilizar isto diretamente em seu site, tornando a utilizao mais simples e fcil. Tudo isto sem abrir mo da eficincia e interatividade. O que no foi avaliado neste trabalho, entretanto, e que deve ser avaliado antes de qualquer tipo de migrao de servio ou construo de um novo utilizando Websockets, em termos de utilizao dos recursos do servidor. Pelos testes que foram executados percebe-se que o trfego de rede bastante reduzido, contudo, outros recursos como memria e processamento devem ser estudados antes de uma utilizao em larga escala.

8 REFERNCIAS
RUSSEL, Alex. Comet: Low Latency Data for the Browser. Disponvel em http://alex.dojotoolkit.org/2006/03/comet-low-latency-data-for-the-browser. 2006. HOLDENER III, Anthony T.. Ajax: The Definitive Guide. Editora O'Reilly. 2008. BERNERS-LEE, Tim; FIELDING, R.; FRYSTYK, H. RFC 1945 - Hypertext Transfer Protocol -HTTP/1.0. Disponvel em http://www.ietf.org/rfc/rfc1945.txt. 1996. WEI, Coach K. AJAX: Asynchronous Java + XML?. Disponvel em http://www.developer.com/design/article.php/10925_3526681_1/AJAX-Asynchronous-Java--XML.htm. 2005. HICKSON, I. Editor's Draft - The WebSocket API. Disponvel em http://dev.w3.org/html5/websockets. 2010. HICKSON, I. Internet-Draft - The Websocket Protocol. Disponvel em http://tools.ietf.org/html/drafthixie-thewebsocketprotocol. 2010. GARRET, Jesse James. Ajax: A New Approach to Web Applications. Disponvel em http://www.adaptivepath.com/ideas/essays/archives/000385.php. 2005. FUJISHIMA, Yuzo; UKAI, Fumitoshi; YOSHIMO Takeshi. Web Sockets Now Available In Google Chrome. Disponvel em http://blog.chromium.org/2009/12/web-sockets-now-available-in-google.html. 2009.

19