Ambiente de Testes

8/2/2019 Ambiente de Testes

1/99

UNIVERSIDADE SO FRANCISCOEngenharia de Computao

BRUNO GALASSO MOLINARI

IMPLEMENTAO DE AMBIENTE DE TESTESAUTOMATIZADOS PARA AVALIAO DE PARMETROS

DE QoS EM REDES DE COMUNICAO DE DADOSBASEADO EM SOFTWARE LIVRE

Itatiba2010


2/99

BRUNO GALASSO MOLINARIRA 002200600186

IMPLEMENTAO DE AMBIENTE DE TESTESAUTOMATIZADOS PARA AVALIAO DE PARMETROS

DE QoS EM REDES DE COMUNICAO DE DADOSBASEADO EM SOFTWARE LIVRE

Monografia apresentada ao Curso deEngenharia de Computao daUniversidade So Francisco, como requisitoparcial para obteno do ttulo de Bacharelem Engenharia de Computao.

Orientador: Prof. Marcelo AugustoGonalves Bardi

Itatiba2010


3/99

AGRADECIMENTOS

Agradeo primeiramente aos meus pais, Ismael e Solange, que me deram o apoio

necessrio durante toda esta minha trajetria, ajudando a alcanar meus objetivos.

minha namorada Mariana, pela pacincia, incentivo e carinho.

Ao meu orientador Prof. Marcelo Agusto Gonalves Bardi cujo auxlio e cobranas

foram fundamentais para a realizao desse trabalho.

Ao meu chefe e amigo Tadeu, pelo apoio e compreenso durante esse perodo.

Ao meu colega de trabalho e amigo Wallace, por ter me incentivado a ingressar na rea

de engenharia. FTD Comunicao de Dados Ltda. pelo apoio durante a faculdade e emprstimo dos

equipamentos utilizados para realizao dos testes deste trabalho.

Enfim, a todos que me apoiaram neste momento da minha vida. Obrigado.


4/99

RESUMO

Nos ltimos anos, houve um crescimento em aplicaes de rede que utilizam recursosmultimdia, como vdeo em tempo real, VoIP, videoconferncia, telemedicina e muitas outras.Essas aplicaes normalmente exigem que a rede por onde trafegam possuam parmetros dequalidade de servio (QoS) bem definidos, o que requer que muitas instalaes econfiguraes de rede atualmente sejam realizadas visando obter esta garantia de qualidadepara alguns servios. Dessa forma, este trabalho objetiva desenvolver um ambiente paratestar, de forma automatizada, se a configurao de uma determinada rede est de acordo comos parmetros exigidos pelas aplicaes conforme as informaes fornecidas pelo usurio.Todo o desenvolvimento do sistema foi realizado utilizando-se como base o sistemaoperacional Linux e softwares como ping, iperf, apache, PHP e MySQL. Atravs de umainterface WEB o usurio informa os parmetros de qualidade da rede que deseja avaliar. Aps

a confirmao do usurio o sistema configura automaticamente todos os softwares envolvidose realiza o teste em segundo plano, durante o tempo determinado pelo usurio. Ao final doteste o sistema avalia as informaes obtidas e informa os resultados ao usurio atravs detabelas, grficos e observaes sobre as condies encontradas. A partir dessas informaes possvel saber se a rede est configurada corretamente ou se so necessrias alteraes em suaconfigurao.

Palavras-chave: parmetros de QoS. redes de computadores. testes.


5/99

ABSTRACT

In recent years, has been a growth in network applications that use multimedia resources likereal time video, VoIP (Voice over IP), video conference, telemedicine and many more. Theseapplications typically require of the network through where passing have parameters ofquality of service (QoS) well defined, what requires that many installations and networkconfigurations currently being performed to obtain this guarantee of quality for some services.Thus, this work have the objective to develop an environment for testing, an automated way,if the configuration of a network is in according to the parameters required by theapplications, based in information provided by user. All development of the system wasperformed using as a base the Linux operating system and software such as ping, iperf,Apache, PHP and MySQL. Through a Web interface, the user informs the quality parametersof the network that want to evaluate. After user's confirming, the system automatically

configures all the software involved and conducts a test in the background during the time setby user. At the end of the test, the system evaluates the information obtained and reports theresults to the user through tables, graphs and comments on the conditions found. From thisinformation it is possible to know if the network is configured correctly or if changes arerequired in your configuration.

Keywords: QoS parameters. computer networks. tests.


6/99

LISTA DE FIGURAS

FIGURA 1 - Camadas TCP/IP ................................................................................................. 15FIGURA 2 - Diagrama geral dos casos de uso ......................................................................... 35FIGURA 3 - Diagrama de seqncia de um teste completo ..................................................... 37FIGURA 4 - Diagrama de classes............................................................................................. 38FIGURA 5 - Estrutura de dados ............................................................................................... 39FIGURA 6 - Diagrama do laboratrio de teste ......................................................................... 40FIGURA 7 - Laboratrio de testes viso geral ......................................................................... 43FIGURA 8 - Laboratrio de testes roteadores .......................................................................... 43FIGURA 9 - Grfico de atraso no teste 3 do cenrio 2............................................................. 45FIGURA 10 - Grfico de atraso no teste 2 do cenrio 2........................................................... 45FIGURA 11 - Grfico de atraso no teste 1 do cenrio 3 ........................................................... 47FIGURA 12 - Grfico de atraso no teste 2 do cenrio 3........................................................... 47


7/99

LISTA DE TABELAS

TABELA 1 - Classes de servioITU-T.................................................................................... 21TABELA 2 - Classes de servio e limites mximos ................................................................. 22TABELA 3 - Configuraes dos fluxos de dados no cenrio 1 ................................................ 41TABELA 4 - Configuraes dos fluxos de dados no cenrio 2 ................................................ 41TABELA 5 - Configuraes dos fluxos de dados no cenrio 3 ................................................ 42TABELA 6 - Resultados esperados nos testes no cenrio 1 ..................................................... 44 TABELA 7 - Resultados dos testes no cenrio 1 ...................................................................... 44TABELA 8 - Resultados esperados nos testes no cenrio 2 ..................................................... 45 TABELA 9 - Resultados dos testes no cenrio 2 ...................................................................... 46TABELA 10 - Resultados esperados nos testes no cenrio 3 ................................................... 47 TABELA 11 - Resultados dos testes no cenrio 3 .................................................................... 48


8/99

LISTA DE ABREVIATURAS E SIGLAS

AFAssured Forwarding

BTCBulk Transport Capacity

Diffserv - Differentiated Service

DS Differentiated Service

DSCP - Diffserv code point

EFExpedited Forwarding

FIFO First In, First Out

IETFInternet Engineering Task ForceIntserv Integrated Services

IPInternet Protocol

IPDVIP Delay Variation

IPERIP Packet Errored Ratio

IPLRIP Packet Loss Ratio

IPTDIP Transfer Delay

IPPMIP Performance Metrics

ISOInternational Organization for Standardization

ITUInternational Telecommunication Union

ITU-TITU Telecommunication Standardization Sector

OWDOne-Way Delay

PHBPer-Hop Behaviors

PHPHypertext Preprocessor

QoSQuality of Service

RFCRequest for Comments

RSVPResource Reservation Protocol

RTDRound Trip Delay

RTTRound Trip Time

SLAService Level Agreements

TCPTransmission Control Protocol

TOSType of Service

UDPUser Datagram Protocol

UMLUnified Modeling Language


9/99

UTCCoordinated Universal Time

VOIPVoice over IP

WFQWeighted Far Queue


10/99

SUMRIO

1 INTRODUO ................................................................................................................... 121.1 OBJETIVOS ....................................................................................................................... 131.2 ORGANIZAO DO TRABALHO ................................................................................. 132 ASPECTOS TERICOS .................................................................................................... 152.1 ARQUITETURA INTERNETE TCP/IP............................................................................ 152.2 QUALIDADE DE SERVIO ............................................................................................ 162.2.1 Parmetros de QoS .......................................................................................................... 172.2.1.1 Confiabilidade .............................................................................................................. 172.2.1.2Delay............................................................................................................................. 182.2.1.3Jitter.............................................................................................................................. 192.2.1.4 Throughput................................................................................................................... 202.2.1.5 Classes de Servio ........................................................................................................ 212.2.2 Tcnicas para Alcanar Qualidade de Servio ................................................................ 222.2.2.1 Superdimensionamento ................................................................................................ 222.2.2.2 Armazenamento emBuffers.......................................................................................... 232.2.2.3 Modelagem de Trfego ................................................................................................. 232.2.2.4 Mecanismos de Escalonamento .................................................................................... 242.2.2.4.1 FIFO .......................................................................................................................... 242.2.2.4.2 Prioridade .................................................................................................................. 252.2.2.4.3 Varredura Cclica ....................................................................................................... 252.2.2.4.4 WFQ .......................................................................................................................... 252.2.2.5 Mecanismos de Regulao ........................................................................................... 262.2.2.5.1 Algoritmo de Balde Furado ....................................................................................... 262.2.2.5.2 Algoritmo de Balde de Smbolos ............................................................................... 27


11/99

2.2.3 Servios Integrados e Servios Diferenciados ................................................................ 272.2.3.1 Servios Integrados ...................................................................................................... 27

2.2.3.2 Servios Diferenciados ................................................................................................. 28

2.2.3.3Intserv XDiffserv ......................................................................................................... 292.2.4 Utilizao de QoS em redes ............................................................................................. 303 METODOLOGIA ................................................................................................................ 323.1 FERRAMENTAS ............................................................................................................... 323.2 DESENVOLVIMENTO ..................................................................................................... 333.3 REQUISITOS ..................................................................................................................... 343.4 CASOS DE USO ................................................................................................................ 353.4.1 Iniciar Teste Lado Mestre ................................................................................................ 353.4.2 Iniciar Teste Lado Escravo .............................................................................................. 363.4.3 Iniciar Testes Anteriores .................................................................................................. 363.5 DIAGRAMAS DE SEQNCIA ...................................................................................... 363.6 DIAGRAMA DE CLASSES .............................................................................................. 383.7 MODELAGEM DE DADOS ............................................................................................. 383.8 METODOLOGIA DE TESTES ......................................................................................... 393.9 LABORATRIO DE TESTES .......................................................................................... 403.10 CENRIOS DE TESTES ................................................................................................. 403.10.1 Cenrio 1 ....................................................................................................................... 403.10.2 Cenrio 2 ....................................................................................................................... 413.10.3 Cenrio 3 ....................................................................................................................... 413.11 REALIZAO DOS TESTES ......................................................................................... 424 RESULTADOS E DISCUSSES ....................................................................................... 444.1 RESULTADOS NO CENRIO 1 ...................................................................................... 444.2 RESULTADOS NO CENRIO 2 ...................................................................................... 454.3 RESULTADOS NO CENRIO 3 ...................................................................................... 46


