Download pdf - Disserta˘c~ao de Mestrado Jhon Franko Jorge Velardeposcomp.ufabc.edu.br/.../pdf/dissertacao-jhon-velarde.pdf · Jhon Franko Jorge Velarde APLICAC˘AO DO PROTOCOLO SPDY PARA APLICATIVOS

Universidade Federal do ABC (UFABC)

Centro de Matematica, Computacao e Cognicao (CMCC)Curso de Pos-Graduacao em Ciencia da Computacao

Dissertacao de Mestrado

Jhon Franko Jorge Velarde

APLICACAO DO PROTOCOLO SPDY PARA APLICATIVOS DE

MONITORAMENTO SOBRE REDES DE IP PUBLICO

Santo Andre - SP

2014

Curso de Pos-Graduacao em Ciencia da Computacao

Dissertacao de Mestrado

Jhon Franko Jorge Velarde



Trabalho apresentado como requisito parcialpara obtencao do tıtulo de Mestre em Cienciada Computacao, sob orientacao do Prof. Dr.Nunzio Marco Torrisi.

Santo Andre - SP

2014

Centro de Matematica, Computacao e Cognicao (CMCC)

Curso de Pos-Graduacao em Ciencia da Computacao



Jhon Franko Jorge VelardeMarco de 2014

BANCA EXAMINADORA:

• Prof. Dr. Nunzio Marco Torrisi (Presidente)(CMCC) Universidade Federal do ABC - UFABC

• Prof. Dr. Rodrigo Palucci PantoniInstituto Federal de Sao Paulo - IFSP

• Prof.a Dr.a Vera Nagamuta(CMCC) Universidade Federal do ABC - UFABC

• Prof. Dr. Ronaldo Cristiano Prati (Suplente)(CMCC) Universidade Federal do ABC - UFABC

Este exemplar foi revisado e alterado em relacao a versao original,de acordo com as observacoes levantadas pela banca no dia da de-fesa, sob responsabilidade unica do autor e com a anuencia de seuorientador.

Santo Andre, 20 de marco de 2014.

Assinatura do autor:

Assinatura do orientador:

Resumo

O objetivo deste trabalho e propor o uso do protocolo SPDY em aplicativos de

monitoramento sobre redes de IP publico, com foco nas melhorias sobre HTTP e

fornecido pelo escalonamento de requests utilizando as oito prioridades no fluxo

SPDY. Para o escalonamento SPDY, sao considerados algoritmos de padroes de

projeto que utilizam mecanismos sıncronos ou assıncronos para o gerenciamento

de requests de multiplos clientes, tais como: os padroes Reactor e Proactor. A

caracterıstica principal, o quantum de tempo, compartilhada nos algoritmos de

escalonamento, tais como: Escalonamento por Prioridade, Escalonamento Round-

Robin, Escalonamento em Filas Multinıvel, Weighted Fair Queuing e Weighted

Round-Robin, permite que os requests com menor prioridade tenham maior opor-

tunidade de ser gerenciados. Um prototipo de servidor SPDY foi desenvolvido

baseado na especificacao do protocolo SPDY e, nas caracterısticas principais

dos padroes de projeto e algoritmos de escalonamento propostos. A avaliacao

deste prototipo foi feita na simulacao de uma situacao real de monitoramento,

o prototipo considerou tres estruturas para gerenciamento de requests no escalo-

nador: oito filas de prioridade, uma fila sem prioridade e oito filas de prioridade

com um quantum de tempo para cada fila. Os resultados obtidos mostram que

os requests com maior prioridade sao processados na media em menor tempo

alem de que sao gerenciados em maior quantidade e, a utilizacao de um quan-

tum de tempo para cada fila de prioridade aumentou a quantidade de requests

gerenciados com menor prioridade.

Palavras-chave: Aplicativos de monitoramento, DNP3, SCADA, HMI, Escalona-

mento, SPDY, HTTP, Padroes de projeto, Filas, Prioridade.

iv

Abstract

The aim of this research project is to propose the use of SPDY protocol for

monitoring applications over public IP networks, with focus on the improve-

ments over HTTP provided by the request scheduling using the eight priorities

in SPDY stream. For the SPDY scheduling, are considered design patterns algo-

rithms which use synchronous or asynchronous mechanisms for handles request

of multiple clients, such as: Reactor and Proactor pattern. The main feature,

the time quantum, shared in scheduling algorithms, such as: Priority Scheduling,

Round-Robin Scheduling, Multilevel Queue Scheduling, Weighted Fair Queuing

and Weighted Round-Robin, allows lower priority requests have higher oppor-

tunity to be managed. A SPDY server prototype was developed based on the

specification of the SPDY protocol, and the main characteristics of the design

patterns and scheduling algorithms proposed. The evaluation of this prototype

was made in the simulation of a real situation monitoring, was considered in the

prototype three structures for managing requests in the scheduler: eight priority

queues, a queue without priority and eight priority queues with a time quantum

for each queue. The results show that higher priority requests are processed on

average in less time beyond that are managed in a larger quantity, and the use

of a time quantum for each priority queue increased the amount of lower priority

managed requests.

v

Agradecimentos

Agradeco a Deus pelas bencaos, pela minha saude e protecao em todos os dias

da minha vida.

Agradeco a minha esposa e amor Alisoli Pretel Jesus por que juntos somos

uma grande equipe, pelo apoio, pela presenca e grande amor, por que todo isso

foi um grande motor para conduzir este mestrado em bom caminho.

Agradeco profundamente a minha amada mae, Dominga e a minha querida

irma, Marıa, pelo amor, pelas oracoes, pela motivacao, compreensao e apoio

incondicional em todo momento.

Agradeco a meu orientador o Prof. Dr. Nunzio Marco Torrisi pela amizade,

pelos ensinamentos, ajuda e colaboracao com o meu trabalho no mestrado.

Aos professores Andre Balan, Joao Paulo Gois e Ronaldo Prati pelas novas

experiencias e pelos conhecimentos adquiridos.

E finalmente, agradeco a meus caros amigos Lıdia, Marcel e Renato por ter

me dado a sua confianca, amizade e por sempre torcer por mim.

vi

Glossario

AJAX Asynchronous Javascript and XML

CyberOPC Cybernetic OPC

DNP3 Distributed Network Protocol, version 3

HMI Human Machine InterfaceHTML5 HyperText Markup Language, version 5HTTP HyperText Transfer ProtocolHTTPS HyperText Transfer Protocol Secure

IETF Internet Engineering Task Force

OLE Object Linking and EmbeddingOPC OLE for Process ControlOPC XML-DA OPC eXtensible Markup Language-Data Ac-

cessOPC-UA OPC-Unified Architecture

RFC Request For Comments

SCADA Supervisory Control And Data AcquisitionSPDY SPeeDY ProtocolSSL Secure Sockets Layer

TCP/IP Transmission Control Protocol/ Internet Pro-tocol

TLS Transport Layer Security

W3C World Wide Web Consortium

vii

Sumario

Glossario vii

1 Introducao 2

1.1 Motivacao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

1.2 Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

1.3 Organizacao deste trabalho . . . . . . . . . . . . . . . . . . . . . . 4

2 Revisao Bibliografica 5

2.1 Tecnologias Relacionadas . . . . . . . . . . . . . . . . . . . . . . . 5

2.1.1 Melhoria do Projeto de Aplicativos HTTP . . . . . . . . . 5

2.1.2 Melhorias da Especificacao do Protocolo HTTP . . . . . . 7

2.1.3 Tecnologias Middleware para Otimizacao de uso de HTTP 8

2.2 Estado da arte . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

2.2.1 Protocolo WebSocket . . . . . . . . . . . . . . . . . . . . . 10

2.2.2 Protocolo SPDY . . . . . . . . . . . . . . . . . . . . . . . 10

2.3 Algoritmos de Escalonamento . . . . . . . . . . . . . . . . . . . . 13

2.3.1 Escalonamento Round-Robin . . . . . . . . . . . . . . . . . 13

2.3.2 Escalonamento por Prioridade . . . . . . . . . . . . . . . . 14

2.3.3 Escalonamento em Filas Multinıvel . . . . . . . . . . . . . 15

2.3.4 Weighted Fair Queuing . . . . . . . . . . . . . . . . . . . . 16

2.3.5 Weighted Round-Robin . . . . . . . . . . . . . . . . . . . . 17

3 Metodologia 18

3.1 Padroes de projeto para transmissao de dados de tipo sıncrono e

assıncrono . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

3.2 Metodologia para a avaliacao dos resultados . . . . . . . . . . . . 22

4 Desenvolvimento de um prototipo de servidor SDPY 24

viii

SUMARIO ix

5 Resultados 28

5.1 Testes I: Analise do comportamento dos tempos de processamento

nas oito filas de prioridade . . . . . . . . . . . . . . . . . . . . . . 32

5.2 Testes II: Analise e comparacao do comportamento dos tempos

de processamento em uma fila sem prioridade e nas oito filas de

prioridade . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

5.3 Testes III: Analise e comparacao do comportamento dos tempos

de processamento nas oito filas com prioridade e quantum de tempo 43

6 Conclusoes 48

Lista de Figuras

2.1 Diagrama temporal da modalidade HTTP Keep-alive (a) e Pipeli-

ning (b). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

2.2 Diagrama de conexoes SPDY. As setas grossas indicam a trans-

ferencia de dados, enquanto as setas finas mostram os tipos de

frames SPDY: PING, SETTINGS, SYN STREAM, SYN REPLY

e DATA FRAME. . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

2.3 Escalonamento Round-Robin. (a) Fila de frames. (b) Fila de fra-

mes quando FS1 nao termina apos de um quantum. . . . . . . . . 13

2.4 Um algoritmo de escalonamento com quatro classes de prioridade. 15

2.5 Escalonamento em Filas Multinıvel. . . . . . . . . . . . . . . . . . 16

2.6 Weighted Fair Queuing. . . . . . . . . . . . . . . . . . . . . . . . 17

2.7 Weighted Round-Robin. . . . . . . . . . . . . . . . . . . . . . . . . 17

3.1 Diagrama de interacao para o padrao Reactor. . . . . . . . . . . . 19

3.2 Diagrama de interacao para o padrao Proactor. . . . . . . . . . . 21