12/99

4.4 CONSIDERAES SOBRE OS RESULTADOS ............................................................. 485 CONCLUSO ...................................................................................................................... 50

5.1 EXTENSES ..................................................................................................................... 50

REFERNCIAS ..................................................................................................................... 52REFERNCIAS CONSULTADAS ....................................................................................... 54APNDICES ........................................................................................................................... 55APNDICE ASHELL SCRIPTPARA TRATAMENTO DOS DADOS GERADOS

PELOIPERF: APAGARESUMO.SH .................................................................................. 56

APNDICE B

SHELL SCRIPTPARA TRATAMENTO DOS DADOS GERADOSPELOPING: PINGS.SH ........................................................................................................ 57APNDICE CAGENTE ESCRAVO: SERVIDOR.PHP ................................................ 58APNDICE DSCRIPTPHP PARA ARMAZENAR DADOS DO TESTE E FLUXO

NA BASE DE DADOS E INICIALIZAR O AGENTE MESTRE: SALVAR_TESTE.PHP

.................................................................................................................................................. 61APNDICE EAGENTE MESTRE: CLIENTE.PHP ...................................................... 63APNDICE FSCRIPT PHP PARA GERAR GRAFICOS: GERA_GRAFICO.PHP .. 67APNDICE GPAGINAPHP COM OS RESULTADOS E GRFICOS DO TESTE:

RESULTADOS_TESTE.PHP ................................................................................................ 72APNDICE HRESULTADOS COMPLETOS DO LABORATRIO DE TESTES ... 75APNDICE I EXEMPLOS DE TELAS DE EXECUO DO SISTEMA ................... 91APNDICE J CONFIGURAES DOS ROTEADORES ............................................ 95


13/99

12

1 INTRODUO

Nos ltimos anos, houve um crescimento em aplicaes de rede que utilizam recursos

multimdia, como vdeo em tempo real, VoIP , videoconferncia, telemedicina e muitas outras.

Essas aplicaes normalmente tm como caracterstica uma taxa de transmisso de dados

constante e as comunicaes ocorrem utilizando-se da infra-estrutura da Internet. Entretanto,

em particular as aplicaes de multimdia, so muito sensveis ao atraso fim-a-fim e a

variao do atraso, mas podem tolerar perdas de dados ocasionais [1].

O modelo da Internet trabalha com o sistema de melhor esforo, compartilhando a

largura de banda entre todos os servios. Com a implantao de qualidade de servio ( QoS)em uma rede, por outro lado, possvel que aplicaes de multimdia e de tempo real tenham

um bom desempenho e funcionem de forma adequada.

Com o aumento da utilizao dessas tecnologias que requerem cada vez mais

qualidade de servio, muitas empresas esto instalando em suas redes equipamentos com

capacidade de prover essa qualidade de servio, sendo necessrias ferramentas para testar e

verificar se os equipamentos instalados e as configuraes realizadas esto funcionando da

maneira correta.Para a realizao de testes de QoS so necessrios equipamentos especficos e

normalmente com custo elevado, como os equipamentos OneTouch SeriesIINetwork

Assistant[2] da empresa Fluke Networks [3] ou o SmartClass Ethernet[4] da empresaJDSU

[5], que so a linha bsica de equipamentos de testes desses fabricantes e realizam testes com

somente um fluxo de dados, sendo assim no permitem testar os parmetros de QoS de forma

completa, apenas de um fluxo, no o comportamento com diferentes fluxos, e j apresentam

custos elevados. J equipamentos capazes de realizar testes com vrios fluxos de forma

simultnea como o EtherScope Series II Network Assistant [6] da fabricante Fluke

Networks ou a srie T-BERD/MTS [7] daJDSU, possuem um custo muito maior, muitas vezes

inviveis para algumas empresas.

Uma alternativa para realizao desses tipos de teste a utilizao de vrios

computadores para gerar fluxos diferentes e coletar dados manualmente para criar e formatar

relatrios com os resultados dos testes. Normalmente, os testes so realizados utilizando a

ferramenta iperf para gerar os fluxos de dados em computadores diferentes. Como uma

ferramenta que no possui interface grfica e somente funciona em modo texto, necessrio

aps a sua execuo copiar a sada de dados no prompt e format-los para uma melhor


14/99

13

apresentao.

Em alguns casos so utilizados vrios fluxos em um mesmo computador, sendo

necessrio inserir as marcas de QoS para distinguir os fluxos; o iperf capaz de realizar essa

tarefa. Porm, uma desvantagem nesse tipo de testes que alm de exigir vrios

computadores, necessrio realizar diversas configuraes, executar vrios comandos em

modo texto e criar o relatrio manualmente atravs da captura dos dados nos diversos

computadores utilizados.

Nesse contexto, uma ferramenta baseada em software livre que realize o teste e gere

relatrios de forma automatizada, aliada a no necessidade de vrios computadores, traria

uma maior agilidade e reduo nos custos desses procedimentos.

1.1 Objetivos

Este trabalho tem por objetivo implementar um ambiente de testes automatizados para

avaliar parmetros de QoS em redes de comunicao de dados, utilizando ferramentas

baseadas em software livre. Os parmetros avaliados sero atraso, variao de atraso, perda depacotes e garantia de banda.

1.2 Organizao do Trabalho

Primeiramente ser apresentada, na seo de Aspectos Tericos, a fundamentao

terica sobre qualidade de servio em redes e telecomunicaes, incluindo seus parmetros

principais, tcnicas para prov-la em redes, uma anlise sobre as principais arquiteturas e

como a qualidade de servio est sendo implantada e utilizada atualmente.

Em seguida, a seo de Metodologia apresenta as ferramentas e a metodologia

utilizada no desenvolvimento dos softwares que compem o sistema, alm da documentao

do sistema segundo a abordagem UML.

Na seo de Testes e Resultados sero detalhados os cenrios de testes e a realizao

dos mesmos. Tambm sero mostrados os resultados obtidos e uma anlise sobre eles.Por fim, as Concluses apresentam os objetivos alcanados, o que pde ser aprendido


15/99

14

durante o desenvolvimento e quais as principais contribuies desse projeto.


16/99

15

2 ASPECTOS TERICOS

Esse captulo apresenta a fundamentao terica para o desenvolvimento do sistema e

anlise dos seus resultados.

2.1 ArquiteturaInternet e TCP/IP

O modelo de referncia TCP/IP utilizado como base para aInternet. um modelo dequatro camadas sendo elas: Fsica/Enlace, Rede, Transporte e Aplicao. A Figura 1 apresenta

um diagrama que representa as quatro camadas TCP/IP.

FIGURA 1 - Camadas TCP/IP

Os protocolos daInternetso uma sute de protocolos, onde os mais conhecidos so o

TCP e oIP, que devido a sua popularidade deram o nome ao modelo de referncia daInternet.

Essa sute de protocolos inclui, alm do TCP/IP, muitos outros protocolos divididos nas trscamadas superiores do modelo de referncia TCP/IP [8].


17/99

16

A camada de rede da Internet fornece um nico modelo de servio conhecido como

servio de melhor esforo. Com o servio de melhor esforo, no h garantia de que a

temporizao entre pacotes seja preservada, no h garantias de que os pacotes sejam

recebidos na ordem que foram enviados e no h garantia da eventual entrega dos pacotes

transmitidos [1].

Ainda, o servio de melhor esforo compartilha a largura de banda entre todos os

servios, os pacotes so encaminhados da melhor forma possvel e quando h

congestionamento, os pacotes so descartados sem distino.

2.2 Qualidade de Servio

Segundo Oodan et al. [9], qualidade pode ser definida e expressada em termos de

parmetros que indicam benefcios para o usurio. Esses parmetros podem ser expressos de

forma quantitativa ou qualitativa. Um conjunto de critrios de qualidade que contm os

benefcios de um produto ou servio para o usurio.

AISOdefine qualidade na norma ISO 8402 como A totalidade das caractersticas de

uma entidade que lhe conferem a capacidade de satisfazer necessidades explcitas e

implcitas [10].

A ITU define Qualidade de Servio (QoS) na recomendao E.800, como sendo o

efeito coletivo provocado pelas caractersticas de desempenho de um servio, determinando o

grau de satisfao do usurio do servio [11].

AIETFconsidera como QoS a capacidade de segmentar o trfego ou de diferenciar

tipos de trfego para que a rede trate esses fluxos de forma diferente dos outros. Assim, QoS

engloba tanto a qualificao do servio quanto o desempenho global da rede para cada

categoria. Do ponto de vista da rede, QoS a habilidade de um elemento de rede (por

exemplo, uma aplicao, host ou roteador) de ter diferentes nveis de garantia para que o

requisitos de trfego e servio possam ser satisfeitos, gerenciando a banda de acordo com a

demanda dos servios e das configuraes da rede [12].

A implantao de qualidade de servio (QoS) em uma rede, baseada na arquitetura da

Internet, o que permite que aplicaes de multimdia e de tempo real tenham um bom

desempenho e funcionem de forma adequada. Com o uso de QoS, os pacotes so marcados

para distinguir os tipos de servios e os roteadores so configurados para criar filas distintas


18/99

17

para cada aplicao, de acordo com as prioridades das mesmas. Assim, uma faixa da largura

de banda reservada e, no caso de congestionamento, determinados tipos de fluxos de dados

ou aplicaes tm prioridade na entrega.

A qualidade de servio medida fim-a-fim. Mesmo que a rede seja formada por vrios

elementos, o desempenho individual de cada elemento no levado em considerao na

anlise da qualidade de um servio. A QoS especfica para cada servio e expressa por um

conjunto nico de parmetros [12].

2.2.1 Parmetros de QoS

Em uma rede IP, uma seqncia de pacotes, desde uma origem at um destino,

chamada de fluxo. As necessidades de cada fluxo podem ser caracterizadas por quatro