3.3 Registro de Eventos (a) Reactor. (b) Proactor. . . . . . . . . . . . 21

3.4 Esquema do projeto. . . . . . . . . . . . . . . . . . . . . . . . . . 22

3.5 Abordagem basica do poll de atualizacao. . . . . . . . . . . . . . . 23

4.1 Visao geral das etapas desenvolvidas no projeto. . . . . . . . . . . 25

4.2 Diagrama de interacao para o enfileiramento de eventos. . . . . . 26

4.3 Dinamica do desenfileiramento de eventos. . . . . . . . . . . . . . 26

4.4 Diagrama de interacao para o despacho de eventos. . . . . . . . . 27

x

LISTA DE FIGURAS xi

5.1 Estrutura dos arquivos de Teste A, F, J e Trafego de Fundo com o

valor da prioridade na primeira coluna e o tempo de inter-arrival

na segunda. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

5.2 (a) Armazenamento na estrutura de dados. (b) Gerenciamento dos

novos requests. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

5.3 Esquema dos testes 1 e 2. . . . . . . . . . . . . . . . . . . . . . . 32

5.4 Plotting 2D do teste 1 utilizando um cliente SPDY para transmitir

o trafego de fundo. . . . . . . . . . . . . . . . . . . . . . . . . . . 33

5.5 Plotting 2D do teste 2 utilizando um cliente SPDY para transmitir

o trafego de fundo. . . . . . . . . . . . . . . . . . . . . . . . . . . 33


5.7 Plotting 2D do teste 3 utilizando outro cliente SPDY para trans-

mitir o trafego de fundo. . . . . . . . . . . . . . . . . . . . . . . . 34








5.12 Vista 1: Plotting 3D do teste 7 utilizando oito filas de prioridade. 38






5.18 Vista 1: Plotting 3D do teste 9 utilizando uma fila de prioridade. 42



LISTA DE FIGURAS xii

5.21 Nova dinamica de desenfileiramento para o teste. . . . . . . . . . 44



5.24 Vista 1: Plotting 3D do teste 11 utilizando um quantum para cada

fila de prioridade. . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

5.25 Vista 2: Plotting 3D do teste 11 utilizando um quantum para cada

fila de prioridade. . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

Lista de Tabelas

5.1 Caracterısticas do servidor e das maquinas clientes. . . . . . . . . 28

5.2 Resultados dos Testes 7, 8 e 9. . . . . . . . . . . . . . . . . . . . . 47

5.3 Resultados dos Testes 10 e 11. . . . . . . . . . . . . . . . . . . . . 47

xiii

Lista de Algoritmos

1 Algoritmo de Gerenciamento de Eventos . . . . . . . . . . . . . . 22

1

Capıtulo 1

Introducao

Em 1991, foi especificada a primeira versao do protocolo HTTP por Tim Berners-

Lee e, em 1996, foi padronizado pelo IETF como HTTP 1.0 e documentado no

RFC 1945 [1]. Apenas tres anos depois, pelo aumento da carga na web, foi pa-

dronizado o HTTP 1.1 pelo IETF. O protocolo revisado no RFC 2616 [2] reduziu

o numero necessario de requisicoes de conexao para um terminal atraves da in-

troducao de conexoes keep-alive [3] e, atraves do HTTP pipelining [4] permitiu

multiplos requests em sequencia sem a necessidade de esperar por as correspon-

dentes responses. O HTTP nao mudou muito desde entao, embora o panorama

web tenha mudado fundamentalmente.

Desde a primeira especificacao do protocolo HTTP - RFC 1945, os aplicativos

baseados neste protocolo evoluıram superando a limitacao da especificacao para

trabalhar com streaming e conteudos web interativos. No entanto, muitos dos

gargalos das implementacoes HTTP 1.1 estao relacionadas a gestao de multiplas

conexoes simultaneas, configuracoes de conexao de ida e volta desnecessarias,

controle de congestionamento e um racionamento constante causado pelo cliente

onde ele tenta evitar a abertura de muitas conexoes em um unico servidor [5].

Enquanto a comunidade cientıfica vem desenvolvendo novas ideias para melhorar

o desempenho de aplicativos web sobre HTTP 1.1, a limitacao do domınio de mui-

tos aplicativos de monitoramento de redes IP locais foi estendida para redes de

IP publico usando HTTP como protocolo preferido para aplicativos personaliza-

2

CAPITULO 1. INTRODUCAO 3

dos. Os aplicativos modernos SCADA1 e HMI2 tem acesso em leitura e escritura,

parcial ou totalmente, a suas variaveis de processo atraves de protocolos HTTP,

HTTPS, ModBus [6], DNP [7] e outros, usando gateways como OPC XML-DA

[8], OPC-UA [9], CyberOPC [10] e muitas outras solucoes interessantes.

1.1 Motivacao

Este trabalho foi motivado pela utilizacao das novas caracterısticas de prioridade

introduzidas pelo protocolo SPDY [5], que permita melhorar o desempenho de

qualquer aplicativo de monitoramento que usa o protocolo HTTP. Esta aborda-

gem tenta resolver o problema atraves do protocolo e nao atraves de um mid-

dleware de aplicativos HTTP, por exemplo, o Reverse AJAX [11]. Assim, os

principais resultados esperados sao:

• Uma metodologia otimizada para usar o protocolo SPDY em redes publicas

para monitoramento e controle de processos industriais;

• A contribuicao tecnologica na industria de software para aplicativos de mo-

nitoramento atraves da internet.

1.2 Objetivos

O principal objetivo e pesquisar e desenvolver um prototipo de servidor SPDY

baseado nas especificacoes do protocolo, os estudos de padroes de projeto e nas

caracterısticas dos algoritmos de escalonamento aplicadas na teoria de gerenci-

amento de filas de prioridade do escalonador SPDY. Os algoritmos de gerencia-

mento de filas adotados no projeto do servidor sao justificados pela caracterıstica

de prioridade do protocolo SPDY. Mais especificamente, os objetivos sao:

• Investigar o protocolo SPDY, os padroes de projeto e algoritmos de escalo-

namento, para atingir os requerimentos de gerenciamento de prioridades e

1SCADA ou Supervisory Control and Data Acquisition e um sistema que utiliza softwarepara monitorar e supervisionar as variaveis e dispositivos de sistemas de controle industrial.

2HMI ou Human–machine interface inclui componentes de hardware e software pelo qual osusuarios interagem com as maquinas.

CAPITULO 1. INTRODUCAO 4

modelar a integracao do gerenciador de fluxo de prioridades SPDY;

• Desenvolver um servidor de teste e simular cenarios de aplicativos de mo-

nitoramento no laboratorio;

• Comparar a estrategia de gerenciamento de fluxo sobre redes de IP publico

e avaliar os resultados.

1.3 Organizacao deste trabalho

O primeiro capıtulo e destinado a fornecer o leitor uma visao geral dos assuntos

abordados neste trabalho, assim, neste capıtulo sao apresentadas a introducao,

motivacao e os objetivos.

No capıtulo 2 sao apresentadas as caracterısticas de varias tecnologias relacio-

nadas que visam a melhoria de HTTP. Tambem descrevemos o estado da arte que

abrange os protocolos WebSocket e SPDY, considerados os principais candidatos

para a proxima e esperada especificacao do HTTP 2.0 pelo IETF. Alem disso,

sao abordadas as caracterısticas principais dos algoritmos de escalonamento.

No capıtulo 3 sao descritas as caracterısticas principais dos padroes de pro-

jeto consideradas para o desenvolvimento do escalonador SPDY. Alem disso, e

apresentada a metodologia utilizada para avaliacao dos resultados.

No capıtulo 4 sao abordadas, detalhadamente, as etapas compreendidas no

desenvolvimento de um prototipo de servidor SPDY.

No capıtulo 5 sao apresentados os resultados dos distintos experimentos feitos

sobre o prototipo desenvolvido, alem de descrever a analise de cada um deles. A

avaliacao foi feita na simulacao de uma situacao real de monitoramento conside-

rando tres grupos de testes.

Finalmente, no capıtulo 6 sao apresentadas as conclusoes desta dissertacao.

Capıtulo 2

Revisao Bibliografica

2.1 Tecnologias Relacionadas

2.1.1 Melhoria do Projeto de Aplicativos HTTP

Blocking e Non-Blocking Socket Os termos de Blocking e Non-Blocking

I/O fazem referencia a maneira pela qual os I/O sao processados no sistema

operacional (OS), sıncrona ou assincronamente respectivamente. O problema

da limitacao de conexoes simultaneas esta relacionado tambem a forma como

o servidor foi implementado e como o OS trabalha com os sockets. Querendo

iniciar uma conexao com o servidor e utilizando um socket para qualquer tipo

de operacao, no Blocking I/O, a operacao e iniciada com um thread, a qual fica

imediatamente em espera ate que o pedido esteja completo. No caso de Non-

Blocking I/O, existem duas alternativas, ou um polling, onde o servidor tenta

fazer a operacao cada intervalo de tempo, ou a utilizacao de uma notificacao

assıncrona, no qual o servidor gera um evento indicando que uma operacao esta

pronta para ser processada.

Devido a complexa interacao entre HTTP e o subjacente protocolo da camada

de transporte (TCP), quer isto dizer, apesar da adicao das tecnicas de HTTP

keep-alive e pipelining em HTTP/1.1, um atraso de 500 ms no servidor HTTP

impede a reutilizacao do canal TCP para requests adicionais, do modo que, os

navegadores atuais evitam este problema abrindo multiplas conexoes simultaneas,

em uma media de 6 conexoes. O gerenciamento de multiplas sessoes TCP, para

suportar essas conexoes simultaneas, aumenta a sobrecarga e a latencia. SPDY

5

CAPITULO 2. REVISAO BIBLIOGRAFICA 6

[5] proporciona melhorias significativas de latencia, mas existem outras solucoes

propostas para a latencia web, principalmente no nıvel da camada de transporte

ou sessao.

Stream Control Transmission Protocol (SCTP) E um protocolo da ca-

mada de transporte que trabalha como os populares protocolos TCP e UDP e

oferece algumas de suas caracterısticas de servico. E orientado a mensagem como

UDP e garante a confiabilidade e mensagens em sequencia com o controle de

congestionamento como TCP. Alem disso, a motivacao principal por detras do

SCTP e fornecer um protocolo mais confiavel e robusto do que o TCP e UDP, o

qual pode aproveitar recursos como multihoming 1 [12]. O protocolo foi definido

pelo grupo de trabalho de transporte de sinalizacao SIGTRAN do IETF em 2000,

e e mantido pelo grupo de trabalho da area de transporte (TSVWG) do IETF. O

RFC 4960 define o protocolo e o RFC 3286 fornece uma introducao. Na ausencia

de suporte nativo para SCTP em sistemas operacionais e possıvel o tunel SCTP

sobre UDP, assim como o mapeamento de chamadas da API de TCP para SCTP.

HTTP sobre SCTP E uma proposta para a execucao de HTTP sobre SCTP.

HTTP requer um transporte confiavel para a comunicacao fim-a-fim. Semelhante

ao TCP, o SCTP oferece uma conexao de transporte fim-a-fim confiavel para apli-

cativos web, alem disso, oferece outros servicos inovadores indisponıveis no TCP,

incluindo multi-transmissao, multihoming, fiabilidade parcial e transferencia de

dados orientados a mensagem [13].

Structured Stream Transport (SST) SST e um protocolo de transporte

experimental projetado para atender as necessidades de aplicativos modernos

que precisam trabalhar com muitas atividades de comunicacao assıncrona em

paralelo, tal como baixar diferentes partes de uma pagina web e a reproducao de

audio e multiplos streams de vıdeo de forma simultanea [14].

1 O multihoming faz referencia a um computador ou dispositivo (celular, tablet) conectadoa mais de uma rede.


MUX e SMUX Sao protocolos de gerenciamento de sessao que separam o

transporte subjacente dos protocolos de aplicacao de nıvel superior. Fornecem um

canal de comunicacao leve para a camada de aplicacao atraves da multiplexacao

de fluxos de dados, sobre um transporte orientado de fluxo confiavel. Ao suportar

a coexistencia de multiplos protocolos de nıvel de aplicacao (por exemplo, HTTP

e HTTP-NG), eles irao facilitar as transicoes para futuros protocolos web e as

comunicacoes de applets cliente utilizando protocolos privados com os servidores

sobre a mesma conexao TCP como a conversacao HTTP [15].

2.1.2 Melhorias da Especificacao do Protocolo HTTP

Keep-alive Tambem chamado conexao persistente HTTP, permite ao servidor

manter a conexao TCP aberta apos do envio das respostas. As sub-sequentes

requests/responses entre o mesmo cliente e servidor podem ser enviados atraves

da mesma conexao. Depois de um determinado perıodo de tempo (intervalo de

tempo de espera), o servidor HTTP fecha a conexao quando nao e utilizada. E

uma tecnica padrao do HTTP/1.1 e existe em duas versoes: com pipelining e sem

pipelining [3]. A figura 2.1-(a) mostra o esquema do HTTP Keep-alive com os

requests/responses entre o mesmo cliente e servidor atraves da mesma conexao.

HTTP Pipelining E uma tecnica que quebra o modelo rigoroso: “enviar uma

solicitacao e esperar pela resposta”, especificada em HTTP 1.0 [1], e permite

despachar multiplos requests HTTP em paralelo para o servidor em uma unica

conexao TCP, sendo utilizado com muito mais eficacia, mas com o tempo trans-

corrido muito menor, sem esperar pelas respostas correspondentes. Logo que os

pedidos sao todos enviados, o cliente HTTP (navegador) comeca a escutar para

responder. O HTTP Pipelining permite menos pacotes TCP para ser enviados

atraves da rede, desde que no mesmo pacote TCP e possıvel agrupar varios re-

quests HTTP, reduzindo a carga de rede [4]. A figura 2.1-(b) mostra o esquema do

HTTP Pipelining com multiplos requests, em paralelo, sobre a mesma conexao.


Cliente Servidor

Abrir

Fechar

Cliente Servidor

Abrir

Fecharte

mp

o

(a) (b)

Figura 2.1: Diagrama temporal da modalidade HTTP Keep-alive (a) e Pipelining(b).

HTTP Server Push Envolve o envio de pacotes de dados periodicamente

desde o servidor HTTP para o cliente HTTP. A conexao HTTP entre o cliente

e o servidor e mantida aberta indefinidamente, de modo que se um evento e

recebido pelo servidor, este pode ser imediatamente enviado para um ou multiplos

clientes, ou caso contrario, os dados teriam que ser enfileirados ate que o proximo

request do cliente seja recebido. Este mecanismo pode ser implementado em

um programa CGI atraves do uso de tipo de MIME multipart/x-mixed-replace.

Tambem e conhecido como HTTP streaming e e suportado apenas pelo Netscape

Navigator (versao 1.1 ou superior) e Internet Explorer [16].

2.1.3 Tecnologias Middleware para Otimizacao de uso deHTTP

Estas tecnologias requerem um software middleware com JavaScript do lado do

cliente e do servidor para a transferencia de dados.

Reverse Ajax Comet [17], conhecido por outros nomes incluindo Reverse Ajax,

e um modelo de aplicacao web que permite aos servidores web enviar dados para

um navegador cliente, sem a necessidade de um request explıcito [17]. Neste

modelo, um request e enviado para o servidor e mantido ativo por um longo

tempo, ate um limite de tempo ou a ocorrencia de um evento do servidor. Quando


o request e completado, outro request Ajax de longa duracao e enviado para

esperar por outros eventos do servidor. A maior vantagem do Comet e que cada

cliente sempre tem um link de comunicacao aberto com o servidor, no qual pode

enviar os eventos aos clientes para completar imediatamente as respostas quando

eles chegarem, ou ate mesmo acumular e enviar por rajadas [18].

Bayeux E uma solucao de codigo aberto projetado para proporcionar baixa

latencia atraves de HTTP. Ele trabalha transportando as mensagens assıncronas

e roteando eventos entre clientes e servidores utilizando um modelo publicar/-

subscrever. O objetivo principal de Bayeux e a implementacao de interacoes

de usuarios que respondem a clientes web usando Ajax e a tecnica server-push

chamada de Comet. A ideia principal e facilitar a interoperacao entre as im-

plementacoes para resolver a distribuicao comum de mensagens e problemas de

roteamento, e fornecer mecanismos para melhorias incrementais e de extensoes.

Entre suas operacoes globais encontramos os transportes “Streaming”, que utili-

zam a tecnica de streaming para permitir que multiplas mensagens sejam enviadas

dentro da mesma resposta HTTP, mas que estejam sujeitas a implementacao dos

agentes de usuario e proxies que requerem respostas HTTP incompletas para ser

entregue ao cliente Bayeux [19].

BOSH Ou “Bidirectional-streams Over Synchronous HTTP”, e uma tecnolo-

gia que emula um fluxo bidirecional via HTTP entre cliente e servidor, usando

multiplos requests/responses sıncronos de HTTP. BOSH consegue uma largura

de banda eficiente, para aplicativos que requerem comunicacoes “push” e “pull”,

e baixa latencia, sem requerimento de polling ou segmentacao assıncrona, como

e feito na tecnica conhecida como Comet [20].


2.2 Estado da arte

Os requerimentos definidos pelo IETF para o futuro protocolo HTTP incluem um

bom desempenho para os navegadores convencionais e moveis e um amplo grau

de compatibilidade com versoes anteriores. O desenvolvimento das especificacoes

de HTTP 2.0 tem como referencia as caracterısticas de SPDY [21]. WebSocket

e SPDY sao tecnologias que incluem as caracterısticas principais das tecnologias

descritas na secao 2.1 como o Pipelining, reutilizacao da conexao aberta TCP,

multiplexacao de fluxos de dados, o Server Push, etc., e seus drafts de espe-

cificacoes no IETF e W3C sao muito ativos em termos de grupo de interesse.

Ambos sao candidatos para a proxima especificacao de HTTP 2.0.

2.2.1 Protocolo WebSocket

E uma tecnologia web desenvolvida como parte do padrao entrante HTML5 [22],

com suporte para comunicacao bidirecional e full-duplex, ao contrario de tecno-

logias como BOSH ou equivalentes, que requerem apenas uma unica conexao de

socket para que as mensagens sejam enviadas entre o cliente e o servidor. Servi-

dores proxy e firewall com WebSocket sao conscientes que usam o canal HTTP e

que podem operar tambem sobre SSL [23]. O API de WebSocket esta sendo pa-

dronizado pelo W3C, e o protocolo WebSocket foi padronizado pelo IETF como

RFC 6455 [24].

2.2.2 Protocolo SPDY

SPDY [5] e um novo protocolo da camada de aplicacao desenvolvido pela empresa

Google Inc. para transportar mensagens HTTP de forma mais rapida. SPDY foi

projetado para reduzir a latencia e aumentar a seguranca. SPDY e considerado

um substituto para o HTTP e como protocolo de pacotes (frames) tem suporte

para a codificacao de dados binarios e suporte nativo para TLS (SSL). SPDY

adiciona um framing layer ou camada de enquadramento para a multiplexacao

de fluxos de mensagens HTTP simultaneos, atraves de uma unica conexao TCP.


O framing layer e otimizado para fluxos request/response do tipo HTTP, tal que

os aplicativos que rodam sobre HTTP atualmente podem trabalhar sobre o SPDY

com pouca ou nenhuma alteracao dependendo do desenvolvimento dos aplicativos

web.

A sessao SPDY permite requests simultaneos HTTP para rodar em uma unica

sessao TCP/IP, e oferece quatro melhorias sobre HTTP:

• Requests multiplexados. Nao existe limite para o numero de requests

que podem ser emitidos simultaneamente em uma unica conexao SPDY.

Como os requests sao intercalados em um unico canal, o protocolo e mais

eficiente sobre TCP.

• Requests priorizados. Os clientes podem solicitar certos recursos para

serem entregues primeiro. Isto evita o problema de congestionar o canal

de rede com os recursos nao crıticos, quando um pedido de alta prioridade

esta pendente.

• Cabecalhos comprimidos. Os clientes atualmente enviam uma quan-

tidade significativa de dados redundantes na forma de cabecalhos HTTP

devido ao fato de que uma unica pagina web pode requerer 50 ou 100 sub-

requests. Comprimir os cabecalhos economiza uma quantidade significativa