parmetros principais: confiabilidade (perda de pacotes), atraso fim-a-fim (delay), variao do

atraso (jitter) e largura de banda (throughput). Juntos esses parmetros definem a QoS que o

fluxo exige [13].

Atualmente existem dois grupos de trabalhos principais trabalhando na definio depadres de mtricas para medio de Qualidade de Servio em redes IP, a IPPMe a ITU-T

[14].

AIPPM parte daIETF, e sua tarefa desenvolver critrios slidos para definir todos

os conceitos relacionados mtricas de desempenho. Seu foco no desenvolvimento de

padres de mtricas que possam ser aplicados em medies de qualidade, desempenho e

confiabilidade de comunicaes na Internet. J a ITU-T usa uma abordagem mais terica e

genrica [14].

2.2.1.1 Confiabilidade

Segundo Tanenbaum [13], a confiabilidade em redes IP est relacionada capacidade

da mesma em entregar os pacotes transmitidos sem erros e sua medida a quantidade de

pacotes perdidos ou com erro. A quantidade de pacotes perdidos pode ser obtida atravs dacomparao do nmero de pacotes transmitidos pela origem com o nmero de pacotes


19/99

18

recebidos no destino, sendo o ideal que no existam perdas de pacotes, mas isso nem sempre

possvel. Nenhum bit de um pacote pode ser entregue de forma incorreta. Em geral, esse

objetivo alcanado calculando-se o total de verificao de cada pacote na origem e

conferindo-se o total de verificao no destino [13].

Segundo Kurose e Ross [1], em uma rede vrios fatores podem contribuir para que um

pacote no seja entregue ou faa com que ele seja descartado: um erro no roteamento pode

levar o pacote a um destino errado ou no encontrar o destino correto; a queda de um enlace

durante a transmisso do pacote ou o excesso de trfego em um roteador pode lotar os seus

buffers de sada, causando o descarte do pacote.

Diferentes tipos de aplicaes podem ser mais ou menos tolerantes a falhas.

Aplicaes de multimdia como, por exemplo, VOIP, dependendo da forma como a voz codificada e de como a perda tratada no receptor, capaz de funcionar com taxas de at

20% de perda de pacotes [1]. J aplicaes como correio eletrnico ou transferncia de

arquivos no podem ter fragmentos das informaes perdidas [13].

De acordo com Kurose e Ross [1], vemos que a perda de pacotes pode ser contornada

utilizando-se o protocolo TCP, pois o mesmo realiza a retransmisso dos pacotes perdidos,

mas essa retransmisso aumenta o atraso fim-a-fim, o que no pode ser aceitvel em alguns

tipos de aplicaes, por exemplo, videoconferncia.A perda de pacotes sempre analisada em uma direo, pois o trfego em redes IP

pode ser assimtrico, isto , o caminho de resposta nem sempre o mesmo do de envio, e

porque algumas aplicaes de tempo real e UDP so unidirecionais [14].

Enquanto a IPPM considera pacotes perdidos e pacotes com erro como uma nica

mtrica, aITU-Tdefine a mtricaIP Packet Loss Ratio para os pacotes perdidos e aIP Packet

Errored Ratio para pacotes com erro [14].

2.2.1.2Delay

Delay, ou atraso fim-a-fim, o acmulo de atrasos de processamento, atrasos de

transmisso, atraso de filas, atraso de propagao nos enlaces e atrasos de processamento em

sistemas finais [1].

Segundo Braun et al. [14], podemos considerar dois tipos de atraso:

One-Way Delay, representa o atraso em uma nica direo, isto , do host de


20/99

19

origem ao hostde destino, o tempo que se passa desde que o primeiro bitdeixa a

origem at que o ltimo bit chegue ao destino. Um problema crtico nessa

abordagem que ambos os hosts, destino e origem, precisam estar com os relgios

sincronizados com preciso, utilizando, por exemplo, uma fonte de tempo UTCe

nem sempre isso possvel [14];

Round-Trip Delay, que a soma do atraso nas duas direes, do envio do pacote

da origem ao destino e a reposta na direo contraria. Utiliza as marcas de tempo

na origem e obtido atravs da diferena entre o tempo de envio e o tempo de

resposta [14]. Como no necessita de sincronismo de tempo entre os hosts, mais

fcil de ser medido. Muitas aplicaes realizam esse tipo de medio, por

exemplo, a ferramenta ping. Essa mtrica tambm conhecida como Round Trip

Time.

O atraso uma mtrica muito importante, pois descreve o grau de interatividade e a

demora de uma comunicao [14]. Por exemplo, para aplicaes de udio altamente

interativas, como o telefone por Internet, atrasos fim-a-fim menores do que 150 ms no so

percebidos pelo ouvido humano; atrasos entre 150 ms e 400 ms podem ser aceitveis, mas no

so o ideal, e atraso que excedem 400 ms podem atrapalhar seriamente a interatividade [1].

J aplicaes no interativas, como transferncia de arquivos e correio eletrnico, noso sensveis ao atraso. Se todos os pacotes estiverem uniformemente atrasados alguns

segundos, no haver nenhum dano [13].

AIPPMutiliza as duas mtricas, OWD eRTD, j aITU-Tdefine apenas a mtricaIP

Transfer Delay com as mesmas caractersticas da mtrica One-Way Delay [14].

2.2.1.3Jitter

A variao de atraso nos tempos de chegada de pacotes chamada de jitter [4].

Variao de atraso de pacote significa que os pacotes experimentam atrasos diferentes dentro

da mesma corrente de pacotes [1].

Segundo Kurose e Ross [1], a principal causa da ocorrncia de jitterso os atrasos

aleatrios de fila nos roteadores, isto , pacotes do mesmo fluxo podem passar mais ou menos

tempo na fila de sada dos roteadores no caminho.

O jitter afeta principalmente aplicaes de multimdia como udio e vdeo. Se o


21/99

20

receptor ignorar a presena de variao de atraso e reproduzir as pores de dados assim que

elas chegam, ento a qualidade de udio ou vdeo poder facilmente se tornar ininteligvel no

receptor [1].

De acordo com Kurose e Ross [1], algumas tcnicas podem ser utilizadas para tentar

eliminar a variao de atraso, como a utilizao de nmeros de seqncia, marcas de tempo e

atraso de reproduo (utilizao de buffers).

Em algumas aplicaes, como vdeo por demanda, o jitterpode ser eliminado pelo

armazenamento em bufferno receptor, seguido pela busca de dados para exibio no buffer, e

no na rede em tempo real. No entanto, para outras aplicaes, em especial aquelas que

exigem interao em tempo real entre pessoas, como telefonia via Internet e

videoconferncia, o retardo inerente do armazenamento em bufferno aceitvel [13].Segundo Braun et al. [14], tanto aITU-Tquanto aIPPMutilizam o mesmo termo para

variao de atraso, IP Delay Variation. Ele definido como a diferena do atraso de um par

de pacotes de um mesmo fluxo, no so especificados quais pacotes devem ser usados, mas

normalmente so utilizados pacotes consecutivos. O IPDV um nmero real, positivo ou

negativo, e s pode ser definido com dois pacotes. Essa mtrica define os limites mnimos dos

buffers de recepo e importante para interatividade (buffers pequenos) e qualidade da

comunicao (pacotes muito atrasados so perdidos). AITU-Tdefine para classes de trfegode tempo real o limite mximo de 50 ms de variao de atraso.

Conforme Braun et al. [14], nas definies daIPPMe daITU-T, oIPDV diferente do

jitter. O jitter obtido atravs da diferena entre o atraso em uma direo de um pacote

especifico e a mdia do atraso em uma direo dos pacotes em um intervalo de tempo.

2.2.1.4 Throughput

Segundo Dattatreya [15], a definio geral para throughput de qualquer sistema a

taxa de produo de sadas bem sucedidas. Em comunicao de dados, a taxa total de bits,

calculada usando todos os bits dos pacotes recebidos corretamente.

Throughput tambm pode ser representado como largura de banda e, de acordo com

Tanenbaum [13], diferentes tipos de aplicaes tm necessidades de largura de banda

diferentes, correio eletrnico e login remoto, por exemplo, no exigem muita largura de

banda, j todas as aplicaes de vdeo necessitam de um grande volume desse recurso.


22/99

21

A IPPM define a mtrica Bulk Transport Capacity, e a define como a capacidade

mxima de transporte de um link utilizando uma nica conexo com um protocolo com

preveno de congestionamento (isto , TCP), onde todos os cabealhos, retransmisses ou

perdas so subtradas da performance geral. E fornece uma idia do mximo de performance

do ponto de vista do usurio quando ocorrem transferncias de alto volume de trfego[14].

A unidade de medida de throughput em bits por segundo (bps), podendo tambm ser

expressa em Kbps, Mbps, Gbps, etc. [14].

O throughput obtido dividindo o nmero de bits transmitidos com sucesso pelo

tempo em segundos transcorridos entre o inicio e o fim da transmisso.

2.2.1.5 Classes de Servio

Varias grupos de criao de padres tentam dividir os servios em categorias (Classes

de Servio de QoS). AITU-Tsugere a definio de seis classes resumidas na Tabela 1.

TABELA 1 - Classes de servioITU-T

Classe de Servio Caractersticas

0 Tempo real, sensvel aojitter, altamente interativa

1 Tempo real, sensvel aojitter, interativa

2 Transao de dados, altamente interativa

3 Transao de dados, interativa

4 Baixa perda (transferncia de dados, streaming de vdeo)

5 Aplicaes padro de redesIP

Segundo Marchese [12], a ITU-T define na recomendao Y.1541 classes de servio

genricas baseadas nos parmetros de QoS apresentados anteriormente. Nessa recomendao,

a ITU-Tassocia cada parmetro ( IPTD, IPDV, IPLR e IPER) a um limite mximo para o

mesmo em cada classe de servio, que refletem os requisitos para os diferentes tipos deaplicao. Os valores para cada classe de servio podem ser vistos na Tabela 2.


23/99

22

TABELA 2 - Classes de servio e limites mximos

Classe de Servio IPTD (ms) IPDV(ms) IPLR IPER

0 100 50 1x10-3 1x10-4

1 400 50 1x10-3 1x10-4

2 100 N* 1x10-3 1x10-4

3 400 N* 1x10-3 1x10-4

4 1000 N* 1x10-3 1x10-4

5 N* N* N* N**NNo especificado