de largura de banda alem de reduzir a latencia em relacao ao HTTP, assim

SPDY comprime os cabecalhos dos requests e responses HTTP utilizando

zlib [25], um metodo de compressao baseado em dicionario amplamente

utilizado [26].

• Server pushed streams . Permite aos clientes receber dados de servidores

sem precisar da requisicao deles.

A especificacao tecnica de SPDY esta dividida em duas partes: Framing Layer

e HTTP Layer. O framing layer, no ultimo draft [5] considera seis partes: sessoes,


que esta associado as conexoes, framing, fluxos, que entre suas caracterısticas con-

sidera a priorizacao do request, tratamento de erros, fluxo de dados e tipos de fra-

mes de controle. No HTTP Layer, o SPDY tenta preservar a semantica existente

de HTTP embora a sintaxe de transmitir essa semantica tenha mudado. Entre

essas mudancas considera-se o gerenciamento da conexao, o request/response de

HTTP e transacoes enviadas pelo servidor. A figura 2.2 mostra o diagrama para

conexoes SPDY, baseado no tıpico intercambio de pacotes TCP [27], onde varios

parametros de tempo sao necessarios para caraterizar esse intercambio como: O

round-trip time ou tempo de ida/volta que tarda um pacote enviado desde um

emissor, o segment transmission time, como tempo que leva para enviar o maior

numero possıvel de pacotes, o tempo de execucao do algoritmo de controle de

congestionamento slow-start, e finalmente o tempo de processamento do request

no servidor SPDY.

Cliente

SPDY

Servidor

SPDY

Setup

(PING,

SETTINGS)

round-trip

time(RTT)

“tempo de

processamento”

Request inicial

(SYN_STREAM)

Response

(SYN_REPLY,

DATA_FRAME)

segment

transmission

time

slow-start

sustained

transfer...

Figura 2.2: Diagrama de conexoes SPDY. As setas grossas indicam a transferenciade dados, enquanto as setas finas mostram os tipos de frames SPDY: PING,SETTINGS, SYN STREAM, SYN REPLY e DATA FRAME.


2.3 Algoritmos de Escalonamento

Para o gerenciador de requests com prioridade, alguns algoritmos de escalona-

mento sao considerados, alguns bem conhecidos de teorias de sistemas operaci-

onais, tais como: Escalonamento Round-Robin, Escalonamento por Prioridade

e Escalonamento em Filas Multinıvel, e tambem algumas propostas tais como:

Weighted Fair Queuing e Weighted Round-Robin.

2.3.1 Escalonamento Round-Robin

Um dos mais antigos, simples, justos algoritmos amplamente utilizado e o escalo-

namento round-robin (ERR). A cada frame SPDY (FS) e atribuıdo um intervalo

de tempo, chamado quantum, o qual e permitido para executar. Se o FS atual

ainda esta em execucao no final do quantum, no escalonador SPDY (ES) ocorre

uma preempcao e cede o lugar a outro FS. Se o FS foi bloqueado ou terminado

antes que tenha decorrido o quantum, um novo FS e escolhido na fila pelo esca-

lonador. O round-robin e facil de implementar. O escalonador tem uma fila de

frames, como e mostrado na figura 2.3-a. Quando o frame FS nao termina apos

um quantum, ele e colocado no final da fila, como e mostrado na figura 2.3-b.

FS1 FS2 FS3 FS4

Atual

Frame

Próximo

Frame

FS2 FS3 FS4 FS1

Atual

Frame

(a) (b)

Figura 2.3: Escalonamento Round-Robin. (a) Fila de frames. (b) Fila de framesquando FS1 nao termina apos de um quantum.


O unico problema interessante com o escalonamento round-robin e a duracao

do quantum. Definir um quantum com pouco tempo provocaria muitas co-

mutacoes dos frames e uma baixa na eficiencia do escalonador, mas defini-lo

com muito tempo pode causar uma ma resposta aos requests interativos curtos

[28].

Fair Queuing No fair queuing (FQ), os frames FS sao enviados e armazenados

em filas. O algoritmo de escalonamento round-robin e usado para servir todas as

filas de uma forma justa. A principal vantagem do FQ e que os fluxos em rajadas

nao afetam o desempenho global [29].

2.3.2 Escalonamento por Prioridade

O escalonamento round-robin faz a suposicao implıcita que todos os frames FS sao

igualmente importantes. A necessidade de levar em conta fatores externos, leva

ao escalonamento por prioridade (EP). A ideia basica e simples: A cada frame

FS e atribuıda uma prioridade e o FS com a maior prioridade tem permissao de

execucao.

A fim de prevenir a execucao indefinida dos frames FS com maior prioridade,

o escalonador ES pode diminuir a prioridade dos FS atualmente em execucao

em cada ciclo de relogio (isto e, a cada interrupcao do relogio). Se essa acao

atribui uma prioridade menor para deixar sem execucao ao proximo FS com maior

prioridade, entao um troco de FS ocorre. Alternativamente, a cada FS pode ser

atribuıdo um tempo maximo de quantum que e permitido para executar. Quando

este quantum se esgota, e dada a oportunidade de execucao ao proximo FS com

prioridade mais alta.

E frequentemente conveniente agrupar os frames FS em classes de prioridade

e usar o escalonamento por prioridade entre as classes, mas com o escalonamento

round-robin dentro de cada classe. A figura 2.4 mostra um sistema com quatro

classes de prioridade. O algoritmo de escalonamento e da seguinte maneira: en-

quanto existam frames FS executaveis na classe de prioridade 1, basta executar


cada um por um quantum “round-robin por turnos”, sem preocupar-se pelas clas-

ses de menor prioridade, se a classe de prioridade 1 esta vazia entao executamos

os frames FS da classe round-robin 2. Se as classes 1 e 2 sao ambas vazias, em

seguida, executamos a classe round-robin 3, e assim por diante. Se as prioridades

nao sao ajustadas ocasionalmente, todas as classes de menor prioridade podem

morrer por inanicao [28].

Escalonador

Prioridade máxima

Prioridade mínima

Despachador

FS1 FS2 FS3 FS3

FS9

FS8

FS6

FS4

FS5

FS5

FS4

FS6

FS7FS7

FS1

FS8

FS2

FS9

Figura 2.4: Um algoritmo de escalonamento com quatro classes de prioridade.

2.3.3 Escalonamento em Filas Multinıvel

O algoritmo de escalonamento em filas multinıvel, divide a fila pronta em varias fi-

las separadas, como na figura 2.5. Os frames FS sao permanentemente atribuıdos

a uma fila, geralmente baseados em alguma propriedade do FS, seja pela prio-

ridade ou pelo tipo de frame. Cada fila tem seu proprio algoritmo de escalona-

mento. Por exemplo, de duas filas separadas com frames FS, a primeira fila pode

ser escalonada por um algoritmo de escalonamento ERR, enquanto a segunda fila

pode ser escalonada por um algoritmo de escalonamento EP.

Cada fila tem prioridade absoluta sobre as filas de prioridade inferior, tambem

pode ser atribuıdo um intervalo de tempo entre as filas. Assim, cada fila recebe

certa porcao de tempo, o qual pode entao, escalonar entre seus multiplos frames

FS [30].


Prioridade Alta

FS9 FS7 FS3 FS1

FS

Tempo

Real

Interativo

preemptado

preemptado

FS0

preemptado

preemptado

Sistema

Lote

Prioridade baixa

FS FS FS

FSFSFSFS

FS FS FS FS

Figura 2.5: Escalonamento em Filas Multinıvel.

2.3.4 Weighted Fair Queuing

O weighted fair queuing (WFQ), e uma tecnica de escalonamento de frame de

dados, que permite diferentes prioridades de escalonamento para os fluxos de

dados multiplexados estatisticamente. A ideia deste algoritmo pode ser facilmente

explicada como uma combinacao dos algoritmos de escalonamento por prioridade

e fair queuing. Tal como no metodo FQ, todas as filas sao servidas de maneira

que nao existe qualquer inanicao de largura de banda, mas algumas filas tem

mais peso no sentido que elas recebem mais servico. Em outras palavras, o peso

e dado a cada fila para atribuir diferentes prioridades as filas. Os frames sao

armazenados na fila apropriada de acordo com sua classificacao.

A figura 2.6 mostra um exemplo do algoritmo WFQ. Os tempos finais sao

atribuıdos somente para um uso qualitativo. Atribuindo um peso alto para uma

fila, ele deve permitir ao escalonador tomar mais de um frame FS dessa fila que

das as outras [29].


Fila 1 (50%)

Fila 2 (25%)

Fila 3 (25%)

FS1

Escalonador

Ordem da transmissão de frames

FS9 FS1FS2

FS2 FS3

FS3FS4FS4 FS5FS5 FS6FS6 FS7

FS7

FS8

FS8 FS9

Figura 2.6: Weighted Fair Queuing.

2.3.5 Weighted Round-Robin

O Weighted Round-Robin (WRR) e um algoritmo de escalonamento onde o buf-

fer e dividido em k filas que representam os fluxos ativos, o algoritmo percorre

cada fila e um fator de ponderacao determina quantos bytes de dados do sistema

entrega de cada fila antes de passar para a proxima fila. Um peso e associado a

cada fila proporcionalmente a taxa de bits requerida da fila e, a maneira como as

filas sao servidas e atraves de uma disciplina Round-Robin de acordo com o peso:

cada fila e servido proporcionalmente a seu proprio peso [31].

P=4

P=3

P=2

Escalonador

P=1

Despachador

Alta

Baixa

Filas

FS1 FS2 FS3 FS2

FS3

FS1

FS4

FS4

FS5

FS5

FS6

FS6

FS7FS7

FS8

FS8

FS9

FS9

Figura 2.7: Weighted Round-Robin.

A figura 2.7 mostra um exemplo do algoritmo WRR. O escalonamento WRR

previne que as filas de menor prioridade sejam ignoradas completamente durante

os perıodos de trafego de alta prioridade. Ao utilizar este escalonamento, as filas

de baixa prioridade tem a oportunidade de transmitir frames FS, embora as filas

de alta prioridade nao estejam vazias.

Capıtulo 3

Metodologia

Fluxos e Prioridades em SPDY Apesar de que as caracterısticas atuais do

protocolo HTTP restringem seu otimo desempenho como o envio de um unico