2.2.2 Tcnicas para Alcanar Qualidade de Servio

Na seo 2.2.1 foram identificados os requisitos de qualidade de servio. Nesta seo

sero apresentadas as tcnicas que podem ser utilizadas para garantir os requisitos e prover

qualidade de servio.

2.2.2.1 Superdimensionamento

Uma soluo prtica para garantir a qualidade de servio fornecer tanta capacidade

de roteadores, tanto de espao de buffers e tanta largura de banda que os pacotes

simplesmente so transmitidos com enorme facilidade [13].

Segundo Marchese [12], existe um erro em pensar que o superdimensionamento vai

solucionar todos os problemas de QoS, e que aumentar a largura de banda uma soluo mais

simples que fazer o gerenciamento da qualidade de servio. Portanto, o

superdimensionamento no pode ser visto realmente com uma soluo, pois ainda ser

necessrio o gerenciamento da qualidade de servio para poder garantir os requisitos de


24/99

23

qualidade de servio, por exemplo, em um caso em que ocorram muito mais acessos a um

sistema do que o previsto e a largura de banda seja insuficiente.

E segundo Tanenbaum [13], no superdimensionamento existe outro problema

relacionado ao custo, pois necessrio adquirir uma quantidade enorme de equipamentos e

largura de banda.

2.2.2.2 Armazenamento em Buffers

Em Tanenbaum [13], vemos que os fluxos podem ser armazenados em buffers no lado

receptor antes de serem entregues para as aplicaes, isto , os pacotes chegam ao destino e

ficam armazenados no buffer e, aps algum tempo, so entregues s aplicaes de forma

constante.

Segundo Tanenbaum [13], o armazenamento dos fluxos em buffers no afeta a sua

confiabilidade e no causa impacto na utilizao da largura de banda, mas aumenta o atraso

dos pacotes tendo em vista que os pacotes s so entregues as aplicaes aps algum tempo.

A vantagem desta tcnica a suavizao do jitter, pois os pacotes s sofrero atrasos

na entrega para as aplicaes caso ocorra um atraso muito alto na rede e o bufferfique vazio.

Em algumas aplicaes como udio e vdeo por demanda, a variao no atraso o principal

problema, portanto, essa tcnica auxilia muito na qualidade deste tipo de servio.

2.2.2.3 Modelagem de Trfego

A modelagem de trfego est relacionada regulagem da taxa e do volume de

transmisso de dados [13]. A tcnica de modelagem de trfego suaviza o trfego no lado

transmissor fazendo com que os pacotes sejam enviados a uma taxa constante.

Segundo Tanenbaum [13] quando uma conexo configurada, deve ser determinado

um padro de trfego, ou seja, uma forma para essa conexo. A modelagem de trfego policia

os fluxos de dados limitando a largura de banda para uma taxa acordada, isto , faz com que

os fluxos fiquem dentro da forma prevista [12].


25/99

24

Com a modelagem de trfego possvel reduzir o congestionamento na rede, pois os

dados sero transmitidos de forma constante a uma taxa mxima. Este fator de grande

importncia no caso da transmisso de dados em tempo real, como conexes de udio e vdeo,

que tm requisitos estritos de qualidade de servio [13].

2.2.2.4 Mecanismos de Escalonamento

O modo como os pacotes enfileirados so selecionados para transmisso pelo enlace

conhecido como disciplina de escalonamento [1].

Segundo Marchese [12], o escalonamento de pacotes especifica a poltica de servios

de uma fila em um n, isto , o escalonamento decide a ordem que ser utilizada para escolher

os pacotes que sero transmitidos sobre um canal. Ele tambm uma parte importante quando

se fala de qualidade de servio, podendo causar grande impacto em diferentes parmetros de

QoS, como atraso,jittere perda de pacotes.

A seguir sero apresentadas as mais importantes disciplinas de escalonamento.

2.2.2.4.1FIFO

A disciplina de escalonamento FIFO seleciona pacotes para transmisso pelo enlace

na mesma ordem em que eles chegaram fila de sada do enlace [1]. Isto , o primeiro pacote

a chegar a um n ser o primeiro a ser transmitido.

Segundo Kurose e Ross [1], como os buffers em um n so finitos, se um pacote chega

fila de sada e ela est cheia, o n utilizar uma poltica de descarte e determinar se o

pacote ser descartado ou se outro pacote ser retirado da fila para dar espao aoque est

chegando. E Peterson e Davie [16] dizem que essa ao tomada sem levar em conta a qual

fluxo o pacote pertence ou o quanto ele importante.


26/99

25

2.2.2.4.2 Prioridade

Segundo Peterson e Davie [16], a disciplina de escalonamento por prioridade uma

variao bsica da disciplina FIFO, onde a idia marcar cada pacote com uma prioridade;

essa marca pode ser carregada, por exemplo, no campo TOS do cabealhoIP. E os roteadores

implementam mltiplas filas, normalmente do tipo FIFO, para cada prioridade.

De acordo com Kurose e Ross [1], na disciplina de escalonamento por prioridade um

n ao transmitir um pacote, sempre ser escolher um da classe de prioridade mais alta que a

fila no esteja vazia, isto , que tenha pacotes esperando para serem transmitidos.

Para Peterson e Davie [16], um problema com o escalonamento por prioridade que

enquanto a fila com a maior prioridade tiver ao menos um pacote para transmisso, as outras

filas no sero atendidas, podendo causar inanio nas outras filas.

2.2.2.4.3 Varredura Cclica

Na disciplina de escalonamento por varredura cclica os pacotes so classificados do

mesmo modo que no escalonamento por prioridade. Contudo, em vez de haver uma prioridade

estrita de servio entre as classes, um escalonador de varredura cclica alterna servios entre

as classes [1]. Isto , o escalonador transmite um pacote da classe um e em seguida um pacote

da classe dois, e volta a transmitir um pacote da classe um, seguido de outro classe dois e

assim por diante. Caso uma fila de uma classe esteja vazia transmitido um pacote de outra

fila.

2.2.2.4.4 WFQ

A disciplina de escalonamento Weighted Far Queue, segundo Peterson e Davie [16],

uma implementao de uma variao do escalonamento por varredura cclica, que permite que

sejam atribudos pesos para cada classe. E tem considervel utilizao nas arquiteturas com


27/99

26

QoS atuais [1].

Segundo Kurose e Ross [1], um escalonador WFQ atende as classes de modo cclico,

assim como na varredura cclica, mas cada classe receber uma frao de tempo igual ao seu

peso divido pelo somatrio dos pesos de todas as classes que tenham pacotes para transmitir.

2.2.2.5 Mecanismos de Regulao

Regulao o ajuste da taxa com a qual permitido que um fluxo injete pacotes na

rede e uma das pedras fundamentais de qualquer arquitetura com QoS [1].

Segundo Kurose e Ross [1], as caractersticas da taxa de pacotes reguladas em um

fluxo so:

Taxa mdia: nmero de pacotes enviados em um intervalo de tempo;

Taxa de pico: nmero mximo de pacotes que podem ser enviados durante um

perodo curto de tempo;

Tamanho da rajada: nmero mximo de pacotes que podem ser enviados em

um intervalo de tempo extremamente curto.Podemos ver em Marchese [12] que existem dois mtodos bsicos para regulao, os

quais sero apresentados a seguir.

2.2.2.5.1 Algoritmo de Balde Furado

De acordo com Tanenbaum [13], o algoritmo de balde furado consiste de uma fila

finita. Quando um pacote chega a um n, se houver espao na fila, ser includo nela; caso

contrrio, ele ser descartado. O balde transmite para a rede os bytes dos pacotes a uma taxa

constante.

Ainda, segundo Tanenbaum [13], esse tratamento faz com que os pacotes saiam do n

a uma taxa constante, independente da forma como chegam at ele, isto , ele transforma um

fluxo de pacotes irregulares em um fluxo de pacotes regular.


28/99

27

2.2.2.5.2 Algoritmo de Balde de Smbolos

O algoritmo do balde furado impe um padro rgido taxa mdia, independente da

irregularidade do trfego. Em muitas aplicaes melhor permitir que a sada aumente um

pouco sua velocidade quando chegarem rajadas maiores; assim, necessrio um algoritmo

mais flexvel, de preferncia um que nunca perca dados [13]. Um algoritmo como esse, o do

balde de smbolos.

O algoritmo do balde de smbolos similar ao do balde furado, mas sua

implementao diferente. De acordo com Marchese [12], smbolos so gerados a uma taxa

constante e colocados no balde. Quando um pacote entra na fila para ser transmitido, ele

precisa pegar um smbolo para cada byte que possui, consumindo o smbolo do balde. Um

byte s pode ser transmitido se existirem smbolos no balde, caso contrrio deve esperar at

que um novo smbolo seja inserido no balde.

Segundo Tanenbaum [13], o algoritmo do balde de smbolos possibilita um tipo de

modelagem de trfego diferente do algoritmo do balde furado, pois permite que fluxos

inativos ou com baixa atividade economizem smbolos para futuras rajadas de trfego.O balde de smbolos tem um tamanho finito e descarta smbolos quando o balde est

cheio, mas nunca descarta pacotes [13].

2.2.3 Servios Integrados e Servios Diferenciados

Nesta seo sero apresentadas as principais arquiteturas de QoS: Servios Integrados

(Intserv) e Servios Diferenciados (Diffserv). Elas representam padres correntes da IETF

para prover qualidade de servio e incorporam os princpios e os mecanismos apresentados

nas sees anteriores.

2.2.3.1 Servios Integrados


29/99

28

Entre 1995 e 1997, a IETFdedicou um grande esforo criao de uma arquitetura

para multimdia de fluxo. Este trabalho resultou em mais de duas dezenas de RFCs,

comeando com asRFCs 2205 a 2210. O nome genrico deste trabalho algoritmos baseados

no fluxo ou servios integrados [13].

Segundo Kurose e Ross [1], a arquitetura de servios integrados (Intserv) possui duas

caractersticas fundamentais:

Recursos reservados: Um roteador deve saber qual a quantidade de recursos que j

est reservada para sesses em andamento.

Estabelecimento de chamada: Uma sesso que exige garantias de QoS deve

primeiramente estar habilitada a reservar recursos suficientes em cada roteador da

rede em seu trajeto entre a origem e destino.

De acordo com Tanenbaum [13], o principal protocolo da IETFpara a arquitetura de