request por conexao, cabecalhos HTTP redundantes, etc., SPDY retem a compati-

bilidade e mantem a estrutura basica de HTTP, tal como a semantica dos requests

e response, ao contrario de WebSocket que requer uma reprogramacao no processo

de encapsulamento de HTTP [24]. Alem disso, oferece a multiplexacao de fluxos,

que proporciona benefıcios adicionais como priorizar os requests, garantindo que

os mais importantes tenham prioridade sobre os menos importantes. Em SPDY,

o iniciador de um fluxo, atribui uma prioridade ao request que e representado por

um numero inteiro de 0 a 7, sendo 0 a maior prioridade e 7 a menor prioridade

[5].

3.1 Padroes de projeto para transmissao de da-dos de tipo sıncrono e assıncrono

Para a implementacao do escalonamento de fluxo e a concorrencia em um servidor

SPDY, serao considerados padroes de projeto de arquitetura de software para o

gerenciamento de eventos em sistemas de rede que usam mecanismos sıncronos e

assıncronos, entre os quais temos os padroes Reactor e Proactor. Comparado aos

mecanismos sıncronos, os mecanismos assıncronos sao atrativos porque oferecem

o benefıcio da concorrencia enquanto aliviam muito a sobrecarga e a complexidade

do multi-threading [32].

18

CAPITULO 3. METODOLOGIA 19

Padrao de projeto Reactor O Reactor e um padrao que simplifica o traba-

lho aos aplicativos orientados a eventos atraves da integracao da demultiplexacao

sıncrona de eventos e o despacho de seus gerenciadores de eventos corresponden-

tes. O padrao Reactor esta constituıdo pelos seguintes participantes: Handles,

que identificam os recursos que sao gerenciados por um sistema operacional; O

demultiplexador sıncrono de eventos, que bloqueia os recursos esperando pela

ocorrencia de eventos em um conjunto de Handles ; A iniciacao do despachador,

que define uma interface para o registro, remocao e envio dos gerenciadores de

eventos; Os gerenciadores de eventos, que especificam uma interface usada pela

iniciacao do despachador chamando de volta aos metodos hook 1 pre-registrados

para processar certos tipos de eventos e finalmente o gerenciador de eventos con-

cretos, que implementa os metodos hook que processam eventos em uma forma

especıfica da aplicacao [33]. A figura 3.1 mostra um diagrama de interacao para

o padrao Reactor.

Initializa

Programa

principal

Callback:

Gerenciador de

eventos concretos :Reactor :Handles

Registrar o

gerenciador

Obter o

gerenciador

Executar no

mesmo laço

Esperar por

eventos

Despachar

gerenciador(es)

Reactor()

registrar_gerenciador(callback)

obter_gerenciador()

gerenciar_eventos()

select()

gerenciar_evento(tipo_evento)

Figura 3.1: Diagrama de interacao para o padrao Reactor.

1Os Metodos hook sao definidos em interfaces ou classes abstratas e devem necessariamenteser implementados por uma aplicacao.


Padrao de projeto Proactor O Proactor e um padrao usado para descrever

como iniciar, receber, demultiplexar, despachar e processar eventos. Seu prin-

cipal objetivo e melhorar o desempenho de um aplicativo orientado a eventos

que recebe e processa multiplos eventos de forma assıncrona. O padrao Proac-

tor e desenvolvido da seguinte forma: quando um evento chega, a entidade do

aplicativo, referido a um iniciador, comeca uma operacao assıncrona apropriada,

em seguida, o Proactor registra o evento com um gerenciador e despachador de

eventos associados ao processador de operacoes assıncronas, logo apos, o iniciador

invoca a operacao assıncrona registrada no processador de operacoes assıncronas.

Uma operacao assıncrona e executada sem bloquear o thread de controle do ge-

renciamento de eventos, assim, ele pode realizar outras operacoes. Uma vez

que a operacao e concluıda, o processador de operacoes assıncronas recupera in-

formacoes do gerenciador e despachador de eventos correspondentes, e gera um

evento de conclusao contendo os resultados da operacao assıncrona, logo apos, de-

multiplexa e despacha o evento para o gerenciador de eventos associado a operacao

assıncrona. Posteriormente, o gerenciador de eventos processa os resultados da

operacao assıncrona e chama novamente a aplicacao [32].

O padrao Proactor oferece os seguintes benefıcios: maior portabilidade da

logica da aplicacao, encapsulamento do mecanismo de concorrencia pelo despa-

chador de conclusao, uma polıtica de threading desacoplada da polıtica de con-

correncia, maior separacao de interesses, e maior desempenho e simplificacao da

sincronizacao de aplicativos. No entanto, ele tambem tem os seguintes inconve-

nientes: o escalonamento e controle de operacoes pendentes e a dificuldade de

depuracao [34]. A figura 3.2 mostra um diagrama de interacao para o padrao

Proactor.


Operação

assíncrona iniciada

Iniciador do

Proactor

Processador

da Operação

Assíncrona

Operação

Assíncrona

Operação realizada

assincronamente

Operação concluída

Gerenciador de

conclusão notificado

registrar(operação, gerenciador, despachador)

executar()

despachar()

gerenciar_evento()

Despachador

de conclusão

Gerenciador

de conclusão

Figura 3.2: Diagrama de interacao para o padrao Proactor.

Em resumo, tanto o Reactor quanto o Proactor sao padroes de projeto focados

nos aplicativos orientados a eventos e que compartilham principalmente as funcoes

de registro, demultiplexacao e gerenciamento de multiplos eventos.

I1

I2I1

I2

I3

I1 I1

I2

I3

I1

I2I1

I4

Fila 0 Fila 1 Fila 2 Fila 3 Fila 4 Fila 5 Fila 6 Fila 7

I2

I3

I1

Fila

I2

I3

I1

(b)(a)

I5

I6

I4

I1

Figura 3.3: Registro de Eventos (a) Reactor. (b) Proactor.

A figura 3.3 mostra o registro de eventos em ambos padroes, e utilizada uma

fila como estrutura de dados de armazenamento dos eventos para a implementacao

do mecanismo sıncrono do padrao Reactor. A diferenca do Proactor e que utiliza

oito filas chamadas filas de prioridade para implementar o mecanismo assıncrono.

Alem disso, tanto o Reactor quanto o Proactor tambem compartilham a

mesma estrutura do algoritmo 1 de gerenciamento de eventos, mas a diferenca

deles esta na funcao de demultiplexacao dos eventos onde, no Reactor e realizado

atraves do desenfileiramento do evento pronto na unica fila utilizada enquanto

no Proactor e realizado por meio de uma dinamica de desenfileiramento que sera

descrita no capıtulo 4, ambos gerenciam o evento obtido com a mesma logica para

responder a requisicao envolvida no evento.Como se pode deduzir, o Proactor e


Algorithm 1 Algoritmo de Gerenciamento de Eventos

1: procedure Handle Events2: loop3: while queue.size > 0 do4: queueItem = Dequeue() . Demultiplexing Events5: response = HandleEvent(queueItem)6: Send response7: end while8: end loop9: end procedure

uma versao do Reactor que, mesmo assim que conceitualmente sejam distintos,

adiciona oito filas de prioridade para melhorar o gerenciamento dos eventos.

3.2 Metodologia para a avaliacao dos resultados

A avaliacao se baseou na comparacao do desempenho entre as diferentes es-

trategias de gestao de fluxo SPDY, testadas durante a execucao do escalonador.

Assim, tendo em conta os parametros de tempo do diagrama de SPDY na fi-

gura 2.2, vamos considerar como parte da avaliacao o tempo de processamento

nas filas de prioridade do escalonador baseado nos algoritmos de padroes de pro-

jeto Reactor e Proactor do servidor SPDY.

Os modelos de trafego adotados para os testes da rede, estarao baseados no

trafego gerado por um grupo de outstations ou estacoes exteriores DNP3 [7], envi-

ando dados de potencia de uma planta de producao de energia, mas adicionando

diferentes prioridades para cada estacao DNP3 e incorporando sua atualizacao

de dados no fluxo SDPY.

Internet RedeCliente SPDY Servidor SPDY

Figura 3.4: Esquema do projeto.

A tecnica basica para o esquema do poll de atualizacao, utilizado no DNP3,


permite que o servidor interaja com o cliente retornando imediatamente uma

resposta aos requests periodicos de atualizacao, ou seja, quando ocorrem as al-

teracoes dos dados, enquanto que o cliente mantenha a subscricao. Esta abor-

dagem e descrita na especificacao, mas nao e comum em aplicativos reais devido

ao fato de que nao otimiza o procedimento de notificacao de alteracao de dados

para o cliente. A figura 3.5 mostra a abordagem basica do poll de atualizacao.

Cliente SPDY Servidor SPDY

Request de

Atualização

Cliente SPDY Servidor SPDY

Response do

Servidor

Figura 3.5: Abordagem basica do poll de atualizacao.

Capıtulo 4

Desenvolvimento de umprototipo de servidor SDPY

O desenvolvimento do prototipo de servidor SPDY abrangeu os dois primeiros

objetivos especıficos indicados na secao 1.2. O projeto foi desenvolvido na lingua-

gem de programacao Python e com o uso de bibliotecas externas que dao suporte

ao protocolo SSL, utilizando OpenSSL que adiciona a extensao “Next Protocol

Negotiation” (NPN) [35] para negociar o uso de SPDY sobre uma conexao se-

gura, e tambem para sockets assıncronos, adaptando a biblioteca “asyncore”1

para complementar ao correto funcionamento do escalonador SDPY.

A pesquisa da especificacao do protocolo SPDY e, o estudo dos dois padroes

de projeto e dos cinco algoritmos de escalonamento selecionados, descritos no

capıtulo 3, permitiram atingir o primeiro objetivo especıfico indicado na secao

1.2.

Para o desenvolvimento do prototipo de servidor SPDY, a estrutura do re-

quest/response SPDY esta baseada na especificacao do draft SPDY [5] versao

tres, versao atual suportada por navegadores e servidores que utilizam esta tec-

nologia, e a estrutura do escalonador, nesta primeira versao do prototipo, esta

baseada no padrao de projeto Proactor. A figura 4.1 mostra uma visao geral das

etapas desenvolvidas na primeira versao do servidor SPDY.