servios integrados oRSVP. Ele o protocolo empregado para fazer as reservas de recursos

entre a origem e o destino do fluxo.

Segundo Peterson e Davie [16], a arquitetura Intserv define duas grandes classes de

servios: servios garantidos e servios de carga controlada. Em Kurose e Ross [1], vemos

que a especificao de servio garantido definida na RFC2212, e estabelece limites rgidos

para atrasos de fila que um pacote sofrer em um roteador. J o servio de carga controlada

receber, de acordo com a RFC2211, uma qualidade de servio que se aproxima muito da

QoS que o mesmo fluxo receberia de um elemento de rede que no tivesse carga.

2.2.3.2 Servios Diferenciados

AIETFpadronizou arquitetura de servios diferenciados, descritas nas RFCs 2474 e

2475, como uma abordagem mais simples para oferecer qualidade de servio, uma estratgia

que pode ser implementada em grande parte localmente em cada roteador, sem configurao

antecipada e sem ter de envolver todo o caminho. Essa abordagem conhecida como

qualidade de servio baseada na classe (em vez de ser baseada no fluxo) [13].

A arquitetura de servios diferenciados (Diffserv) flexvel, no sentido de que no

define servios especficos nem classes de servios especficas. Em vez disso, ela fornece os


30/99

29

componentes funcionais, isto , as peas de uma arquitetura de rede com as quais esses

servios podem ser montados [1]. A arquitetura Diffserv consiste em dois conjuntos de

elementos funcionais:

Funes de borda: classificao de pacotes e condicionamento do trfego. Na

borda de entrada da rede os pacotes so marcados identificando a qual classe ele

pertence. A marcao feita alterando o campo DS do cabealho do pacote.Caso o

trfego esteja fora do padro acordado ele pode receber uma marcao diferente,

de uma classe menos prioritria, ou ser descartado [1].

Funo central: envio. Quando um pacote marcado com DS chega a um roteador

habilitado com Diffserv ele repassado at seu prximo salto de acordo com o

comportamento por salto associado classe do pacote. O comportamento por salto

influencia a maneira pela qual os buffers e a largura de banda de um roteador so

compartilhados entre as classes de trfego concorrentes [1].

De acordo com Peterson e Davie [16], aIETFdecidiu utilizar seis bits do campo TOS

do cabealhoIP para realizar a marcao dos pacotes,esses seis bits so chamados deDSCP.

Eles mapeiam as classes de servio que definem o comportamento por salto (PHB) a ser

aplicado ao pacote.

Segundo Kurose e Ross [1], at agora foram definidos dois PHBs: um de repasseacelerado (EF) e um de repasse assegurado (AF) respectivamente pelasRFCs 3246 e 2597.

O repasse acelerado dividido em duas classes, a do trfego regular e a do trfego de

repasse acelerado [13]. E, segundo Braun et al. [14], deve-se assegurar que o trfego da classe

de repasse acelerado receba uma taxa mnima de transmisso, independente da intensidade de

outros tipos de trfego.

De acordo com Tanenbaum [13], o repasse assegurado um pouco mais elaborado,

definindo quatro classes de prioridade, alm de trs possibilidades de descarte de pacotes queestejam sofrendo congestionamento: baixo, mdio e alto. Assim, definindo doze classes de

servio.

2.2.3.3Intserv XDiffserv

OIntserv capaz de prover uma qualidade de servio parecida com as de tecnologias


31/99

30

de circuitos, atravs da reservas de recursos prvia. Segundo Tanenbaum [13], os algoritmos

baseados no fluxo tm potencial para oferecer boa qualidade de servio a um ou mais fluxos,

porque eles reservam quaisquer recursos necessrios ao longo da rota. Porm, eles tambm

tm a desvantagem de exigirem uma configurao antecipada para estabelecer cada fluxo,

algo que no se ajusta bem quando existem milhares ou milhes de fluxos. Alm disso, eles

mantm o estado interno por fluxo nos roteadores e envolvem trocas complexas de roteador

para roteador, a fim de configurar os fluxos.

De acordo com Kurose e Ross [1], o Diffserv possui uma escalabilidade muito maior,

pois no precisa manter os estados dos fluxos, isso porque seu comportamento determinado

por salto e no fim-a-fim, isso uma diferena muito grande quando se trata de milhes de

fluxos (um nmero comum na Internetatual). Ainda possui uma flexibilidade muito maiorque a arquitetura Intserv na definio de classes, permitindo que sejam adicionadas ou

retiradas classes sem afetar a que j esto em utilizao.

2.2.4 Utilizao de QoS em redes

Atualmente a maioria das conexes de acesso a Internet, principalmente os acessos

residenciais,no possuem nenhum tipo de qualidade de servio oferecida. A nica garantia

oferecida uma pequena porcentagem da largura de banda contratada. No caso de acessos

corporativos o cenrio no muito diferente, mas a largura de banda garantida normalmente

maior.

Alguns provedores de servios deInternetvendem atualmente servios de acesso com

garantias de qualidade de servio, mas de acordo com Xiao [17], essa garantia s vlidaenquanto o trfego est dentro da rede do provedor de servio, quando passam por redes de

outros provedores a QoS no pode ser garantida.

Segundo Xiao [17], isso ocorre por que os provedores no possuem acordos para

manter a qualidade de servio do trfego de outros provedores em sua rede, sendo o trfego

proveniente de outros provedores tratados como servios de melhor esforo.

A qualidade de servio oferecida pelos provedores de servios a usurio na forma de

acordos de nvel de servio (SLA), onde so definidas as classes de servios oferecidas e osparmetros mximos de largura de banda, atraso, jittere nmero de pacotes perdidos em uma


32/99

31

determinada classe ou conexo. No SLA tambm definido a forma como o usurio entregar

os dados ao provedor, isso , marcao dos pacotes, taxa mdia, taxa de pico e tamanho

mximo de rajadas. Caso o trfego entregue esteja fora do formato acordado o provedor de

servios no ir garantir os nveis definidos no SLA [17].

Empresas e rgos pblicos tambm podem utilizar QoS dentro de suas redes privadas,

priorizando aplicaes crticas ou que necessitem de algum nvel de qualidade de servio para

um bom funcionamento, utilizando as tcnicas de QoS internamente.


33/99

32

3 METODOLOGIA

Neste capitulo apresentada a metodologia para o desenvolvimento do sistema e

documentao do desenvolvimento, incluindo alguns conceitos da UML. Alm de definidos

os cenrios e metodologia de testes.

3.1 Ferramentas

O desenvolvimento foi realizado utilizando o sistema operacional Linux, distribuio

GNU/Debian, verso 5.0.4 codinome Lenny, disponvel em http://www.debian.org. Foi