1A biblioteca “asyncore” fornece uma infraestrutura basica para desenvolver o gerenciamentode sockets assıncronos, http://docs.python.org/3/library/asyncore.html.

24

http://docs.python.org/3/library/asyncore.html

CAPITULO 4. DESENVOLVIMENTO DE UM PROTOTIPO DE SERVIDOR SDPY25

Cliente SPDY

Criar o Proactor

como base para

o escalonador de

SPDY

Escalonador - Proactor

Envolver o

frame SPDY

e a prioridade

em um evento

Enfileirar o

evento acordo à

prioridade

atribuida

Despachar o

novo frame

SPDY obtido de

gerenciar o

evento

desenfileirado

<< request SPDY>> << response SPDY>>

<< loop >>

Servidor SPDY

Figura 4.1: Visao geral das etapas desenvolvidas no projeto.

Funcionamento do escalonador SPDY A execucao do servidor SPDY con-

templa inicialmente a criacao da instancia do Proactor. Criada a instancia, dois

metodos serao executados: O registro do gerenciador de eventos, que e preciso

para a analise e processamento dos requests HTTP envolvidos nos frames SPDY,

e o inıcio do thread de gerenciamento de eventos, que fica esperando pelo menos

um elemento disponıvel nas filas de prioridade para ser processado pelo gerenci-

ador de eventos.

O processo no escalonador SPDY, baseado em Proactor, compreende tres

etapas para atingir o gerenciamento de requests SPDY: O envolvimento do frame

SPDY recebido e sua prioridade atribuıda em um evento, respeitando a concepcao

do Proactor descrita na subsecao 3.1; o enfileiramento do evento e por ultimo, o

despacho do frame SPDY resultante do gerenciamento do evento desenfileirado.

Enfileiramento do evento O enfileiramento do evento esta baseado na prio-

ridade atribuıda ao frame SPDY, como item de uma das oito filas de prioridade

criadas segundo a especificacao de SPDY [5]. A figura 4.2 mostra o diagrama de

interacao para o enfileiramento de eventos no escalonador SPDY.


Enfileiramento

iniciado

: Servidor

SPDY : Proactor : QueueItem :PriorityQueue

Estabelecer

parâmetros nos

items da fila

Procurar a fila

baseado na

prioridade

Enfileirar o

evento

Enqueue(handleID, event, priority)

:Queue

setHandle(handleID)

setEvent(event)

Enqueue(queueItem, priority)

Enqueue(queueItem)

FindPriorityQueue(priority)

Figura 4.2: Diagrama de interacao para o enfileiramento de eventos.

Despacho do frame SPDY O processo de despacho de um novo frame SPDY,

inicia com o desenfileiramento do evento pronto para gerenciar. A figura 4.3

mostra a dinamica de desenfileiramento utilizada nas oito filas de prioridade do

escalonador SDPY, onde para desenfileirar um evento e necessario cumprir com

a sequencia de prioridade desde a fila de prioridade mais alta ate a mais baixa.

Portanto, comeca a desenfileirar o evento pronto a partir da fila de mais alta

prioridade. Se essa fila estiver vazia, continua-se com a proxima fila de menor

prioridade e assim por diante.

I2

I3

I1

I2I1

I2

I3

I1 I1

I2

I3

I1

I2I1

I4

Fila 0 Fila 1 Fila 2 Fila 3 Fila 4 Fila 5 Fila 6 Fila 7

<< loop >>

I1

Alta

prioridade

Baixa

prioridade

Figura 4.3: Dinamica do desenfileiramento de eventos.

Com o evento desenfileirado, procedemos a tratar seu pedido com a analise

do frame SPDY envolvido. Essa analise compreende principalmente conhecer

qual e o tipo de frame SPDY para poder atender o requerimento. Assim, de


acordo a especificacao do protocolo SPDY, geramos um novo frame SPDY com

a informacao solicitada. A figura 4.4 mostra o diagrama de interacao para o

despacho de eventos no escalonador SPDY.

Desenfileiramento

iniciado

:Proactor:HTTP

Handler: QueueItem:PriorityQueue

Obter os

parâmetros do

item

Procurar o item

pronto e

desenfileirar

da fila

Gerenciar o

evento a

despachar

:Queue

Dequeue()

queueItem

FindQueueItem()

Dequeue()

queueItem

GetEvent()

event

GetHandle()

handleID

HandleEvent(event)

Figura 4.4: Diagrama de interacao para o despacho de eventos.

Gerenciamento assıncrono de sockets O “asyncore” e uma biblioteca que

trabalha com sockets gerenciados de forma assıncrona, seu desenho e baseado em

eventos e e utilizada para desenvolver servidores de rede com requests concorren-

tes. Estas caraterısticas ajudam muito ao desenvolvimento do escalonador SPDY,

mas essa biblioteca nao tem suporte para sockets envolvidos em SSL, e alem disso,

cada socket entrante e tratado na ordem de chegada e fechado imediatamente,

nao podendo se adequar a um esquema de gerenciamento com prioridade. Devido

a esses inconvenientes na biblioteca, foi adicionado um patch de suporte para soc-

kets envolvidos em SSL e foram implementados metodos para o gerenciamento

de erros e fechamento dos sockets.

Capıtulo 5

Resultados

A fim de abranger a avaliacao do tempo de processamento nas filas de prioridade

do escalonador SPDY, foi definido um ambiente de teste usando quatro maquinas

clientes e um servidor para transmitir requests com diferentes prioridades entre 0

e 7. O servidor e as maquinas clientes possuem as seguintes caracterısticas:

Processador RAM Sistema Operacional

Servidor Intel Core i5 3333M, 4 Nucleos de 3.2 GHz 4 GB Ubuntu 12.04, 32 bits

Maquina 1 Intel Core i5 2430M, 4 Nucleos de 2.4 GHz 4 GB Ubuntu 12.04, 64 bits




Tabela 5.1: Caracterısticas do servidor e das maquinas clientes.

Para determinar as faixas de prioridades e os tempos de envio dos requests

transmitidos por cada cliente para o servidor SDPY, foram utilizados quatro

arquivos de teste configurados com a seguinte estrutura: o valor da prioridade e

tempo de inter-arrival em milissegundos.

Arquivos de Teste Tres dos quatro arquivos de teste contem tempos de inter-

arrival de tres dispositivos DNP3 industriais reais chamados de A, F e J, os quais

enviam dados de uma planta de energia para uma central de controle SCADA,

estes tempos de inter-arrival foram obtidos a partir de medicoes ao longo de uma

semana de funcionamento da planta, alem disso, a cada tempo de inter-arrival foi

atribuıdo um valor de prioridade selecionado aleatoriamente das maiores priorida-

des que estao entre 0 e 2. Os dados destes arquivos tem o objetivo de simular uma

28

CAPITULO 5. RESULTADOS 29

situacao real de monitoramento enviando requests simultaneos por cada cliente.

Os tempos de inter-arrival do quarto arquivo ou arquivo de trafego de fundo,

foram criados utilizando uma funcao de distribuicao normal1 com media de 0.039

segundos e desvio padrao de 1.0 em um intervalo de tempo total de 90 horas.

Alem desta grande quantidade de dados de tempo de inter-arrival foi atribuıdo

aleatoriamente a cada tempo um valor de prioridade menor do que os arquivos

A, F e J que esta entre 3 e 7. Os dados deste ultimo arquivo tem o objetivo

de manter cheias as filas de prioridade gerando um efeito de stress no servidor

SPDY. A figura 5.1 mostra a estrutura e alguns dados dos arquivos de teste.

2 4000

0 6000

1 8000

0 4000

2 262000

.

.

.

A

0 8000

0 78000

2 2000

1 26000

0 2000

.

.

.

F

2 8000

1 22000

1 18000

0 4000

1 18000

.

.

.

J

7 614.094

4 109.847

6 1168.76

6 1083.66

3 703.774

.

.

.

Tráfego de Fundo

Figura 5.1: Estrutura dos arquivos de Teste A, F, J e Trafego de Fundo com ovalor da prioridade na primeira coluna e o tempo de inter-arrival na segunda.

Descricao do Teste Apos da execucao do servidor SPDY, cada cliente envia

o primeiro request e o servidor retorna uma response SPDY contendo texto com

sintaxe HTML e JavaScript aos clientes a fim de que possam anexar o arquivo

de teste a seguir. Assim cada cliente vai continuar um trafego principal com

prioridades entre 0 e 2 ou um trafego de fundo com prioridades entre 3 e 7 por

request. O codigo 5.1 mostra a funcao que e utilizada para gerar o conteudo da

response SPDY, esta funcao contem tres parametros e se o primeiro parametro,

que e boolean, e verdadeiro, entao le o conteudo de um arquivo com sintaxe HTML

e JavaScript de geracao do formulario que permite anexar arquivos.

1A funcao normrnd de Matlab gera numeros aleatorios a partir de uma funcao de distribuicaonormal, http://www.mathworks.com/help/stats/normrnd.html.

http://www.mathworks.com/help/stats/normrnd.html


def ge t r e sp proc t ime html (self , f i l e t e s t , t e s t a t t , prev t ime ) :try :

r e sp = ’ ’

if not f i l e t e s t :r e sp = ’<form id =\ ’myform\ ’ method=post> ’ \

’<t a b l e border =\ ’0\ ’> ’ \’<tr><th>Timer:</th> <td><input type =\ ’ t ex t \ ’ ’ \’ id =\ ’ t imer \ ’ va lue=’+t e s t a t t [0 ]+ ’></td></tr> ’\

’<tr><th>Previous Time:</th> <td><input type=’ \’ \ ’ t ex t \ ’ id =\ ’ prev t ime \ ’ va lue=’+prev t ime+’> ’

\’</td></tr> ’ \’<input type =\ ’ hidden \ ’ id =\ ’ curt ime \ ’ va lue=’+\

t e s t a t t [0 ]+ ’> ’ \’<input type =\ ’ hidden \ ’ id =\ ’nrow \ ’ va lue=’+ \t e s t a t t [1 ]+ ’> ’ \’<input type =\ ’ hidden \ ’ id =\ ’ p r i o r i t y \ ’ va lue=’+

\t e s t a t t [2 ]+ ’> ’ \’</tab le> ’ \’</form> ’

else :f = open( ’www/ proct ime a jax . html ’ , ’ rb ’ )re sp = f . read ( ) . decode ( ’UTF−8 ’ )f . c l o s e ( )

return re sp . encode ( ’ ut f−8 ’ )except IOError as e :

raise Exception ( ’ h t tp hand le r − ge t r e sp proc t ime html : ’ \’ I /O e r r o r ({0} ) : {1} ’ .format( e . errno , e . s t r e r r o r ) )

except Exception as e r r :raise Exception ( ’ h t tp hand le r − ge t r e sp proc t ime html : ’ , \e r r )

Codigo 5.1: Geracao do conteudo da response SPDY.

As linhas dos arquivos de teste enviados pelos clientes no proximo grupo

de requests sao armazenados em uma estrutura de dados do servidor a fim de

que possa gerenciar os novos requests ate o final do teste. A response SPDY

para cada request contem texto com sintaxe HTML que inclui tres parametros

preenchidos com o tempo que tem que esperar o cliente SPDY para enviar o

proximo request, a prioridade que vai ter esse request e o ındice do proximo

elemento da estrutura de dados que o servidor tem que obter para atender o


request enviado. Assim, no codigo 5.1, se o primeiro parametro e falso, entao

geramos a sintaxe HTML de um formulario com campos que sao preenchidos com

os valores dos outros parametros da funcao. A figura 5.2 mostra a representacao

dos ultimos procedimentos anteriormente descritos.

Servidor SPDY

A

Máquina 2J

F

Cliente

Máquina 1

Cliente

Máquina 4

Cliente

(a)

Máquina

Servidor SPDY

(b)

Prioridade,

ÍndiceTempo,

Prioridade,

Índice

Cliente

Estrutura de

dados

Máquina 3

Cliente

Tráfego de

Fundo

Figura 5.2: (a) Armazenamento na estrutura de dados. (b) Gerenciamento dosnovos requests.

A medicao do tempo total de processamento2 nas filas de prioridade do escalo-

nador SPDY abrange as funcoes principais de desenfileiramento e gerenciamento

dos requests. Com a obtencao dos dados de tempo, numero de IP do cliente,

prioridade e numero de request no escalonador SPDY foram realizados dois ex-

perimentos preliminares, o registro em um arquivo de resultados dos tempos de

processamento nas filas de prioridade e a geracao de um grafico3 de Tempo de

inter-arrival vs. Numero de Requests.

2A biblioteca “cProfile” de Python mede o tempo total de execucao de uma porcao de codigo,http://docs.python.org/3.3/library/profile.html.

3A biblioteca “‘matplotlib” de Python realiza o plotting 2D e 3D de dados, http://

matplotlib.org/.

http://docs.python.org/3.3/library/profile.html

http://matplotlib.org/

http://matplotlib.org/


5.1 Testes I: Analise do comportamento dos tem-pos de processamento nas oito filas de prio-ridade

Para atingir a analise do comportamento dos tempos de processamento nas filas de

prioridade, foram realizados distintos experimentos gerando graficos de Tempo de

processamento vs. Numero de Requests. As figuras abaixo mostram os resultados

dos testes que foram executados no servidor SDPY em um tempo total medio de

20 minutos.

Testes 1 e 2 Os testes 1 e 2 foram executados utilizando um dos clientes

SPDY para transmitir o trafego de fundo e os outros clientes o trafego principal

dos arquivos A, F e J. O esquema de realizacao destes testes esta representado

na figura 5.3.

Servidor SPDY

A

Máquina 2J

F

Cliente

Máquina 1

Cliente

Máquina 4

Cliente

Máquina 3

Cliente

Tráfego de

Fundo

Figura 5.3: Esquema dos testes 1 e 2.

A figura 5.4 mostra que o Teste 1 realizado em um tempo total de 20 minutos

alcanca um numero de requests de 517 e um tempo de processamento maximo de

0.0367 ms.



0.0392 ms.


Figura 5.4: Plotting 2D do teste 1 utilizando um cliente SPDY para transmitir otrafego de fundo.

Figura 5.5: Plotting 2D do teste 2 utilizando um cliente SPDY para transmitir otrafego de fundo.

Testes 3 e 4 Os testes 3 e 4 foram executados utilizando um cliente SPDY,

distinto ao usado nos testes 1 e 2, para transmitir o trafego de fundo e os outros

clientes o trafego principal dos arquivos A, F e J. O esquema de realizacao destes

testes esta representado na figura 5.6.


Servidor SPDY

A

Máquina 2J F

Cliente

Máquina 1

Cliente

Máquina 4

Cliente

Máquina 3

Cliente

Tráfego de

Fundo


Figura 5.7: Plotting 2D do teste 3 utilizando outro cliente SPDY para transmitiro trafego de fundo.



0.035 ms.

A figura 5.8 mostra que o Teste 4 realizado em um tempo total de 35 mi-

nutos com 46 segundos alcanca um numero de requests de 774 e um tempo de

processamento maximo de 0.038 ms.

Testes 5 e 6 Os testes 5 e 6 foram executados utilizando um cliente SPDY,

distinto ao usado nos anteriores testes, para transmitir o trafego de fundo e os

outros clientes o trafego principal dos arquivos A, F e J. O esquema de realizacao



destes testes esta representado na figura 5.9.

Servidor SPDY

AMáquina 2

J

F

Cliente

Máquina 1

Cliente

Máquina 4

Cliente

Máquina 3

Cliente

Tráfego de

Fundo



e 13 segundos alcanca um numero de requests de 461 e um tempo de processa-

mento maximo de 0.039 ms.






0.04 ms.


5.2 Testes II: Analise e comparacao do compor-tamento dos tempos de processamento emuma fila sem prioridade e nas oito filas deprioridade

Para ter uma melhor visualizacao do comportamento dos tempos de processa-

mento nas filas de prioridade e assim poder observar em quais filas os requests se

processam em menor tempo e em quais se gerenciam mais, foram gerados distintos

graficos em 3D considerando novamente o tempo de processamento e o numero de

request adicionando como terceiro parametro a prioridade ou o numero de cliente

de acordo com a analise.

Nas figuras abaixo serao mostradas dois tipos de analise com o objetivo de

fazer a comparacao visual entre elas, a primeira considera a proposta deste tra-

balho com a adicao das oito filas de prioridade no gerenciamento dos requests no

escalonador SPDY com graficos de Tempo de Processamento vs. Numero de re-

quests vs. Prioridade. A segunda considera somente uma fila de armazenamento

dos requests atribuindo para cada um deles a mesma prioridade com graficos de

Tempo de Processamento vs. Numero de requests vs. Cliente.

Teste 7 As figuras 5.12, 5.13, 5.14 mostram os graficos do experimento que

utilizou os tres arquivos de tempos reais de teste A, F, J e o arquivo de trafego de

fundo. Como resultado se pode observar que nos 20 minutos de execucao do teste

os 126 requests com prioridades entre 0 e 2 sao processados em um tempo medio

de 0.0012 ms e os 378 requests com prioridades entre 3 e 7 sao processados em

um tempo medio de 0.0019 ms alcancando um tempo de processamento maximo

no teste de 0.025 ms.


Figura 5.12: Vista 1: Plotting 3D do teste 7 utilizando oito filas de prioridade.





utilizou quatro arquivos de teste que contem os mesmos dados de tempo do

arquivo de trafego do fundo, atribuindo aleatoriamente para tres deles as maiores

prioridades entre 0 e 2. O objetivo deste experimento e a execucao simultanea

com tempos curtos de envio entre requests para alcancar o mais alto nıvel de

stress no servidor. Como resultado se pode observar que nos 20 minutos de

execucao do teste os 1062 requests com prioridades entre 0 e 2 sao processados

em um tempo medio de 0.002408 ms e os 380 requests com prioridades entre 3 e

7 sao processados em um tempo medio de 0.002416 ms alcancando um tempo de

processamento maximo no teste de 0.063 ms. Alem disso, se pode observar que

com esta grande quantidade de transmissao de dados sao gerenciados com maior

prioridade aqueles requests com prioridades entre 0 e 2.







utilizou novamente nos quatro arquivos de teste os dados de tempo do arquivo de

trafego de fundo com a diferenca que se atribuıram a todos os tempos a mesma

prioridade com valor 0. O objetivo deste experimento e observar o comportamento

dos tempos de processamento em um contexto sıncrono de gerenciamento de

requests e de fazer uma comparacao com a proposta das oito filas de prioridade

no escalonador SPDY. Como resultado se pode observar que nos 20 minutos

de execucao do teste os 1550 requests sao processados em um tempo medio de

0.00246 ms alcancando um tempo de processamento maximo de 0.06 ms.


Figura 5.18: Vista 1: Plotting 3D do teste 9 utilizando uma fila de prioridade.




5.3 Testes III: Analise e comparacao do com-portamento dos tempos de processamentonas oito filas com prioridade e quantum detempo

Tomando em consideracao a caracterıstica principal do algoritmo de escalona-

mento Round-Robin, o quantum descrito nas subsecoes 2.3.1 e 2.3.2, foi atribuıdo

a cada fila de prioridade um tempo maximo de execucao ou quantum com a

finalidade que os requests armazenados nas filas com menor prioridade sejam

processados com maior frequencia e assim se possa controlar mais a inanicao.

Empiricamente foi atribuıdo um quantum a cada fila de prioridade com valores

entre 0.8 a 0.1 segundos nessa ordem, assim a dinamica de desenfileiramento,

descrita no capıtulo 4, foi adicionada um novo controle de tempo de execucao

para cada fila de prioridade. Assim, se esse tempo de execucao fosse maior ao

quantum atribuıdo, entao deixa de gerenciar os demais requests da fila atual

que esta atingindo para continuar com os requests da proxima fila de menor


prioridade, e assim por diante com cada fila de prioridade. A figura 5.21 mostra

a nova dinamica de desenfileiramento para o teste utilizando um quantum de

tempo para cada fila de prioridade.

I2

I3

I1

I2I1

Fila 0 Fila 1 Fila 2 Fila 7

<< loop >>

I1

Alta

prioridade

Baixa

prioridade

q= 0.8 sec q= 0.7 sec q= 0.6 sec q= 0.1 sec

...

Figura 5.21: Nova dinamica de desenfileiramento para o teste.