utilizado o softwareApache verso 2.0 como servidor HTTP (http://www.apache.org) com o

mdulo de suporte a linguagem PHP na verso 5.0 (http://www.php.net). Como servidor de

banco de dados, foi utilizado o softwareMySQL verso 5 (http://www.mysql.com).

O software utilizado pelo sistema para gerar os fluxos de dados o iperfverso 2.0.4(http://sourceforge.net/projects/iperf/). Ele tambm ser responsvel por gerar os dados brutos

com os resultados dos testes.

A ferramenta de teste de redes ping em conjunto com ferramentas de shell scripts foi

usada para registrar os dados de atraso dos fluxos.

A sute NetBeans (http://netbeans.org/) foi utilizada para o desenvolvimento das

pginas e scripts em PHP da interface web do sistema. Para gerar os grficos com os

resultados dos testes foi utilizada a classe PHP pChart, disponvel em

http://pchart.sourceforge.net/.

Todos os dados de configurao e resultados dos testes ficam armazenados em base de

dados no servidor MySQL. E o softwarephpmyadmin (http://www.phpmyadmin.net) foi

usado para a criao e manutenes na base de dados.


34/99

33

3.2 Desenvolvimento

Foram desenvolvidos scripts em shellscript(Apndices A e B), utilizando o editor de

texto gedit, para capturar as sadas geradas em arquivos de texto, retirar as informaes

desnecessrias e inserir os dados relevantes na base de dados, para que possam ser utilizados

futuramente para gerar os grficos e pgina de resultados a serem exibidos pela interface web.

O shell utilizado para executar os scripts o bash.

Foi desenvolvida uma interface web na linguagem PHP para a configurao dos testes

e apresentao dos resultados. Alguns cdigos desenvolvidos podem ser vistos nos Apndices

C a G.

Durante o desenvolvimento foram utilizados equipamentos de rede, como roteadores e

switchs, com capacidade de realizar QoS para verificar o funcionamento do sistema de testes

automatizados.

O desenvolvimento seguiu as seguintes fases:

Instalao do sistema operacional e ferramentas necessrias para o

desenvolvimento e funcionamento do sistema;

Testes das ferramentas iperfeping;

Desenvolvimento dos shell scripts que para tratamento dos resultados brutos do

teste;

Testes de funcionamento dos shell scripts;

Desenvolvimento da interface web para configurao dos testes e relatrios

automatizados;

Testes da interface web;

Laboratrio de testes com equipamentos de rede e diferentes configuraes de QoS

e ajustes no software.

Os diagramas da UML apresentados nesse trabalho foram desenvolvidos utilizando a

ferramenta de desenho de diagramasDIA (http://live.gnome.org/Dia).

O desenvolvimento do texto do trabalho ocorreu em paralelo ao desenvolvimento da

aplicao.

Algumas telas de exemplo de funcionamento do sistema encontram-se no Apndice I.


35/99

34

3.3 Requisitos

O sistema proposto visa permitir que sejam realizados testes de qualidade de servio

em redes de comunicao de dados de forma automatizada e que sejam criados relatrios

tambm de forma automatizada a partir dos resultados obtidos durante os testes.

Os testes devero ser configurados para que seja possvel medir os parmetros

definidos como essenciais para a qualidade de servio.

O sistema ter duas formas de funcionamento, modo escravo e modo mestre.

No modo escravo o usurio deve informar em qual endereo IP o sistema deve

aguardar a conexo do sistema em modo mestre, aps a conexo sero trocadas informaes

sobre os parmetros do teste e o escravo iniciar o envio de dados com o softwareiperf.

No modo mestre o usurio informar os dados bsicos do testes como nome, nmero

de fluxos, tempo de durao, tipo de marcao de pacotes e endereosIPs utilizados no teste.

Em seguida, para cada fluxo, dever informar a qual classe de QoS ele pertence, a largura de

banda e tamanhos dos pacotes.

Aps a confirmao dos dados pelo usurio, o sistema no modo mestre ir se conectar

ao sistema funcionando no modo escravo, enviar os parmetros dos testes e iniciar os

softwaresping e iperf para receber os fluxos e gerar os arquivos com resultados. Aps a

finalizao do testes ser responsvel por formatar e salvar os resultados e em seguida exibi-

los ao usurio.

Todos os campos exibidos nas pginas de configurao so de preenchimento

obrigatrio, com exceo do tempo de teste.

Caso o usurio no fornea o tempo de durao do testes ser utilizado o tempo padro

de sessenta segundos.O campo tamanho dos pacotes na configurao dos fluxos deve possuir um valor

maior que 64 bytes.

As marcas de QoS utilizadas nos fluxos devem ser digitadas em formato decimal.

O sistema dever permitir que o usurio visualize os resultados de testes anteriores.


36/99

35

3.4 Casos de Uso

O sistema possui trs casos de uso, que podem ser observados na Figura 2.

FIGURA 2 - Diagrama geral dos casos de uso

3.4.1 Iniciar Teste Lado Mestre

Nome do Caso de Uso: Iniciar Teste Lado Mestre Sistema de Teste de QoS

Ator Envolvido: Usurio

PR-CONDIO1Ter acesso ao sistema.

DESCRIO DO CASO1Clicar em iniciar novo Teste Mestre;2Inserir dados bsicos do teste;3Inserir dados dos fluxos;4Confirmar configuraes;5Se ocorrerem erros, fim.6Caso contrrio visualizar resultados.

PS-CONDIO1Teste realizado.2Resultados exibidos.


37/99

36

3.4.2 Iniciar Teste Lado Escravo

Nome do Caso de Uso: Iniciar Teste Lado Escravo Sistema de Teste de QoS


PR-CONDIO1Ter acesso ao sistema

DESCRIO DO CASO1Clicar em iniciar novo Teste Escravo;2Inserir dados do teste;3Se ocorrerem erros, fim.4Caso contrrio teste realizado com sucesso.

PS-CONDIO1Teste realizado.

3.4.3 Iniciar Testes Anteriores

Nome do Caso de Uso: Visualizar Testes Anteriores Sistema de Teste de QoS


PR-CONDIO1Ter acesso ao sistema.2Existirem testes j realizados

DESCRIO DO CASO1Clicar em iniciar Visualizar Resultados Anteriores;2Selecionar o teste desejado;3Visualizar resultados.

PS-CONDIO1Resultados exibidos.

3.5 Diagramas de Seqncia

A Figura 3 mostra o diagrama de seqncia da execuo de um teste completo.


38/99

37

FIGURA 3 - Diagrama de seqncia de um teste completo


39/99

38

3.6 Diagrama de Classes

A Figura 4 apresenta do diagrama de classes do sistema desenvolvido.

FIGURA 4 - Diagrama de classes

3.7 Modelagem de Dados

A estrutura do banco de dados utilizada no sistema formada por sete tabelas:

teste: armazena os dados bsicos e estados dos testes;fluxos_teste: contm as informaes especficas de cada fluxo do teste;


40/99

39

resultados_simples: armazena os resultados obtidos a partir das ferramentas iperfe

ping;

classe_qos: armazena os requisito mnimos para cada classe de servio.

A Figura 5 apresenta a estrutura do banco de dados.

FIGURA 5 - Estrutura de dados

3.8 Metodologia de Testes

Para a realizao dos testes de funcionamento do software foram utilizados dois

notebooks com sistema operacional Linux Debian, verso 5.0.4, e com todos os softwares

necessrios para o funcionamento do sistema. Foram utilizados tambm dois roteadores AR-

1700 da empresa FTD Comunicao de Dados.

Os testes foram realizados configurando os roteadores para prover a qualidade de

servio especificada por cada cenrio e o software foi configurado para testar os parmetros

de QoS de acordo com o proposto pelo cenrio.


41/99

40

3.9 Laboratrio de Testes

O laboratrio foi montado da forma apresentada da Figura 6, os roteadores foram

conectados atravs da porta serial (WAN), utilizando o protocolo PPP. E os notebooks foram

conectados as portasEthernet (LAN) dos seus respectivos roteadores. A conexo serial entre

os roteadores foi configurada com 2 Mbps de largura de banda.

FIGURA 6 - Diagrama do laboratrio de teste

Os testes foram realizados trs vezes em cada cenrio para evitar que uma falha

espordica ou comportamento estranho afetassem os resultados dos testes e tambm para

verificar a estabilidade e coerncia entre os resultados do software.

3.10 Cenrios de Testes

Foram criados trs cenrios de testes com configuraes diferentes para avaliar o

funcionamento e comportamento do software.

3.10.1 Cenrio 1

No cenrio 1 foram utilizados dois fluxos com as caractersticas apresentadas na

Tabela 3, com o fluxo 1 recebendo uma prioridade maior que a do fluxo 2 no escalonamento.


42/99

41

TABELA 3 - Configuraes dos fluxos de dados no cenrio 1

Fluxo Classe Largura deBanda (bps)

Tamanho dosPacotes (bytes)

1 1 - Tempo real, sensvel aojitter, interativa 300 000 64

2 5 - Aplicaes padres de redesIP 1 700 000 1 500

3.10.2 Cenrio 2

No cenrio 2 foram utilizados trs fluxos com as caractersticas apresentadas na Tabela

4, com o fluxo 1 e fluxo 2 recebendo a mesma prioridade, portanto compartilhando a banda

no escalonamento e o fluxo 3 com uma prioridade menor.




1 0 - Tempo real, sensvel aojitter, altamenteinterativa

200 000 128


3 5 - Aplicaes padres de redesIP 1 650 000 768

3.10.3 Cenrio 3

No cenrio 3 foram utilizadas as mesmas configuraes do cenrio 2 com trs fluxos e

com as caractersticas apresentadas na Tabela 5, e com o fluxo 1 e fluxo 2 recebendo a mesma

prioridade, portanto compartilhando a banda no escalonamento e o fluxo 3 com uma

prioridade menor.

Durante a execuo do teste o fluxo 3 foi configurado para gerar uma largura de banda

de 2000000 bps, acima do permitido para a classe e perto do limite mximo do link, paraverificar se o excesso de trfego desse fluxo no ir influenciar no escalonamento dos fluxos


43/99

42

de maior prioridade.




1 0 - Tempo real, sensvel aojitter, altamenteinterativa

200 000 128


3 5 - Aplicaes padres de redesIP 1 650 000 768

3.11 Realizao dos Testes

O laboratrio foi montado de acordo com o proposto, como pode ser observado nas

Figuras 7 e 8. Primeiramente os roteadores foram configurados de acordo com as regras de

cada cenrio (Apndice J) e em seguida foram realizados os testes, trs vezes consecutivas em

cada configurao, pelo perodo de cinco minutos por teste.Durante os testes foi encontrado um problema com o tamanho dos pacotes para a

realizao dos mesmos. A ferramenta iperfao ser configurada para gerar os dados utilizando

pacotes muito pequenos gera um volume de dados muito maior do que o configurado. Isso se

de deve ao fato da configurao do tamanho do pacote na ferramenta ser relativo apenas a

quantidade de dados do pacote, assim como a largura de banda utilizada, tambm se refere aos

dados do pacote, excluindo os cabealhos UDP, IP e Ethernet. Por esse motivo, os testes

foram realizados utilizando em todos os fluxos o tamanho do pacote em 1500 bytes.


44/99

43

FIGURA 7 - Laboratrio de testes viso geral

FIGURA 8 - Laboratrio de testes roteadores


45/99

44

4 RESULTADOS E DISCUSSES

Nesta seo sero mostrados e analisados os resultados obtidos durante os testes, os

relatrios de resultados completos gerados pelo sistema esto no Apndice H.

4.1 Resultados no Cenrio 1

No cenrio 1 todos os testes ocorreram sem problemas e os fluxos apresentaram o

comportamento e resultados esperados, de acordo com as classes de QoS definidas

anteriormente, so apresentados na Tabela 6 e os resultados obtidos esto na Tabela 7.

TABELA 6 - Resultados esperados nos testes no cenrio 1

Fluxo Throughput (bps) IPTD (ms) IPDV(ms) IPLR

1 >= 291 601,12 < 400 < 50 < 0,001

2 >= 1 652 419,04 N N N*NNo especificado

TABELA 7 - Resultados dos testes no cenrio 1

Fluxo Teste Throughput (bps) IPTD (ms) IPDV(ms) IPLR

1

1 293 960,8 6,772 4,129 0,000

2 293 960,8 5,246 2,529 0,0003 293 960,8 6,594 3,569 0,000

2

1 1 665 608,0 17,417 3,967 0,000

2 1 666 156,8 8,301 2,863 0,000

3 1 665 333,6 8,458 3,155 0,000

Podemos observar que todos os resultados ficaram dentro dos parmetros esperados e

o desempenho do software ficou de acordo com o configurado.


46/99

45


No cenrio 2 ocorreram problemas durante o teste de numero trs, durante quinze

segundos houve aumento de atrasos, sem explicao, fazendo com que o resultado fosse

negativo para esse parmetro em alguns fluxos. O grfico de atraso, mostrado na Figura 9,

mostra o resultado anormal, comparado com o grfico de um teste com resultado correto

(Figura 10).

FIGURA 9 - Grfico de atraso no teste 3 do cenrio 2


Os resultados esperados para os testes nesse cenrio, de acordo com as classes de QoS

definidas anteriormente, so apresentados na Tabela 8 e os resultados obtidos na Tabela 9.


Fluxo Throughput (bps) IPTD (ms) IPDV(ms) IPLR

1 >= 194 401,12 < 100 < 50 < 0,001

2 >= 145 801,12 < 400 < 50 < 0,0013 >= 1 603 805,60 N N N

*NNo especificado


47/99

46



1

1 195 960,8 5,168 2,006 0,000

2 195 960,8 5,224 2,221 0,000

3 195 960,8 5,012 2,366 0,000

2

1 146 960,8 4,670 1,681 0,000

2 146 960,8 4,673 2,552 0,000

3 146 960,8 4,179 2,190 0,000

3

1 1 616 804,0 11,825 6,865 0,000

2 1 616 216,0 17,295 9,048 0,0003 1 616 804,0 14,107 7,629 0,000

Podemos observar que todos os resultados ficaram dentro dos parmetros esperados,

que o desempenho do software ficou de acordo com o configurado e, mesmo com o problema

de atrasos no terceiro teste o resultado mdio ficou bem prximo ao obtido nos outros testes

do cenrio.


No cenrio 3, assim como no cenrio 2, ocorreram problemas durante o teste de

nmero um, com relao ao aumento de atrasos, durante dez segundos, tambm fazendo com

que o resultado fosse negativo para esse parmetro em alguns fluxos. O grfico de atraso,mostrado na Figura 11, mostra o resultado anormal, comparado com o grfico de um teste

com resultado correto (Figura 12).


48/99

47



Os resultados esperados para os testes nesse cenrio, de acordo com as classes de QoS

definidas anteriormente, so apresentados na Tabela 10. Neste cenrio esperado que o fluxo

trs no obtenha o mnimo esperado no parmetro de largura de banda, pois a largura de

banda gerada maior do que a capacidade do enlace entre os roteadores, mas esperado que

o excesso de banda gerada no fluxo trs no interfira nos resultados dos outros fluxos. Os

resultados obtidos esto na Tabela 11.


Fluxo Throughput (bps) IPTD (ms) IPDV(ms) IPLR1 >= 194 401,12 < 100 < 50 < 0,001

2 >= 145 801,12 < 400 < 50 < 0,001

3 >= 1 944 104,16 N N N*NNo especificado


49/99

48



11 195 960,8 4,842 3,338 0,0002 195 960,8 4,952 2,710 0,000

3 195 960,8 5,151 2,366 0,000

2

1 146 960,8 4,832 2,840 0,000

2 146 960,8 4,635 2,776 0,000

3 146 960,8 4,927 2,469 0,000

3

1 1 575 604,8 258,113 9,646 0,195

2 1 575 448,0 240,895 9,996 0,195

3 1 570 469,6 259,917 9,759 0,198

Os resultados ficaram dentro dos parmetros esperados e o desempenho do software

ficou de acordo com o configurado e, da mesma forma que no cenrio 2 ocorreram problemas

com atrasos no teste nmero um, o resultado mdio, porm, ficou bem prximo ao obtido nos

outros testes do cenrio.

4.4 Consideraes Sobre os Resultados

Atravs dos resultados obtidos foi possvel verificar que o sistema est funcionando

bem e de forma estvel, e que tambm est medindo de forma correta os parmetros de

qualidade de servio propostos. Principalmente no cenrio 3 foi possvel verificar o

funcionamento do QoS aplicado pelo roteador, que mesmo com um fluxo de trfego comlargura de banda maior do que o suportado pelo enlace manteve a qualidade dos fluxos que

possuam uma prioridade maior.

No foi possvel determinar a causa dos problemas nos testes de atraso, sendo a causa

mais provvel, a interferncia de outro software em execuo nos computadores que

realizavam os testes, que utilizou recursos, como processamento, atrasando o funcionamento

do software que realiza o teste de atraso. Aps a ocorrncia dos erros em dois testes seguidos

os roteadores foram reiniciados, e os testes seguintes no apresentaram erros.Devido ao comportamento do iperfcom pacotes pequenos, no foi possvel realizar os


50/99

49

testes com o tamanho de pacotes propostos, para isso ser necessria uma alterao no

funcionamento do software que dever prever os tamanhos dos cabealhos para calcular o

trfego que dever ser gerado pelo iperf.


51/99

50

5 CONCLUSO

Com base nos critrios e resultados apresentados nesta monografia, onde o objetivo

era o desenvolvimento de um ambiente de testes automatizados de qualidade de servio em

rede de comunicao de dados baseado em softwares livres, constatou-se que o objetivo

proposto foi alcanado.

O usurio do sistema pode realizar os testes atravs de uma interface web e visualizar

os resultados na prpria aplicao sem a necessidade de recorrer a comandos no shell e outros

softwares para montar os relatrios e grficos com os resultados.

A utilizao de ferramentas livres como Linux, Apache, MySQL, iperf, ping

proporcionam uma ferramenta gratuita para a realizao dos testes de qualidade de servio em

ocasies onde necessrio verificar o funcionamento das configuraes aplicadas na rede,

sendo uma alternativa muito mais barata que os equipamentos de testes de redes encontrados

no mercado.

Durante a realizao do trabalho foi possvel aprimorar os conhecimentos em

programao utilizando shell scripts alm de um aprendizado muito grande em linguagem de

programao PHP, banco de dados MySQL e nos funcionamento e opes de configuraes

das ferramentasping e iperf.

5.1 Extenses

Este trabalho pode ser continuado da seguinte forma:

Implementao de um mdulo gerador de trfego, baseado no iperf, que seja mais

flexvel permitindo, por exemplo, que o trfego gerado tenha perodos de

inatividade ou perodos de pico de trfego acima do permitido pela configurao

do QoS;

Implementao de um mdulo para medio de atraso e tratamento dos dados sem

a necessidade de utilizao de ferramentas de shell scripts, permitindo que a

ferramenta possa ser utilizadas em outros sistema operacionais;

Utilizao de base de dados que no necessite de um servidor MySQL instalado,


52/99

51

utilizando, por exemplo, base de dados SQLite, aumentando a portabilidade da

ferramenta;

Utilizao de servidor web leve,integrado, multiplataforma e com suporte a PHP.

Implementao, que em conjunto com as sugestes anteriores, tornaria o sistema

totalmente portvel;

Exportao dos resultados para planilhas eletrnicas.


53/99

52

REFERNCIAS

1 KUROSE, J. F.; ROSS, K. W. Redes de Computadores e a Internet: uma abordagem top-

down. 3 edio. So Paulo: Pearson, 2006. 634 p.

2 FLUKE NETWORKS. One Touch Series II: Overview. Disponvel em:

. Acesso em: 08 mar.

2010.

3 FLUKE NETWORKS. Test and Troubleshoot. Disponvel em:

. Acesso em: 08 mar. 2010.

4 JDSU. SmartClass Ethernet. Disponvel em: . Acesso em: 08 mar. 2010.

5 JDSU. Acess Network Test. Disponvel em:


6 FLUKE NETWORKS. EtherScope Series II: Overview. Disponvel em:


7 JDSU. T-BERD 4000 Multiple Services Test Platform. Disponvel em:


8 CISCO SYSTEMS. Internetworking Technology Handbook: Internet Protocols (IP).

Disponvel em:


54/99

53

Protocols.html#wp2468>. Acesso em: 07 mar. 2010.

9 OODAN, A. et al. Telecommunications Quality of Service Management: From legacy to

emerging services. Londres, Reino Unido: The Institution Of Engineering And Technology,

2009. 602 p.

10 ISO - INTERNATIONAL ORGANIZATION FOR STANDARDIZATION. ISO

8402:1994: Quality management and quality assurance -- Vocabulary. Disponvel em:

. Acesso em: 12 abr. 2010.

11 ITUINTERNATIONAL TELECOMMUNICATION UNION. Terms and definitions

related to quality of service and network performance including dependability.

Disponvel em: . Acesso em: 03 mar. 2010.

12 MARCHESE, M. QoS Over Heterogeneous Networks. West Sussex: John Wiley & Sons,

2007. 307 p.

13 TANENBAUM, A. S. Rede de Computadores. 4 edio. Rio de Janeiro:

Campus/Elsevier, 2003. 968 p.

14 BRAUN, T. et al. End-to-End Quality of Service Over Heterogeneous Networks.

Berlin: Springer, 2008. 266 p.

15 DATTATREYA, G. R. Performance Analysis of Queuing and Computer Networks. 1

edio. Boca Raton: CRC Press, 2008. 449 p.

16 PETERSON, L. L.; DAVIE, B.S. Computer Networks: A Systems Approach. 3. ed. San

Francisco: Elsevier Science, 2003. 809 p.

17 XIAO, X. Technical, commercial, and regulatory challenges of QoS: An Internet

Service Model Perspective. Burlington: Elsevier, 2008. 274 p.


55/99

54

REFERNCIAS CONSULTADAS

BEZERRA, E. Princpios de anlise e projeto de sistemas com UML. Rio de Janeiro:

Elsevier, 2002. 279p.

BLUM, R. Linux Command Line and Shell Scripting Bible. Indianapolis: Wiley

Publishing, 2008. 809 p.

BURTCH, K. O. Linux Shell Scripting with Bash. 1 edio. Indianapolis: Sams Publishing,

2004. 412 p.

CONVERSE, T.; PARK, J.; MORGAN, C. PHP5 and MySQL Bible. Indianapolis: Wiley

Publishing, 2004. 1042 p.

MySQL AB. MySQL 5.1 Reference. Disponvel em:


NARAMORE, E.; GERNER, J.; SCOUARNEC, Y. L.; STOLZ, J.;GLASS, M. K. Beginning

PHP5, Apache, and MySQL Web Development. Indianapolis: Wiley Publishing, 2005. 798

p.

PETERS, R. Expert Shell Scripting. 1 edio: Apress, 2009. 293 p.

PHP GROUP. PHP: Documentation. Disponvel em: .

Acesso em: 06 mar. 2010.

RNPREDE NACIONAL DE ENSINO E PESQUISA. QoS. Disponvel em:

. Acesso em: 27 fev. 2010.


56/99

55

APNDICES


57/99

56

APNDICE AShellscript para tratamento dos dados gerados pelo iperf:apagaresumo.sh

######################################################Processa Saidas IPERF e insere na base de dados ##Parametros: ## $1 ID do Teste ## $2 ID do Fluxo ## $3 arquivo a ser processado ## $4 usuario sql ## $5 senha sql ## $6 base de dados sql ######################################################

#Limpando linhas desnecessariaslinhas=`cat $3 | grep -in ",0.0-" | grep -v ",0.0-1\.0" | cut -d ',' -f 7`fluxo=$2teste=$1for i in $linhas; do

sed "/"$i"/d" $3 > tmp$3cat tmp$3 > $3rm tmp$3

donecont=0echo $contlinhas=`cat $3`for i in $linhas; do

if [ "$cont" -eq 0 ]; thentinicial="1970-1-1"tinicial=$tinicial" "$(echo $i | cut -d',' -f1 | cut -c'9-10');tinicial=$tinicial":"$(echo $i | cut -d',' -f1 | cut -c'11-12');tinicial=$tinicial":"$(echo $i | cut -d',' -f1 | cut -c'13-14');tinicial=$(date -d "$tinicial" +"%s")cont=1

echo $tinicial

ficolarray[0]=`expr $tinicial + $(echo $i | cut -d',' -f7 | cut -d'-' -f 2 | cut -d'.' -f 1) - 10801`echo ${colarray[0]}

colarray[1]=$(echo $i | cut -d',' -f2)colarray[2]=$(echo $i | cut -d',' -f3)colarray[3]=$(echo $i | cut -d',' -f8)colarray[4]=$(echo $i | cut -d',' -f9)colarray[5]=$(echo $i | cut -d',' -f10)colarray[6]=$(echo $i | cut -d',' -f11)colarray[7]=$(echo $i | cut -d',' -f12)mysql -u $4 -p$5 -e "INSERT INTO resultados_simples

VALUES($2,$1,'${colarray[1]}:${colarray[2]}',${colarray[3]},${colarray[4]},${colarray[5]},${colarray[6]},${colarray[7]},${colarray[0]},null)" $6done


58/99

57

APNDICE BShell script para tratamento dos dados gerados peloping: pings.sh

#######################################################*Processa Saidas do ping e insere na base de dados ##Parametros: ## $1 ID do Teste ## $2 ID do Fluxo ## $3 arquivo a ser processado ## $4 usuario sql ## $5 senha sql ## $6 base de dados sql ## #######################################################

linhas=`cat $3 | tr -d ' ' `fluxo=$2teste=$1

for i in $linhas; do

colarray[0]=$(echo $i | cut -d':' -f1)

colarray[1]=$(echo $i | cut -d'=' -f4 | cut -d'm' -f1)

mysql -u $4 -p$5 -e "UPDATE resultados_simples SET ping_rtt=${colarray[1]} WHEREtesteid=$1 AND fluxoid=$2 ANDtempos=((HOUR(${colarray[0]})*60*60)+(MINUTE(${colarray[0]})*60)+SECOND(${colarray[0]}))" $6

done


59/99

58

APNDICE CAgente escravo: servidor.php


60/99

59

fclose($fp);die("Falha ao aceitar conexo no socket: " . socket_strerror ($msgsock) . "\n");break;

}

$fp = fopen('status/statusconexaoe.sts', 'w');ftruncate($fp,0);fwrite($fp,'3');fclose($fp);$msg = "0\n";socket_write($msgsock, $msg, strlen($msg));

do {if (FALSE == ($buf = socket_read ($msgsock, 2048, PHP_NORMAL_READ))) {

echo "Erro recebendo dados do socket" . socket_strerror ($ret) . "\n";break 2;

}if (!$buf = trim ($buf)) {

continue;}$confs=split(',',$buf);if ($buf == 'R') {

break;}if ($buf == 'E') {

socket_close ($msgsock);break 2;

}if ($confs[0] == 'I') {

$numfluxos=intval($confs[1]);$ipmaster=$confs[2];$tipomarca=$confs[3];$tempoteste=$confs[4];$resp = "I,F,".$numfluxos." \n";socket_write ($msgsock, $resp, strlen ($resp));

//break;}

if ($confs[0] == 'F') {if($numfluxos > 0 & intval($confs[1])


61/99

60

}if ($confs[0] == 'S') {

$resp = "S,GO\n";socket_write ($msgsock, $resp, strlen ($resp));

$fp = fopen('status/statusconexaoe.sts', 'w');ftruncate($fp,0);fwrite($fp,'4');fclose($fp);for($i=1; $i


62/99

61

APNDICE DScriptPHP para armazenar dados do teste e fluxo na base de dados einicializar o agente mestre: salvar_teste.php


63/99

62

$result1 = mysqli_query($conn, 'INSERT INTO fluxos_teste (teste_id, fluxo_id,fluxo_classe, fluxo_marca, fluxo_banda, fluxo_tam_pacote) VALUES ('.$teste_id.', '.$i.','.$classe.', "'.$marca.'", '.$banda.', '.$tampacote.')');

if(!$result1) {

mysqli_rollback($conn);die('Erro inserido dados do fluxo'.$i);}mysqli_free_result($result1);

}

mysqli_commit($conn);mysqli_close($conn);echo "Dados Inseridos com Sucesso";

$ip=$_POST["ip_local"];$cmd = "php ./cliente.php '$teste_id' >/dev/null & ";

passthru($cmd);sleep(5);Redirecionar_URL();

?>


64/99

63

APNDICE EAgente mestre: cliente.php


65/99

64

$fp = fopen('status/statusconexaom.sts', 'w');ftruncate($fp,0 );fwrite($fp,'2');fclose($fp);

$buf = socket_read ($socket, 1024);$msg="I,".$teste_num_fluxo.",".$teste_ip_mestre.",".$teste_tipo_marca.",".$teste_tempo."\n";socket_write ($socket, $msg, strlen ($msg));$buf = socket_read ($socket, 1024);$resp=split(',',$buf);if($resp[0] == "I" & $resp[1] == "F" & intval($resp[2]) == $teste_num_fluxo){


}else{

$fp = fopen('status/statusconexaom.sts', 'w');ftruncate($fp,0 );fwrite($fp,'-1');fclose($fp);socket_write ($socket,"E\n",3);socket_close ($socket);mysqli_close($conn);die("Erro na troca de dados do teste!!!");

}

for($i=1; $i


66/99

65

mysqli_close($conn);die("Erro na troca de dados do fluxo!!!");break;

}

}

for($i=1; $i


67/99

66

$buf = socket_read ($socket, 1024);$resp=split(',',$buf);

if($resp[0]== 'T'){// & $resp[1] == "BYE"){


}else{

$fp = fopen('status/statusconexaom.sts', 'w');ftruncate($fp,0 );fwrite($fp,'-1');fclose($fp);socket_write ($socket,"E\n",3);

socket_close ($socket);mysqli_close($conn);$cmd = "killall iperf";passthru($cmd);$cmd = "killall ping";passthru($cmd);die("Teste no finalizado corretamente!!!");

}

mysqli_close($conn);socket_close ($socket);

$cmd = "killall iperf";passthru($cmd);$cmd = "killall ping";passthru($cmd);

for($i=1; $i


68/99

67

APNDICE FScript PHP para gerar graficos: gera_grafico.php


69/99

68

$DataSet->Addpoint($tempos[1],"Tempos");$DataSet->SetAbsciseLabelSerie("Tempos");$DataSet->SetXAxisName("Tempo de Teste");

//Grafico Largura de Banda// Initialise the graph$Test = new pChart(1200,300);$Test->drawGraphAreaGradient(90,90,90,90,TARGET_BACKGROUND);

// Prepare the graph area$Test->setFontProperties("fonts/tahoma.ttf",9);$Test->setGraphArea(80,40,980,260);

// Initialise graph area

$Test->setFontProperties("fonts/tahoma.ttf",9);

for($i = 1; $i AddSerie("BandaF".$i);$DataSet->SetSerieName("Largura de Banda Fluxo ".$i,"BandaF".$i);

}

// Draw the SourceForge Rank graph$DataSet->SetYAxisName("Largura de Banda kbps");$Test->drawScale($DataSet->GetData(),$DataSet-

>GetDataDescription(),SCALE_NORMAL,213,217,221,TRUE,0,0,FALSE,10,FALSE);$Test->drawGraphAreaGradient(225,225,225,-30);$Test->drawGrid(1,TRUE,155,155,155,10);$Test->setShadowProperties(2,2,0,0,0,30,4);$Test->drawCubicCurve($DataSet->GetData(),$DataSet->GetDataDescription());$Test->clearShadow();$Test->drawFilledCubicCurve($DataSet->GetData(),$DataSet->GetDataDescription(),.1,30);

// Write the legend (box less)$Test->setFontProperties("fonts/tahoma.ttf",12);$Test->drawLegend(980,50,$DataSet-

>GetDataDescription(),0,0,0,0,0,0,255,255,255,FALSE);// Write the title$Test->setFontProperties("fonts/MankSans.ttf",18);$Test->setShadowProperties(1,1,0,0,0);$Test->drawTitle(0,0,"Resultado dos Testes - Largura de

Banda",255,255,255,1200,30,TRUE);$Test->clearShadow();

// Render the picture$Test->Render("graficos/resultado_banda.png");

for($i = 1; $i RemoveSerie("BandaF".$i);


70/99

69

$DataSet->removeSerieName("BandaF".$i);}

//Grafico RTT

// Initialise the graph$Test = new pChart(1200,300);$Test->drawGraphAreaGradient(90,90,90,90,TARGET_BACKGROUND);

// Prepare the graph area$Test->setFontProperties("fonts/tahoma.ttf",9);$Test->setGraphArea(80,40,980,260);

// Initialise graph area$Test->setFontProperties("fonts/tahoma.ttf",9);

for($i = 1; $i AddSerie("RttF".$i);$DataSet->SetSerieName("RTT Fluxo ".$i,"RttF".$i);

}

// Draw the SourceForge Rank graph$DataSet->SetYAxisName("RTT ms");$Test->drawScale($DataSet->GetData(),$DataSet-

>GetDataDescription(),SCALE_NORMAL,213,217,221,TRUE,0,0,FALSE,10,FALSE);$Test->drawGraphAreaGradient(225,225,225,-30);$Test->drawGrid(1,TRUE,155,155,155,10);$Test->setShadowProperties(2,2,0,0,0,30,4);$Test->drawCubicCurve($DataSet->GetData(),$DataSet->GetDataDescription());$Test->clearShadow();$Test->drawFilledCubicCurve($DataSet->GetData(),$DataSet->GetDataDescription(),.1,30);

// Write the legend (box less)$Test->setFontProperties("fonts/tahoma.ttf",12);$Test->drawLegend(980,50,$DataSet-

>GetDataDescription(),0,0,0,0,0,0,255,255,255,FALSE);

// Write the title$Test->setFontProperties("fonts/MankSans.ttf",18);$Test->setShadowProperties(1,1,0,0,0);$Test->drawTitle(0,0,"Resultado dos Testes - RTT",255,255,255,1200,30,TRUE);$Test->clearShadow();

// Render the picture$

Ambiente de Testes

Documents

Transcript of Ambiente de Testes