As figuras abaixo mostram os graficos de dois experimentos realizados com

quatro arquivos de teste que contem os mesmos dados de tempo que do arquivo de

trafego de fundo onde dois deles tem atribuıdos aleatoriamente para cada tempo

as maiores prioridades entre 0 e 2 e os outros dois tem atribuıdos aleatoriamente

prioridades entre 3 e 7, com o objetivo de realizar uma comparacao entre estes

experimentos.

Teste 10 As figuras 5.22, 5.23 mostram os graficos do experimento realizado

com o mesmo gerenciamento sobre as oito filas de prioridade descritos no primeiro

experimento da secao 5.2 em um tempo total de 20 minutos, onde o escalona-

dor SDPY alcanca gerenciar 759 requests nas filas de maior prioridade com um

tempo medio de processamento de 0.002304 ms, 480 requests nas filas de menor

prioridade com um tempo medio de processamento de 0.002388 ms e um maximo

tempo de processamento entre os requests de 0.064 ms.





Teste 11 As figuras 5.24, 5.25 mostram os graficos do experimento realizado

com o quantum de tempo para cada fila de prioridade, descrito nesta secao, em

um tempo total de 20 minutos, onde o escalonador SDPY alcanca gerenciar 740

requests nas filas de maior prioridade com um tempo medio de processamento de

0.002836 ms, 541 requests nas filas de menor prioridade com um tempo medio de

processamento de 0.002945 ms e um maximo tempo de processamento entre os

requests de 0.084 ms. Como se pode observar nos dois experimentos realizados

com os mesmos arquivos de teste, a utilizacao de um quantum para cada fila de

prioridade permite gerenciar mais requests das filas de menor prioridade.

Figura 5.24: Vista 1: Plotting 3D do teste 11 utilizando um quantum para cadafila de prioridade.


Figura 5.25: Vista 2: Plotting 3D do teste 11 utilizando um quantum para cadafila de prioridade.

Em resumo as tabelas 5.2 e 5.3 contem os resultados dos testes descritos nas

secoes 5.2 e 5.3:

Prioridades N. Requests Tempo Medio de Proc. Tempo Max. de Proc.

Teste 7 0 - 2 126 0.0012 ms

3 - 7 378 0.0019 ms 0.025 ms

Teste 8 0 - 2 1062 0.002408 ms

3 - 7 380 0.002416 ms 0.063 ms

Teste 9 1550 0.00246 ms 0.06 ms

Tabela 5.2: Resultados dos Testes 7, 8 e 9.

Prioridades N. Requests Tempo Medio de Proc. Tempo Max. de Proc.

Teste 10 0 - 2 759 0.002304 ms

3 - 7 480 0.002388 ms 0.064 ms

Teste 11 0 - 2 740 0.002836 ms

3 - 7 541 0.002945 ms 0.084 ms

Tabela 5.3: Resultados dos Testes 10 e 11.

Capıtulo 6

Conclusoes

O Proactor, como padrao projetado para aplicativos orientados a evento que

recebem e processam multiplos eventos de forma assıncrona, se adequa as ca-

racterısticas requeridas no escalonador SPDY permitindo a concorrencia e otimo

gerenciamento dos requests transmitidos pelos clientes SDPY.

A inclusao de oito filas de prioridade no escalonador SPDY ajuda a alcancar no

Proactor o conceito de mecanismo assıncrono, alem de que obedece a priorizacao

dos requests como uma das melhorias de SPDY sobre HTTP. Os testes baseados,

em grande parte nesta funcionalidade do escalonador SPDY e descritos na secao

5.2, demonstram que os requests com maior prioridade sao processados na media

em menor tempo alem de que sao gerenciados em maior quantidade, ao contrario

dos requests com menor prioridade que sao gerenciados em menor quantidade

alcancando tempos de processamento maximos em alguns requests e na media

maior tempo de processamento.

A atribuicao de um quantum, como caracterıstica principal do algoritmo de

escalonamento Round-Robin, ou tempo de execucao para cada fila de prioridade,

descrito na secao 5.3, melhorou o gerenciamento dos requests armazenados em

todas as filas de prioridade, prevenindo a execucao indefinida dos requests com

maior prioridade e aumentando a quantidade de requests gerenciados com menor

prioridade.

Este trabalho demonstrou que se alcancamos simular uma situacao real com

o envio de dados gerados por dispositivos industriais de uma planta de energia,

48

CAPITULO 6. CONCLUSOES 49

tomando em consideracao o otimo funcionamento do escalonador SDPY, entao

os aplicativos de monitoramento poderiam adotar as caracterısticas do protocolo

SPDY para melhorar o desempenho atual da tecnica de atualizacao de dados

descrita na secao 3.2.

Referencias Bibliograficas

[1] T. Berners-Lee, R. Fielding, and H. Frystyk. Hypertext Transfer Protocol –

HTTP/1.0. http://www.ietf.org/rfc/rfc1945.txt, May 1996.

[2] R. Fielding, J. Gettys, J. Mogul, H. Frystyk, L. Masinter, P. Le-

ach, and T. Berners-Lee. Hypertext Transfer Protocol – HTTP/1.1.

http://www.ietf.org/rfc/rfc2616.txt, June 1999.

[3] J.F. Kurose and K.W. Ross. Computer Networking: A Top-Down Approach.

Addison-Wesley, 2010.

[4] Ilya Grigorik. Optimizing HTTP: Keep-alive and Pipelining.

http://www.igvita.com/2011/10/04/optimizing-http-keep-alive-and-

pipelining, Oct. 2011.

[5] R. Peon M. Belshe. SPDY Protocol. http://tools.ietf.org/html/draft-

mbelshe-httpbis-spdy-00, Feb. 2012.

[6] Modbus Organization. Modbus Application Protocol Specification v1.1b3.

http://www.modbus.org/docs/Modbus Application Protocol V1 1b3.pdf,

April 2012.

[7] IEEE Draft Standard for Electric Power Systems Communications -

Distributed Network Protocol (DNP3). IEEE P1815/D08, January 2012,

pages 1–858, Feb 2012.

[8] OPC Foundation. OPC XML-DA Specification.

http://www.opcfoundation.org/, July 2003.

50

REFERENCIAS BIBLIOGRAFICAS 51

[9] OPC Foundation. OPC Unified Architecture.

http://www.opcfoundation.org/UA.

[10] N.M. Torrisi. Cyberopc. http://www.cyberopc.org.

[11] N.M. Torrisi. Monitoring Services for Industrial. Industrial Electronics Ma-

gazine, IEEE, 5(1):49 –60, March 2011.

[12] Jan Newmarch. Introduction to stream control transmission protocol. Linux

J., (161):7, Sep. 2007.

[13] P. Natarajan, P. Amer, J. Leighton, and F. Baker. SCTP for HTTP.

http://tools.ietf.org/html/draft-natarajan-http-over-sctp-02, July 2009.

[14] Bryan F. Structured Stream Transport. http://pdos.csail.mit.edu/uia/sst,

March 2007.

[15] W3C HTTP-NG project. MUX Overview.

http://www.w3.org/Protocols/MUX, Dec. 2000.

[16] Shishir G. CGI Programming on the World Wide Web.

http://oreilly.com/openbook/cgi/ch06 06.html, March 1996.

[17] P. McCarthy and D. Crane. Comet and Reverse Ajax: The Next-Generation

Ajax 2.0. Apresspod Series. Apress, 2008.

[18] Mathieu Carbou. Reverse Ajax, Part 1: Introduction to Co-

met. http://www.ibm.com/developerworks/web/library/wa-reverseajax1,

July 2011.

[19] Alex R., Greg W., David D., and Mark N. Bayeux Protocol – Bayeux 1.0.0.

http://svn.cometd.com/trunk/bayeux/bayeux.html, 2007.

[20] XMPP Standards Foundation. XMPP Technologies: BOSH.

http://xmpp.org/about-xmpp/technology-overview/bosh.


[21] IETF. Hypertext Transfer Protocol Bis (httpbis).

https://datatracker.ietf.org/wg/httpbis/charter/, 2012.

[22] World Wide Web Consortium. W3C. http://www.w3.org.

[23] Ilya Grigorik. Ruby & Websockets: TCP for the Browser.

http://www.igvita.com/2009/12/22/ruby-websockets-tcp-for-the-browser,

Dec. 2011.

[24] A. Melnikov I. Fette. The Websocket Protocol.

http://tools.ietf.org/html/rfc6455, Dec. 2011.

[25] Mark A. Greg R., Jean-loup G. zlib. http://zlib.net/, July 2012.

[26] Fan Y., Paul A., Jonathan L., and Mike B. A methodology to derive SPDY’s

initial dictionary for zlib compression.

[27] J. Heidemann, K. Obraczka, and J. Touch. Modeling the performance of

HTTP over several transport protocols. Networking, IEEE/ACM Transac-

tions on, 5(5):616–630, 1997.

[28] Andrew S. Tanenbaum. Modern Operating Systems. Prentice Hall PTR,

2001.

[29] Chuck Semeria. Supporting Differentiated Service Classes: Queue Scheduling

Disciplines. Juniper Networks, 2001.

[30] Abraham S., Peter B. G., and Greg G. Operating Systems Concepts. JOHN

WILEY & SONS. INC, 2005.

[31] Ioannou, Aggelos, Katevenis, and Manolis G. H. Pipelined heap (priority

queue) management for advanced scheduling in high-speed networks. IEE-

E/ACM Trans. Netw., 15(2):450–461, Apr. 2007.


[32] U. Praphamontripong, S. Gokhale, A. Gokhale, and J. Gray. Performance

Analysis of an Asynchronous Web Server. In Computer SW and App. Conf.,

COMPSAC ’06. 30th Annual Int., volume 2, pages 22–28, Sept. 2006.

[33] Douglas C. S. Reactor – An Object Behavioral Pattern for Concurrent Event

Demultiplexing and event handler dispatching, 1995.

[34] Douglas C. S. James Hu, Irfan P. Applying The Proactor Pattern to High-

Performance Web Servers. In Proceedings of the 10th Int. Conf. on Parallel

and Distributed Computing and Systems, 1998.

[35] A. Langley. Transport Layer Security (TLS) Next Protocol Negotiation Ex-

tension. draft-agl-tls-nextprotoneg-03, April 2012.