Ambiente para Especificação de Aplicações Multimídia Com Suporte de Qualidade de Serviço

UNIVERSIDADE FEDERAL DE SO CARLOS
CENTRO DE CINCIAS EXATAS E DE TECNOLOGIA

PROGRAMA DE PS-GRADUAO EM CINCIA DA COMPUTAO
Ambiente para Especificao de Aplicaes

Multimdia com Suporte de Qualidade de Servio
Wesley Barbosa Thereza
So Carlos
Agosto/2004
II
III
Ficha catalogrfica elaborada pelo DePT da

Biblioteca Comunitria da UFSCar
T398ae
Thereza, Wesley Barbosa.

Ambiente para especificao de aplicaes multimdia
com suporte de qualidade de servio / Wesley Barbosa
Thereza. -- So Carlos : UFSCar, 2006.
100 p.
Dissertao (Mestrado) -- Universidade Federal de So
Carlos, 2004.
1. Sistemas multimdia. 2. Qualidade de servio. 3.
Linguagem de marcao. 4. HQML. I. Ttulo.
CDD: 006.7 (20a)
Dedico este trabalho a Deus, meus pais e irmos

pelo apoio, amor e fora de sempre.
IV
Agradecimentos
Inicialmente a minha famlia pai (Testa), me (Gansa) e irmos

(Capivara e Cabelo) - pelo apoiou desde o incio para a realizao deste meu sonho.
A todos os amigos que se fazem presentes na minha vida, me apoiando e
sendo meu alento para todas as horas, desde as agradveis at as mais difceis.
Ao meu orientador Prof. Srgio Donizetti Zorzo pelo conhecimento,
apoio e, principalmente, pacincia.
Aos funcionrios e professores do Departamento de Computao, em
especial a Cristina (Cris), Prof. Luis Carlos Trevelin, Prof. Hlio C. Guardia e Prof.
Clio Estavan Moron.
Aos amigos do laboratrio de Sistemas Distribudos e Redes (aqurio),
pela ajuda e companheirismo: Eugeni (Mestre), Bruno (Amaral), Alessandro
(Quadrado), Lcio (Warta) e Fabiana (Maninha).
Aos amigos e colegas do PPG-CC pela cumplicidade das dores e
sucessos: Moacir (Mo-moacir), Eduardo (Escovar), Juliano (Jukinha), Daniel
(Lucldio), Fernando (Genta), Taciana, Alexandre (Cl), Darley (Biriguei), Anderson
(Dinho), Pablo (Pablito) e Aureliano (Oreia).
Aos grandes amigos que fiz aqui pelos momentos de alegria e extrema
felicidade: Mairum (Caso), Vincius (Baiano), Renato (Renatim), Ricardo (Rar) e
rico (Sabirila). Com certeza, sem vocs eu no teria finalizado esse trabalho.
V
Em especial ao grande amigo Fernando (Bocudo). Acho que aps todo

esse tempo de convivncia, passei a consider-lo como um irmo. Irmo sempre
presente em todos os momentos vividos ao longo desses anos. Espero que nossa relao
de irmandade permanea por toda nossa vida. Valeu mesmo, cara.
VI
Abstract
This work describes an environment for specification of distributed

multimedia applications with demanded Quality of Service (QoS) detailing.
The description of the application is made in a hierarchic way, in the
user, application and resource level, adding the demanded QoS parameters and the
adaptation rules to be applied for the Quality of Service monitoring/ (re)negotiation.
These rules and QoS parameters will be responsible for the activation of
the system adaptation to guarantee its execution in compliance with the Quality of
Service negotiated in the specification.
After the specification phase of the distributed multimedia system, the
environment generates the documentation in a specification language of system with
QoS detailing and its adaptation/ (re)negotiation forms.
This documentation feeds NIST Net emulator, allowing that the results
can be analyzed by the verification of the multimedia system behavior and the emulated
system.
VII
Resumo
Esse trabalho descreve um ambiente para especificao de aplicaes
multimdia distribuda com detalhamento da Qualidade de Servio (Quality of Service
QoS) exigida.
A descrio da aplicao feita de forma hierrquica, nos nveis de
usurio, aplicao e recursos, acrescentando os parmetros de QoS exigidos e as regras
de adaptao a serem aplicadas para o monitoramento/ (re)negociao da Qualidade de
Servio.
Essas regras e parmetros de QoS sero responsveis para a ativao da
adaptao do sistema de forma a garantir a sua execuo em conformidade com a
Qualidade de Servio negociada na especificao.
Aps a fase de especificao do sistema multimdia distribudo, o
ambiente gera a documentao em uma linguagem de especificao de sistema com
detalhamento da QoS e suas formas de adaptao/ (re)negociao.
Essa documentao alimenta o emulador Nist Net, permitindo que os
resultados possam ser analisados mediante a verificao do comportamento do sistema
multimdia via sistema emulado.
VIII
Sumrio
Lista de Figuras..............................................................................................................XI
Lista de Tabelas............................................................................................................ XII
1 - Introduo ...................................................................................................................1
2 - Qualidade de Servio ..................................................................................................5
2.1 - Definio ..............................................................................................................5
2.2 - Mapeamento de QoS...........................................................................................7
2.2.1 - QoS de Usurio..............................................................................................8
2.2.2 - QoS de Aplicao ..........................................................................................8
2.2.3 - QoS de Sistema (Software e Hardware) ........................................................9
2.2.4 - QoS de Rede ................................................................................................12
2.3 - Abordagem ........................................................................................................14
3 - Linguagens de Especificao de Qualidade de Servio para Aplicaes Multimdia
Distribudas ....................................................................................................................17
3.1 - Particionamento das Linguagens de Especificao de QoS em Camadas...19
3.2 - Particionamento das Linguagens de Especificao de QoS em Paradigmas
.....................................................................................................................................20
3.2.1 - Paradigma baseado em script.......................................................................20
3.2.2 - Paradigma baseado em parmetro ...............................................................21
3.2.3 - Paradigma orientado a processo ..................................................................22
3.2.4 - Paradigma baseado em controle lgico .......................................................22
3.2.5 - Paradigma baseado em markup ...................................................................23
3.2.6 - Paradigma orientado a aspecto ....................................................................23
3.2.7 - Paradigma orientado a objeto ......................................................................24
3.3 - Critrios para Avaliao das Linguagens de Especificao de QoS ............25
4 - Linguagem de Marcao para Especificar QoS Hierarquicamente ......................28
4.1 - Modelo de Aplicao.........................................................................................30
4.2 - Sintaxe HQML para Especificao de QoS da Camada de Usurio ...........33
4.3 - Sintaxe HQML para Especificao de QoS da Camada de Aplicao ........34
4.4 - Sintaxe HQML para Especificao de QoS da Camada de Recursos .........36
5 - Ambiente para Especificao de Aplicaes Multimdia com Suporte de Qualidade
de Servio........................................................................................................................39
5.1 - Viso Geral da Arquitetura .............................................................................40
5.2 - Editor Visual de QoS Hierrquico ..................................................................42
5.3 - ConfigG: Gramtica Especial de Relao de Smbolo Limitada .................45
5.4 - Gerador de HQML ...........................................................................................47
IX
5.5 - Executor HQML ...............................................................................................48

5.6 - Mdulo Sistema Multimdia ............................................................................51
5.7 Trabalhos Correlatos .......................................................................................54
6 - Estudo de Caso: Uma Aplicao de Vdeo Sob Demanda ......................................56
7 Concluses e Trabalhos Futuros.............................................................................65
Referncias Bibliogrficas.............................................................................................67
Apndice A Cdigo do Proxy ......................................................................................74
Classe Connection..........................................................................................................74
Classe ProxyTunnel .......................................................................................................76
Classe Server ..................................................................................................................78
Classe ControlServer......................................................................................................79
Classe Controller............................................................................................................80
Classe ControllerGUI.....................................................................................................81
Apndice B Conjunto Completo de Regras de Produo da ConfigG ......................86
Apndice C Cdigo HQML especificado no Estudo de Caso ....................................95
Apndice D Tabela 6 .................................................................................................100
Lista de Figuras
FIGURA 1: MODELO CONCEITUAL DE QOS. ........................................................................7
FIGURA 2: REQUISITOS DE ARMAZENAMENTO PARA ALGUMAS MDIAS. ...........................12
FIGURA 3: ESQUEMA FUNCIONAL DO CONTROLE DA QUALIDADE DE SERVIO.................15
FIGURA 4: CONFIGURAO DA APLICAO PARA APLICAO DE VOD............................31
FIGURA 5: ORGANIZAO HIERRQUICA DO HQML. ......................................................32
FIGURA 6: EXEMPLO DE ESPECIFICAES HQML NA CAMADA DE USURIO. .................34
FIGURA 7: EXEMPLO DE ESPECIFICAES HQML NA CAMADA DE APLICAO. .............36
FIGURA 8: EXEMPLO DE ESPECIFICAES HQML NA CAMADA DE RECURSO..................38
FIGURA 9: ARQUITETURA DO AMBIENTE PARA ESPECIFICAO DE APLICAES
MULTIMDIA COM SUPORTE DE QOS........................................................................41
FIGURA 10: EDITOR VISUAL DE QOS HIERRQUICO. .......................................................43
FIGURA 11: CAIXA DE DILOGO REFERENTE AO SOFTWARE DO CLIENTE..........................44
FIGURA 12: CAIXA DE DILOGO REFERENTE AO HARDWARE DO CLIENTE. .......................45
FIGURA 13: EXEMPLOS DE GRAFOS DE CONFIGURAES INCORRETOS............................46
FIGURA 14: ESTRUTURA DA APLICAO DE VDEO SOB DEMANDA. ...............................49
FIGURA 15: INTERFACE GRFICA PARCIAL DO EMULADOR NIST NET (XNISTNET)..........53
FIGURA 18: CAIXA DE DILOGOS REFERENTE A CLASSE DE APLICAO E A QUALIDADE DE
SERVIO EXIGIDOS NA CAMADA DE USURIO...........................................................57
FIGURA 19: DESCRIO DE UMA APLICAO DE VDEO SOB DEMANDA NO EDITOR VISUAL
DE QOS HIERRQUICO. ............................................................................................58
FIGURA 20: (A) HARDWARE DO SERVIDOR, (B) SOFTWARE DO SERVIDOR, (C) HARDWARE
DO CLIENTE E (D) SOFTWARE DO CLIENTE...............................................................59
FIGURA 21: IMAGENS COM APLICAO DE FILTROS. (A) IMAGEM ORIGINAL. (B) IMAGEM
COM APLICAO DO FILTRO QSCALE 15 AB 64. (C) IMAGEM COM APLICAO DO
FILTRO QSCALE 30 AB 32..........................................................................................64
XI
Lista de Tabelas
TABELA 1: TAXA DE BITS DE ALGUMAS APLICAES DE UDIO E VDEO..........................11
TABELA 2: QOS PARA AS TRS CAMADAS: USURIO, APLICAO E RECURSO................19
TABELA 3: COMPARAO DA CAMADA DE APLICAO DAS LINGUAGENS DE
ESPECIFICAO DE QOS...........................................................................................26
TABELA 4: COMPARAO ENTRE DIFERENTES LINGUAGENS DE ESPECIFICAO DE QOS.
.................................................................................................................................27
TABELA 5: VALORES DOS PARMETROS E OS RESPECTIVOS FILTROS APLICADOS. ............62
XII
1 - Introduo
O termo multimdia definido em [1] usado para se referir a mltiplos
tipos de mdia, tecnologias, sistemas e aplicaes que manipulam vrias mdias. Ainda
em [1] sistema multimdia definido como um sistema capaz de manipular pelo menos
um tipo de mdia contnua na forma digital, ou mdia esttica.
J sistemas multimdia distribudo so sistemas que lidam com mdias
contnuas e as processam de maneira distribuda, isto , o sistema formado por
elementos que se interagem a fim de fornecer determinado servio de maneira
satisfatria, como vdeo sob demanda e teleconferncia.
As infra-estruturas que suportam os sistemas multimdia distribudos
oferecem servios com reservas de recursos ou garantias que o desempenho no seja
prejudicado em virtude de variao nas condies do ambiente.
Num sistema multimdia distribudo os servios requisitados para a infraestrutura do ambiente devem ser tratados de forma global. A aplicao requisita os
recursos que esto disponveis no momento da execuo, de forma a garantir a melhor
qualidade possvel. Esses recursos dependem do meio de acesso da aplicao (PDA,
desktop, celular, etc.), da rede de comunicao (Ethernet, ATM, wireless, etc.) e dos
sistemas de processamento da mdia (codificador, decodificador, prefetcher, etc.). Podese utilizar alguns parmetros mnimos na requisio de tais servios, como a exigncia
de uma dada qualidade na transmisso, recepo e execuo da mdia, de forma que tais
Captulo 1 Introduo
servios sejam oferecidos pela infra-estrutura para atender esta requisio mais
abrangente.
nesse contexto que surge a Qualidade de Servio como o conjunto de
caractersticas de um sistema necessrio para atingir uma determinada funcionalidade
por meio da aferio de parmetros pr-definidos antes de iniciar a execuo da
aplicao, sendo que a aplicao possui capacidade de renegociao durante sua
execuo.
As requisies dos servios necessitam que os recursos e os prprios
servios oferecidos estejam em conformidade para que a infra-estrutura possa atender o
que foi determinado na aplicao com a Qualidade de Servio desejada pelo usurio.
Portanto, a QoS torna-se imprescindvel nesse contexto, pois ela delimita os padres
mnimos exigidos para os requisitos do usurio, bem como evidencia se o servio foi
bem sucedido ou no.
A descrio da QoS em uma aplicao multimdia pode ser feita numa
linguagem de especificao de Qualidade de Servio. Tais linguagens so responsveis
por aproximar o desenvolvedor da aplicao aos recursos do sistema, sem preocuparse com a complexidade da implementao. Alm disso, facilita o entendimento dos
meios envolvidos nas transmisses de dados das aplicaes multimdia distribudas.
As linguagens de especificao, tanto as de especificao de sistemas,
como as de especificao de QoS, surgiram devido s diferenas existentes entre os
sistemas operacionais, as redes de comunicao, as preferncias dos usurios, as
aplicaes e, ainda, ao dinamismo no uso dos recursos de um sistema. Enquanto as
linguagens de especificao de sistemas agregam caractersticas capazes de descrever o
sistema multimdia distribudo como um todo, desde os requisitos fsicos do sistema at
parmetros de QoS, as linguagens de especificao de QoS descrevem somente
parmetros ligados a QoS.
O objetivo desse trabalho construir um ambiente para especificao de
aplicaes multimdia distribuda com detalhamento da Qualidade de Servio exigida, a
Captulo 1 Introduo
fim de analisar os resultados dessa especificao por meio de um sistema multimdia

distribudo emulado utilizando o emulador Nist Net.
O ambiente tambm oferece a possibilidade de insero de parmetros de
QoS que funcionam como reguladores da Qualidade de Servio, caso seja necessria a
adaptao e a (re)negociao da QoS envolvida. Com isso, pretende-se abordar
principalmente esses mecanismos de adaptao e a possvel renegociao dos
parmetros, para comprovar o ineditismo desses recursos por meio de um estudo de
caso, ou seja, uma aplicao de vdeo sob demanda.
O desenvolvimento deste trabalho iniciou com um levantamento
bibliogrfico sobre QoS, linguagens de especificao de QoS para sistemas multimdia
distribudos e ambientes de descrio de sistemas multimdia, objetivando a
especificao do ambiente proposto. Esse ambiente de especificao, alm de permitir o
detalhamento do Sistema Multimdia com relevncia aos aspectos de qualidade de
servio, permite a implementao de novos recursos, como adaptao e (re)negociao.
O ambiente implementado uma extenso da proposta QoSTalk [2] e da linguagem de
especificao de QoS HQML, com as funcionalidades descritas acima. Os testes do
ambiente foram realizados com uma aplicao multimdia distribuda de vdeo sob
demanda, que foi emulado no Nist Net [50] . Os testes evidenciaram a viabilidade do
ambiente com recursos implementados e emulados, com ganhos em tempo de
desenvolvimento e na clareza do processo.
O contedo deste trabalho est organizado da seguinte forma:
No captulo 2 apresentada a conceituao de Qualidade de Servio,
enumerando as prerrogativas inerentes ao escopo de sistemas multimdia distribudos
adotados no mbito deste trabalho.
No captulo 3 so apresentadas linguagens de especificao de QoS para
aplicaes multimdia distribudas, bem como a anlise comparativa das linguagens
levando-se em considerao aspectos de reusabilidade, expressividade, independncia,
declaratividade e extensibilidade.
Captulo 1 Introduo
O captulo 4 descreve a linguagem de especificao de sistemas proposta

e utilizada neste trabalho, baseada na linguagem HQML [2]. Apresenta ainda o modelo
bsico de aplicao e suas caractersticas e vantagens na utilizao da mesma na
descrio de um sistema multimdia distribuda com garantia de QoS.
No captulo 5 apresentado o Ambiente para Especificao de
Aplicaes Multimdia com Suporte de Qualidade de Servio proposto. So descritos os
aspectos da arquitetura e os recursos do sistema.
Um estudo de caso apresentado no captulo 6, com o detalhamento de
todos os passos utilizados na modelagem de uma aplicao multimdia e sua utilizao
em sistema emulado, bem como os resultados obtidos.
No captulo 7 so apresentadas as concluses deste trabalho e propostas
futuras para extenso.
2 - Qualidade de Servio
2.1 - Definio
Apesar de Qualidade de Servio (QoS) no ser um conceito novo,

atualmente este termo tem sido muito abordado em pesquisas que se referem a
utilizao de aplicaes multimdia que precisam de alguma garantia na efetivao do
servio desejado.
O primeiro problema existente ao lidar com QoS a definio do termo,
haja vista que vrios rgos internacionais de padronizao utilizam uma definio
prpria como escopo para determinar a evoluo dos estudos que envolvem QoS. Por
isso, no existe uma definio formal ou comum do que QoS. Um grande nmero de
definies pode ser encontrado na literatura, nas quais a noo de QoS originalmente
serve para descrever certas caractersticas tcnicas da transmisso dos dados,
principalmente dados que no so dependentes do tempo, como dados de mdia
discretos (texto e figuras).
Neste trabalho a definio que melhor descreve as aspiraes buscadas,
baseia-se em [3] e [4], chegando concluso de que QoS o conjunto de caractersticas
de um sistema (aplicao) necessrio para atingir uma determinada funcionalidade
atravs da aferio de parmetros pr-definidos antes de iniciar a execuo da aplicao,
sendo que a aplicao possui capacidade de renegociao durante sua execuo.
Captulo 2 Qualidade de Servio
Abaixo esto algumas definies no nvel de comunicao utilizadas

pelos vrios rgos de padronizao do mundo das telecomunicaes, padres
internacionais e padres Internet [5]:
O International Telecommunication Union (ITU), refere-se a QoS
como "Um conjunto de requisitos de qualidade de comportamento coletivo de um ou

mais objetos". Alguns parmetros de QoS descrevem rapidez e confiabilidade na
transmisso dos dados, por exemplo, vazo, atraso e taxa de erro;
A ATM Lexicon define em [6] QoS como "Um termo que se
refere a um conjunto de parmetros de desempenho ATM que caracteriza o trfego

sobre uma dada conexo virtual". Parmetros de QoS aplicam-se principalmente s
camadas do protocolo nos nveis mais baixos, no sendo diretamente observveis ou
verificveis pela aplicao. Esses parmetros incluem taxa de clulas perdidas, taxa de
clulas erradas, taxa de falhas durante a insero de clulas na rede, variao do atraso
das clulas, atraso na transferncia da clula, e mdia de atraso na transferncia das
clulas;
J em [7], os autores definem que Qualidade de Servio um
requisito que uma classe de aplicaes possui. Isso exige que uma srie de parmetros
esteja dentro de uma faixa de valores bem definidos, para o seu perfeito funcionamento.
Alm dessas definies, vrias outras podem ser encontradas na
literatura. Uma definio mais geral de QoS para aplicaes que se comunicam em
tempo real dada por Vogel et al. [8], descreve Qualidade de Servio como a
representao do conjunto daquelas caractersticas qualitativas e quantitativas de um
sistema multimdia distribudo necessrias para obter funcionalidades requeridas pela
aplicao. Funcionalidades incluem a apresentao de dados multimdia para o usurio,
bem como sua satisfao.
Outras definies de QoS incluem: um conjunto de parmetros que
define as propriedades dos streams1 [9]; uma descrio quantitativa de quais servios
oferecidos pelo sistema satisfaz as necessidades da aplicao expressa como um
conjunto de pares de parmetros [10].
1
Streams: fluxos de dados multimdia.
2.2 - Mapeamento de QoS
Dobson em [11] trata QoS em sistemas multimdia distribudos,

primeiramente, a partir do desempenho de toda a rede e, posteriormente, a servios de
caractersticas no-funcionais. J Bernet et al. em [12] descreve um framework para
aplicaes que requerem controle de QoS. Nesse trabalho foi utilizada uma modelagem
apresentada por Nahrstedt em [13], em que os parmetros de QoS podem ser divididos
conceitualmente em camadas, que podem ser observadas na Figura 1. A Camada de
Usurio descreve a Qualidade de Servio do usurio referentes aos anseios, bem como a
Camada de Aplicao descreve a QoS para a aplicao, porm a Camada de Recurso
descreve QoS nos nveis do Sistema Operacional e da rede. Os parmetros das QoS de
Usurio, Aplicao, Sistema e Rede so apresentados nos itens a seguir.
Figura 1: Modelo conceitual de QoS.
2.2.1 - QoS de Usurio

Os parmetros de qualidade relacionados diretamente aos usurios so
necessariamente menos tcnicos e mais subjetivos, normalmente mensurados de forma
qualitativa. Uma interface apropriada deve ser oferecida para facilitar a escolha dos
parmetros [13].
A essncia dessa camada ocultar, tanto quanto possvel, os parmetros
de QoS inerentes ao sistema (freqentemente sem significado para o usurio). Para isso,
devem-se apresentar exemplos que permitem realizar escolhas como tamanhos de
imagem e resoluo diferentes, ou udio com qualidade de CD ou telefone. Em um
sistema, cada uma das escolhas anteriores impactam nas exigncias de QoS de rede. Por
exemplo, a seleo de uma imagem de alta resoluo pode resultar em um aumento de
largura de banda capaz de suportar tais imagens. Alm disso, aspectos como tamanho da
janela (grande, mdia, pequena), preo do modelo (taxa de flat, carga por transmisso
de bytes) e variao de preo (alta, mdia, baixa) tambm so parmetros relevantes
nessa camada.
Uma outra possibilidade permitir que o usurio escolha a QoS como
alta, mdia, baixa ou qualquer dentro de uma classe de aplicao e essa escolha seja
refletida nas camadas inferiores.
2.2.2 - QoS de Aplicao

Nessa camada so descritos os requisitos para a aplicao em termos de
qualidade da mdia e relacionamento entre mdias (sincronizao intermdia e
intramdia). Escolhas realizadas pelo usurio final, na QoS na camada de usurio, so
mapeadas em um conjunto de parmetros de aplicao, os quais devem atender seus
anseios.
Nesse nvel, os parmetros so associados a quadros de vdeo (tamanho
do quadro, taxa de quadros/segundo), ou amostras (taxa de amostragem,
bits/amostragem), etc. Como exemplo, pode ser citado um vdeo com quadros de 640
8
pixels por 480 pixels com taxa de 30 quadros por segundo. Alm disso, parmetros
como tamanho do frame do vdeo, taxa de frame do vdeo, resoluo de udio/imagem e
regras de adaptao so parmetros relevantes nessa camada. Ainda deve ser ressaltado
que parmetros como atraso e variao do atraso, normalmente tratados como
parmetros de rede, podem ser analisados nessa camada, haja vista a necessidade da
aplicao de ter garantias quanto aos valores desses parmetros. Esses parmetros so
mapeados para a Camada de Recurso a fim de serem alocados recursos fsicos
necessrios para a garantia de que os valores dos parmetros sero alcanados no nvel
da aplicao.
2.2.3 - QoS de Sistema (Software e Hardware)
Os parmetros dessa camada representam caractersticas de cada host

presente no sistema, as quais podem ser especificadas em termos de critrios
quantitativos e qualitativos, sendo os quantitativos representados pelo hardware e os
qualitativos tratados pelo sistema operacional de cada mquina. Os critrios
quantitativos so aqueles que podem ser avaliados em termos de medidas concretas,
como bits por segundo, tempo de processamento de uma tarefa, e tamanho da unidade
de dados. Os critrios qualitativos especificam os servios esperados, como
sincronizao, mecanismos de escalonamento e recuperao de erros.
Os parmetros, nesse nvel, podem ter um grande impacto na qualidade
percebida pelo usurio. Por exemplo, a velocidade do barramento, memria disponvel e
tempo de CPU podem limitar a taxa de quadros da apresentao de um vdeo, bem
como uma tela que apresenta imagens em preto e branco no pode mostrar imagens
coloridas.
Em se tratando de imagens, a forma de armazenamento ocorre
calculando-se o nmero de cada pixel (H) em cada linha, vezes o nmero de linhas da
imagem (V) e a profundidade do pixel P (bits por pixel), divididos por 8 [14]:
Armazenamento (em Bytes, MBytes, GBytes) = HVP/8
9
Por exemplo, se uma imagem tem 480 linhas, 600 pixels em cada linha e
uma profundidade de pixel de 24 bits, necessrio 864.000 bytes para represent-la.
Para uma nica imagem no preciso dimensionar o tempo de
armazenamento, porm se h um tempo limite para a transmisso de cada imagem, a
largura de banda pode ser calculada baseado no armazenamento da mdia. Por exemplo,
se a imagem de 864.000 bytes deve ser transmitida com um tempo de 2 segundos, ento
a largura de banda necessria de 3.456 Mbits/s. Em muitas aplicaes, imagens podem
ser mostradas em sincronia com uma mdia contnua, como o udio. Neste caso, a
transmisso de imagens impe restries de tempo e largura de banda.
Tanto o udio quanto o vdeo so mdias contnuas. Para calcular a taxa
de bits transmitidas em um segundo por um arquivo de udio deve-se basear na taxa de
amostras e nmero de bits por amostra. A taxa de bits para arquivos de vdeo pode ser
calculada da mesma forma que no udio, porm normalmente calculada a partir da
quantidade de dados em cada imagem (quadro ou frame) vezes o nmero de quadros por
segundo. O nmero resultante desse clculo especifica tanto a taxa de bits necessitada
pelo canal de transmisso quanto a taxa de transferncia do dispositivo de
armazenamento.
A Tabela 1 [14] apresenta os requisitos de largura de banda de mdias
contnuas (udio e vdeo) de diferentes qualidades. J a Figura 2 [14] mostra os
requisitos de armazenamento para mdias estticas e mdias contnuas de diferentes
duraes. Obviamente que os dados expostos na Figura 2 dependem de fatores como
tamanho da imagem e as representaes de cores e no so consideradas mdias
comprimidas.
10
Aplicaes
CD-udio
Taxa de Dados (kbit/s)

1.411,2
DAT
1.536
Telefone Digital
64
Televiso-Qualidade do Vdeo
216.000
VHS-Qualidade do Vdeo
54.000
HDTV
864.000
Tabela 1: Taxa de bits de algumas aplicaes de udio e vdeo. [Willrich, 2004]
Na Tabela 1 e na Figura 2 possvel perceber que as mdias digitais

necessitam de grande quantidade de dados para serem representadas, alm de farta
largura de banda para a transmisso. Por meio dos dados descritos tanto na Tabela 1,
como na Figura 2, pode-se calcular que em um mdia de 1.5 horas de udio com
qualidade de CD, ou 36 segundos de vdeo com qualidade de TV precisam de 1 GB para
ser armazenada. Essa quantidade de dados precisaria de 800 segundos para ser
transferida com uma taxa de 10 Mbits/s.
11
Figura 2: Requisitos de armazenamento para algumas mdias. [Willrich, 2004]
2.2.4 - QoS de Rede

Os requisitos dos servios de rede so abordados nessa camada, por
exemplo, o desempenho, associados a propriedades de pacotes ou bits, tais como, atraso
de pacotes, ou taxa de bits. Nesse nvel, parmetros fim-a-fim (delay, jitter e perda de
pacotes) so especificados.
Para aplicaes multimdia, por exemplo, a rede deve satisfazer os
requisitos de transmisso de dados multimdia. O trfego de mdia discreta
(transferncia de arquivos ou recuperao de imagens) requer servios livres de erros,
mas tolerante a atrasos. O trfego de mdia contnua requer tempo real e transmisso
de alta velocidade para um bom desempenho de aplicaes. Essa mdia sensitiva a
atrasos e suas variaes, mas tolerante a perdas ocasionais de pacotes. A rede deve
suportar os requisitos especificados pela aplicao.
12
udio e vdeo digitais so mdias contnuas dependentes do tempo, e por

isso so chamadas mdias dinmicas ou iscronas. Isso significa que para ter uma boa
qualidade quando executados o udio e o vdeo devem ter taxas de amostragens com
intervalos regulares. Por exemplo, se uma parte do udio tem taxa de amostragem de
8kHz, o mesmo deve ser executado com 8.000 amostras por segundo. Essa dependncia
em relao ao tempo das mdias contnuas implica diretamente na existncia de dois
parmetros: o atraso (delay) e a variao do atraso (jitter).
O atraso, comumente tratado como atraso fim-a-fim, a soma de todos
os atrasos em todos os componentes do sistema multimdia, incluindo acesso ao disco,
ADC2, codificao, tempo de processamento, acesso rede, transmisso na rede,
bufferizao, decoficao e DAC3. Um atraso aceitvel algo muito subjetivo e tambm
dependente da aplicao. Por exemplo, de acordo com Gopal et al. [15] e Hehmann et
al. [16] o atraso em aplicaes do tipo conversacional [17] deve ser abaixo de 300 ms,
porm para aplicaes do tipo apresentacional [17] o atraso de alguns segundos
aceitvel.
A variao do atraso, ou jitter a variao do intervalo de tempo entre
chegadas de pacotes no receptor. Para uma transmisso de mdia contnua sem
problemas, a variao do atraso deve ser mantida bem pequena. Por exemplo, de acordo
com Hehmann et al. [16] para transmisses de udio com qualidade de telefone e vdeo
com qualidade de televiso, a variao do atraso deve ser menor do que 10 ms, porm
para aplicaes de udio de alta qualidade esse valor cai para menos de 1 ms.
Diferentes dos dados alfanumricos, onde perdas e erros na transmisso
so na sua grande maioria intolerveis. Erros ou perdas em dados de udio, vdeo e
imagens podem ser tolerados, pois estas perdas e erros de bits no so desastrosos e
geralmente no so percebidos pelo usurio.
Para voz, tolera-se uma taxa de erros de bit de 10-2. Para imagens e
vdeos pode-se tolerar uma taxa de bits de 10-4 a 10-6. Outro parmetro que mede o erro
a taxa de perda de pacotes. Os requisitos de taxa de perdas de pacote so mais fortes
2
3
ADC (Analog to Digital Converter): converso de analgico para digital. [18]

DAC (Digital to Analog Convertor): converso de digital para analgico. [19]
13
que a de erros de bit, porque uma perda de pacote pode afetar a decodificao de uma
imagem, por exemplo. Quando tcnicas de compresso so utilizadas a taxa de erro de
bits deve ser pequena, pois um erro de bit pode causar um erro de descompactao de
muitos bits. Tcnicas de encobrimento de erros podem ser empregadas para aumentar a
qualidade de udio e vdeo.
2.3 - Abordagem
Considerando QoS como sendo o conjunto de caractersticas que um

sistema necessita para que a sua funcionalidade possa ser aferida por parmetros
predefinidos, apresenta-se a delimitao do processo de execuo do sistema que se d
da forma mostrada na Figura 3: o processamento de QoS num sistema distribudo
comea com o estabelecimento dos parmetros exigidos pelo usurio. Como definido na
seo 2.2.1, os parmetros so relevantes ao que o usurio julga necessrio para
satisfazer os seus anseios. Esses parmetros so mapeados e negociados entre os
componentes do sistema como um todo, assegurando que todos podem atingir um nvel
de QoS aceitvel. Nesse ponto, os componentes verificam os parmetros definidos na
Camada de Aplicao, pois, deve haver conformidade entre os requisitos escolhidos
pelo usurio na camada superior com os requisitos da aplicao. Recursos so, ento,
alocados e monitorados, havendo possibilidade de renegociao caso as condies do
sistema se alterem. Em havendo a necessidade de uma renegociao, novos parmetros
de QoS so remapeados para os componentes a fim de que possa ser garantida a QoS
aceitvel pelo sistema. A alocao de recursos, bem como a (re)negociao baseada em
regras de adaptao, acontecem mediante parmetros mapeados para a Camada de
Recurso.
14
Figura 3: Esquema funcional do controle da Qualidade de Servio.
Os parmetros de QoS devem ser escolhidos de acordo com o ambiente

usado, pois devido s suas caractersticas particulares, redes fixas e redes mveis sem
fio, por exemplo, necessitam negociar parmetros diferentes. Os parmetros de QoS do
ponto de vista da aplicao so mais subjetivos pois tratam, por exemplo, se a imagem
em uma videoconferncia deve ser em cores ou em preto-e-branco, se o som deve ter
qualidade de telefone ou de CD, se pode haver ou no interrupo da comunicao
durante um handoff4, entre outras coisas. Deste modo, esse trabalho apresenta um
mecanismo que traduza tais desejos em parmetros de mais baixo nvel os quais possam
ser negociados pelas entidades de rede, tais como taxa de transmisso ou atraso.
Portanto, QoS algo que deve ser tratado por todo o sistema [20].
Handoff: Em sistemas mveis celulares, o processo de transferir uma chamada em andamento de uma
clula transmissora e receptora com uma freqncia definida para uma outra clula transmissora e
receptora usando uma freqncia diferente [21].
15
Aps a escolha dos valores dos parmetros de QoS pela aplicao e sua
posterior traduo em parmetros que o sistema possa compreender, deve-se
efetivamente iniciar a negociao com os elementos do sistema envolvidos para
verificar se possvel prover a qualidade desejada.
Se a negociao com os elementos do sistema for bem sucedida,
preciso que os recursos necessrios para que se garantam a QoS sejam reservados ao
longo do caminho da comunicao. Durante a comunicao deve-se monitorar tambm
a QoS e, caso seja violada, tomar as providncias necessrias. Alm disso, ao longo da
comunicao a aplicao deve poder renegociar parmetros de QoS.
Como a QoS garantida s aplicaes por meio de reserva de recursos
ao longo da rede, como largura de banda, buffers nos roteadores, ciclos de CPU, entre
outros, torna-se importante que no haja desperdcio de recursos, pois deste modo,
pode-se atender a mais usurios simultaneamente. Esta racionalidade no uso dos
recursos tambm importante devido ao fato de que o usurio estar eventualmente
pagando pela sua utilizao e, portanto, deve-se procurar minimizar os custos.
Embora existam muitas solues para a utilizao de QoS em sistemas
multimdia distribudos, os desenvolvedores de aplicao ainda no conseguiram criar
aplicaes multimdia com QoS embutida, especialmente para aplicaes Web [22]. A
razo est situada no fato de que no existe uma linguagem de especificao de QoS
universal. Mesmo existindo as mais diversas linguagens de especificao de QoS, elas
ainda esto muito ligadas com uma linguagem de programao especfica ou no podem
ser estendidas para alcanar rapidamente os novos servios de QoS. Dessa forma,
necessrio que haja uma anlise das linguagens de especificao de QoS e das
necessidades do desenvolvedor da aplicao, a fim de que todos os requisitos do usurio
possam ser expressos na especificao de QoS. O captulo a seguir apresenta uma
anlise comparativa das linguagens de especificao de QoS.
16
3 - Linguagens de Especificao de Qualidade de Servio para

Aplicaes Multimdia Distribudas
Tipicamente, o gerenciamento de aplicaes multimdia distribudas

requer que, antes de iniciar a execuo, uma aplicao determine seus requisitos de QoS
por meio de parmetros como taxa de apresentao, qualidade de imagem e som. Esses
requisitos so ento traduzidos em um conjunto de recursos do sistema (tais com largura
de banda de transmisso, memria ou ciclos de CPU por segundo) alocados para a
aplicao. Um processo de negociao da QoS, juntamente com uma infra-estrutura de
gerenciamento, garante o fornecimento da QoS requerida durante a execuo da
aplicao, por meio de reserva de recursos.
A QoS envolve um grande nmero de propriedades, como caractersticas
de desempenho, disponibilidade, capacidade de obter resposta em um tempo
determinado, segurana e versatilidade, alm dos aspectos especficos da aplicao. Em
relao s especificaes de QoS [23], tem-se:
devem permitir descries de parmetros de QoS quantitativos e
qualitativos, assim como regras de adaptao;
devem ser informativas, isto , devem especificar somente o que
requisitado pelo usurio, porm no como a requisio deve ser executada pela
aplicao;
17
Captulo 3 Linguagens de Especificao de QoS para Aplicaes Multimdia

Distribudas
precisam ser acompanhadas por um processo de mapeamento e
compilao para poder mapear a especificao de QoS para dar suporte a polticas e a
mecanismos do sistema.
Devido s diferenas existentes entre os sistemas operacionais, as redes
de comunicao, as preferncias dos usurios, as aplicaes e, ainda, ao dinamismo no
uso dos recursos de um sistema, torna-se imprescindvel especificar propriamente as
necessidades e polticas de adaptao da QoS para a entrega e o processamento
multimdia.
Para satisfazer essa tarefa complexa, muitas linguagens de especificao
de QoS surgiram para suprir essas necessidades. Com tantas especificaes de QoS
existentes, que passam por vrias camadas de QoS e paradigmas de linguagens, h uma
forte necessidade de categoriz-las e organiz-las para que se obtenha um amplo e
criterioso entendimento sobre esta importante rea.
A metodologia para analisar o conjunto de linguagens de especificao
de QoS pode empregar a diviso e conquista, como estudado por Jin e Nahrstedt [23],
em que foi particionado o conjunto em paradigmas de acordo com as propriedades
especficas e avaliada cada paradigma separadamente, assim como foram estudadas as
relaes entre esses paradigmas.
A QoS em sistemas multimdia deve ser assegurada no somente na
camada de rede, mas tambm nos sistemas finais, como por exemplo os sistemas
operacionais e dispositivos perifricos. Por essa razo, a especificao de QoS foi
introduzida para sistemas finais e aplicaes [24]. Baseado nesse desenvolvimento, as
linguagens de especificao de QoS podem ser divididas primeiramente em camadas de
acordo com o sistema final a que elas pertencem [25], [26], e ento em paradigmas
baseados em suas propriedades.
18

Distribudas
3.1 - Particionamento das Linguagens de Especificao de QoS em

Camadas
O particionamento em camada necessrio porque especificaes em

camadas diferentes apresentam muitas caractersticas diferentes. So consideradas 3
camadas: Camada de Usurio, Camada de Aplicao e Camada de Recursos.
Como um simples exemplo para ilustrar o modelo de especificao de 3
camadas, pode-se considerar uma aplicao de Vdeo Sob Demanda em que o usurio
quer um vdeo localizado num servidor remoto. Nestes casos, o usurio pode
especificar, geralmente sobre uma Interface Grfica (GUI), a qualidade de mdia
desejada para o servio de Vdeo Sob Demanda entre o conjunto de escolhas, como,
alta, mdia e baixa qualidade, baseada na percepo humana. Esta especificao ento
passada para a camada da aplicao para derivar especificaes de qualidade de mdia
mais concreta, como taxa de quadro do vdeo e resoluo imagem/udio. Essas so
especificaes inerentes aplicao, mas com descries independentes de plataforma e
hardware.
Camadas de QoS
Camada de Usurio (critrios subjetivos)
Camada da Aplicao (independente de hardware

e plataforma)
Camada de Recurso (dependente de hardware e

plataforma)
Parmetros/Questes de QoS
- Qualidade de mdia percebida (excelente, bom,
regular, ruim)
- Tamanho da janela (grande, mdia, pequena)
- Preo do modelo (taxa de flat, carga por
transmisso de bytes)
- Variao de preo (alta, mdia, baixa)
- Atributos de QoS especficos aplicao
(tamanho do frame do vdeo, taxa de frame do
vdeo, resoluo de udio/imagem, sincronizao
inter/intrastream)
- Regras de adaptao
- Questes quantitativas (vazo, atraso, jitter,
tamanho da memria, tempo de requisio do
recurso)
- Questes qualitativas (escalonamento do Sistema
Operacional, estilo da reserva do recurso,
mecanismos de deteco/recuperao de perda)
- Regras de adaptao
Tabela 2: QoS para as trs camadas: Usurio, Aplicao e Recurso.
19

Distribudas
Sistema operacional e servios de comunicao so especificados
quantitativa e qualitativamente, onde descries quantitativas podem incluir vazo,
atraso, jitter, tamanho de buffer, e sincronizao da distoro de imagem, ao passo que
descries qualitativas podem incluir polticas de escalonamento de CPU e mecanismos
de recuperao de erros de transmisso. Um resumo das camadas de QoS e alguns de
seus parmetros so apresentados na Tabela 2 [23].
3.2 - Particionamento das Linguagens de Especificao de QoS em

Paradigmas
As linguagens de especificao de QoS podem ser classificadas de
acordo com suas propriedades e com as camadas de especificao da Modelagem. Na
Camada de Usurio no h linguagens de especificao representativas, uma vez que
seus requisitos so de carter cognitivo. As especificaes da Camada de Aplicao
divididas quanto aos seus paradigmas (baseada em script, baseada em parmetro,
orientada a processo, baseada em controle lgico, orientada a aspectos e baseada em
markup), enquanto as especificaes da camada de recursos baseiam-se nas suas
granularidades (grossa e fina). De acordo com Jin e Nahrstedt as principais linguagens
de especificao, de acordo com o seu paradigma so descritas a seguir.
3.2.1 - Paradigma baseado em script
As linguagens baseadas em script so mais abstratas do que as

linguagens imperativas, assim podem ser usadas para especificar objetos em um nvel
elevado, sem ter que revelar muitos detalhes. Roscoe e Bowen [27] apresentam uma
tcnica que adiciona suporte de QoS para o Windows NT sem modificar as aplicaes
ou os componentes do sistema operacional. Nessa soluo h a adio de uma parte de
software, chamada agente do protocolo, na pilha do protocolo winsock. O agente do
20

Distribudas
protocolo intercepta as chamadas feitas pela aplicao rede, e ento contata o daemon5
de poltica, O detalhamento das polticas so expressas pela linguagem Safe-Tcl [28],
para aprender como marcar os pacotes da rede de acordo com a descrio dada pelo
script de QoS. Nesse exemplo, a linguagem Safe-Tcl foi usada somente para instruir o
agente do protocolo como marcar os pacotes da rede, e tambm mostra como
especificaes podem ser escritas separadamente das aplicaes, mostrando assim uma
boa independncia.
3.2.2 - Paradigma baseado em parmetro
Muitas das aplicaes com QoS embutidas atuais, ao especificar a

Camada de Aplicao de QoS, usam este
paradigma. Neste paradigma, os
desenvolvedores de aplicao definem estruturas de dados para expressar e declarar

parmetros qualitativos e quantitativos, sem criar uma nova linguagem de especificao
de QoS. Um exemplo de linguagem com paradigma baseado em parmetro QoS-A
[29], em que usada uma Arquitetura de Qualidade de Servio (QoS-A) para tentar
garantir a QoS tanto nos sistemas finais quanto nas redes de uma maneira uniforme. Por
exemplo, em uma especificao de parmetro de QoS entre duas partes se comunicando,
deve-se definir um contrato de servio que inclui diversos aspectos: especificao do
fluxo, comprometimento de QoS, adaptao de QoS, manuteno de QoS, tipo de
reserva e custo. O contrato de servio implementado como em uma estrutura da
linguagem C, e cada clusula representada como uma outra estrutura. Dessa forma, o
conjunto de construes de QoS torna-se bastante rico, fazendo a API boa em termos de
expressividade, sendo possvel acrescentar novas construes de QoS sem dificuldade.
QoS-A permite tambm que os contratos sejam desenvolvidos independentemente das
aplicaes. Como os parmetros de QoS e as aes so especificados como estruturas,
QoS-A no fornecem facilidades especiais para reuso da especificao.
Daemon: processo executado em segundo plano que realiza operaes em perodos predefinidos ou em
resposta a determinados eventos.
21

Distribudas
3.2.3 - Paradigma orientado a processo
O paradigma orientado a processo supe o modelo, em que os processos,

como unidades de execuo, se comunicam e se sincronizam um com o outro pela
passagem de mensagens, ou portas de comunicao. A especificao de QoS orientada a
processo permite associar QoS com as portas finais de comunicao, e tambm
expressar a negociao de restrio de QoS e a monitorao de QoS entre duas portas.
Um exemplo de linguagem de especificao de QoS baseada em processo QuAL [30].
QuAL uma extenso de Concert/C, e suas construes fornecem meios para a
especificao e a negociao de restries de QoS, especificao de gerenciadores de
violao de QoS, e configurao da monitorao de QoS. QuAL tem uma boa
expressividade e fcil para se desenvolver novas construes de QoS quando
necessrio. Entretanto, as especificaes escritas em QuAL so espalhadas atravs do
cdigo funcional, tornando as duas partes (cdigo funcional e especificao de QoS)
difceis de se fazer manuteno. Alm disso, a linguagem mais instrutiva do que
declarativa, que deve ser uma caracterstica natural de toda a linguagem de
especificao.
3.2.4 - Paradigma baseado em controle lgico
As linguagens baseadas em controle lgico so adotadas em sistemas

adaptveis para especificaes de QoS de polticas e do controle de fluxo adaptveis
[31]. Alguns sistemas usam tcnicas do controle adaptvel tais como o controlador de
PID (Proporcional-Integral-Derivative) para especificar e controlar a granularidade fina
quando escalonar fluxos ou tarefas. Outros sistemas usam tcnicas de controle fuzzy
para especificar e ajudar na adaptao de QoS. O controle fuzzy permite que as
aplicaes expressem polticas e preferncias de adaptao de QoS na forma de regras e
funes. As regras so especificadas no formato if-then. Um exemplo de regra de
adaptao nesse formato if cpu is very_high and rate is very_low then rate_demand is
compress que diz para o sistema comprimir os dados porque a largura de banda
22

Distribudas
muito baixa, mas h uma grande quantidade de cpu disponvel. Uma limitao do
controle fuzzy que esse tipo de linguagem tem a inteno de especificar somente
aes, mas no outras propriedades de QoS. Assim este tipo de linguagem pobre em
termos de expressividade e, em geral, no possui subsdios suficientes para expressar as
necessidades de aplicaes multimdia.
3.2.5 - Paradigma baseado em markup
Neste paradigma encontram-se as linguagens baseadas em markup que

um mecanismo para identificar estruturas em documentos, sendo que especificaes
XML [32] definem uma maneira padro de adicionar markup a documentos. Exemplos
de linguagens que utilizam este paradigma so XQoS [33] e HQML [2]. As
caractersticas da HQML so expostas no captulo 4 deste trabalho, porm, faz-se
relevante citar que a HQML expressiva, declarativa e independente, no entanto, no
possui nenhuma construo especial que facilite a extenso e o reuso de especificaes
existentes.
3.2.6 - Paradigma orientado a aspecto
Este paradigma segue a Programao Orientada a Aspecto (AOP) [34],

porque as tarefas relacionadas a QoS so exemplos dos aspectos deste paradigma. Os
aspectos no so unidades da decomposio funcional do sistema; preferencialmente,
eles so as propriedades que afetam o desempenho ou a semntica dos componentes em
maneiras
sistemticas.
Usando
linguagens
de
programao
tradicionais,
as
implementaes de tais aspectos resultariam em um cdigo complicado com o cdigo

relacionado a aspecto espalhado por todo o programa. A tecnologia de Programao
Orientada a Aspecto foi desenvolvida para suportar a abstrao e a composio tanto de
componentes funcionais como de aspectos. Usando AOP, uma aplicao pode ser
decomposta em componentes funcionais e aspectos, onde aspectos diferentes podem ser
23

Distribudas
programados em linguagens tambm diferentes, mas que sejam apropriadas s tarefas,
sendo que h ainda um processador de linguagem especial, chamado aspect weaver, que
coordena a composio do cdigo, fazendo com que todo o cdigo seja unificado para
produzir uma nica aplicao executvel. O paradigma orientado a aspecto pode ser
encontrado no framework Quality Object (QuO) [35], [36], [37]. QuO suporta QoS na
Camada de Recurso, que mapeado para a camada de objeto do CORBA, onde as
implementaes do objeto distribudo possibilitam acesso s propriedades do sistema
CORBA ORB. QuO estende a linguagem de descrio de interface do CORBA com a
descrio de QoS denominada de QDL, permitindo especificaes de estados de QoS,
de recursos do sistema e de mecanismos possveis a fim de medir e fornecer QoS, e
ainda com comportamento para adaptar-se s mudanas em QoS. QDL bom na
maioria dos critrios de avaliao, sendo expressiva, declarativa, independente e
extensvel.
3.2.7 - Paradigma orientado a objeto
As linguagens deste paradima baseiam-se nos conceitos das linguagens

orientadas a objetos para proverem a herana de especificaes como exemplo de reuso
de cdigo. Um exemplo de linguagem que fornea esses conceitos QML (QoS
Modeling Language) [38]. QML oferece trs mecanismos principais de abstrao de
especificao de QoS: tipo do contrato, contrato, e perfil; em que o tipo do contrato
define as dimenses que podem ser usadas para caracterizar um aspecto particular de
QoS, os contratos so instncias de tipos do contrato, e os perfis associam contratos com
as interfaces e as operaes. Alm disso, boa em termos de independncia e
extensibilidade. Entretanto, uma limitao de QML que para cada tipo de contrato que
um perfil associa, no mximo um contrato pode ser usado como um contrato padro
dentro do perfil.
24

Distribudas
3.3 - Critrios para Avaliao das Linguagens de Especificao de QoS

A avaliao dos critrios de cada paradigma diferente, pois cada um
deles composto por um conjunto de servios.
Baseado em [23], uma anlise dos critrios utilizados para a avaliao
dos paradigmas, observando-se que cada paradigma obedece a sua classificao em
camadas. Portanto, necessrio que exista um levantamento do que relevante ou no
em cada camada a fim de enumerar as vantagens dos paradigmas em relao
composio de suas camadas.
Alguns critrios relevantes avaliados na Camada de Usurio so os
aspectos que proporcionam facilidades para os mesmos, sendo necessrio lembrar que o
usurio no tem a pretenso de saber o que acontece para que o servio seja fornecido.
O usurio quer que o servio seja realizado em conformidade com as opes de QoS
escolhidas. Para facilitar o desenvolvedor da aplicao primordial que seja fornecida
uma Interface Grfica amigvel, que seja simples para que o usurio consiga realizar a
escolha da QoS e que essa escolha reflita ao usurio os custos envolvidos.
Em relao Camada de Aplicao so considerados cinco critrios para
analisar a QoS oferecida:
Expressividade: avaliada a especificao de QoS em termos da
sua capacidade de especificar uma grande variedade de servios, seus recursos exigidos
e suas regras de adaptao correspondentes.
Declarativa: uma especificao de QoS deve ser informativa;
dessa forma, deve especificar somente o que exigido, no como a prpria

especificao realizada.
Independncia: avaliada se as especificaes podem ser
desenvolvidas independentemente do cdigo funcional pela sua legibilidade e pela

facilidade no desenvolvimento e na modificao de seus objetivos.
25

Distribudas
Extensibilidade: nesse ponto avaliado o quo fcil estender
uma linguagem para permitir a especificao de novas dimenses de QoS alm das que
j foram desenvolvidas, atravs da incluso de novas classes.
Reusabilidade: capacidade do cdigo da especificao ser claro,
fcil de ser desenvolvido, etc., facilitando o seu reuso por um outro desenvolvedor.
Adaptabilidade: capacidade da linguagem representar requisitos
de adaptao mediante negociao/renegociao da aplicao.

Jin e Nahrstedt [23] apresentam um estudo comparativo das linguagens
de especificao de QoS retratado na Tabela 3, onde HQML mostrou-se, de maneira
geral, uma linguagem com resultados satisfatrios no que se refere aos critrios
importantes para a realizao deste trabalho, que so Expressividade, Extensibilidade e
Independncia, alm de ter a facilidade de ser uma linguagem baseada em XML [32].
Linguagens
de QoS
Expressividade
Declarativa
Independncia
Extensibilidade
Reusabilidade
Adaptabilidade
SafeTcl
Fraco
Regular
Bom
Fraco
Fraco
Bom
QoS-A
Bom
Bom
Bom
Bom
Fraco
Fraco
QuAL
Bom
Fraco
Fraco
Bom
Fraco
Bom
Regular
Bom
Bom
Regular
Fraco
Bom
HQML
Bom
Bom
Bom
Bom
Fraco
Bom
QDL
Bom
Bom
Bom
Bom
Fraco
Bom
QML
Regular
Bom
Bom
Bom
Bom
Bom
XqoS
Bom
Bom
Regular
Bom
Fraco
Bom
Fuzzy Control
Tabela 3: Comparao da camada de aplicao das Linguagens de Especificao de QoS.
Na Camada de Recurso do sistema avaliado se as linguagens

conseguem usar todo o recurso fsico requerido e de que forma isso acontece, isto , se
no h perdas ou mau uso do mesmo.
A Tabela 4, apresentada por Gu et al. [39], ilustra a superioridade do
HQML sobre as outras linguagens do gnero no que diz respeito ao tratamento das
camadas de usurio, de aplicao e de recurso, s facilidades impostas pelo
26

Distribudas
Mapeamento Automtico, Integrao com Aplicao Web, Checagem de Consistncia,
alm da Gerao de Especificao Automtica.
Integrao
Linguagens
QoS na
QoS na
QoS na
de
Camada
Camada
Camada
Mapeamento
Independente
com
Checagem de
Automtico
de Linguagem
Aplicao
Consistncia
Gerao de
Especificao
Especificao
de
de
de
de QoS
Usurio
Aplicao
Recurso
Index
Sim
No
No
No
No
No
No
No
SafeTcl
No
Sim
No
No
No
No
No
No
QoS-A
No
Sim
No
No
No
No
No
No
QuAL
No
Sim
Sim
No
No
No
No
No
QDL
No
Sim
Sim
No
Sim
No
No
No
QML
No
Sim
No
No
Sim
No
No
No
RSL
No
No
Sim
No
Sim
No
No
No
TAOML
No
No
Sim
Sim
Sim
Sim
No
No
HQML
Sim
Sim
Sim
Sim
Sim
Sim
Sim
Sim
XQoS
Sim
Sim
Sim
No
Sim
No
No
No
Web
Automtica
Tabela 4: Comparao entre diferentes Linguagens de Especificao de QoS.
Essas facilidades so primordiais para que o desenvolvedor no se

preocupe em como se d o mapeamento de um modelo proposto pelo mesmo em
parmetros expresso pelo cdigo HQML, abordado sucintamente no prximo captulo.
27
Linguagem
de
Marcao
para
Especificar
QoS
Hierarquicamente
O XML (eXtensible Markup Language) [32] uma linguagem de
especificao, usada por aplicaes Web multimdia distribudas num formato universal
para documentos estruturados e dados na Web e tambm extensvel. XML por si s no
diz ao desenvolvedor da aplicao como especificar requisitos de QoS para sua
aplicao, precisa definir um conjunto mnimo de tags apropriadas para permitir que os
desenvolvedores expressem suas polticas e requisitos de QoS, baseado na sintaxe
XML. Os desenvolvedores tambm podem definir suas prprias tags especficas para
um servio.
Na prtica XML um padro para troca de informaes entre diversas
plataformas, que apenas possibilita a descrio de dados em um arquivo de formato
texto. Vrias linguagens de especificao de sistemas so derivadas de XML, o que
possibilita ao XML ser considerado uma poderosa ferramenta para a publicao de
informaes. XML considerada uma linguagem-me [40] das linguagens de
especificao, pois a partir dele possvel serem desenvolvidas novas linguagens.
O XML foi escolhido para ser o modelo do HQML porque existe uma
facilidade comum e natural entre as necessidades do XML de criar novos modelos bem
sucedidos e os requisitos de especificao de QoS de aplicaes multimdia para Web.
28
Captulo 4 - HQML: Linguagem de Marcao para Especificar QoS

Hierarquicamente
O HQML (Hierarchical QoS Markup Language) [2] uma linguagem de

especificao de QoS baseada em XML e suas especificaes so classificadas em trs
nveis ou camadas, em conformidade com o detalhamento do dado no captulo 3.
Na Camada de Usurio, as especificaes HQML fornecem tags para
especificar critrios de QoS qualitativos (por exemplo, alto, baixo, mdio), tipo de
aplicao (vdeo sob demanda, videoconferncia, etc), preos para os servios
requeridos e qualquer outra tag desejada pelo desenvolvedor da aplicao, haja vista
essa possibilidade de extenso do HQML por meio do ambiente descrito no captulo 5.
As especificaes de QoS da camada de usurio so usadas, durante o tempo de
execuo, para encontrar a melhor medida entre a condio econmica do usurio, o
nvel de QoS preferido e os nveis de QoS disponveis oferecidos pelos diferentes
provedores de servio. No necessrio que os usurios conheam especificaes
quantitativas detalhadas de todos os tipos de parmetros especficos da aplicao que
podem, potencialmente, ser muito complexos, como foi apresentado na camada de
usurio descrita no captulo 3.
Na Camada de Aplicao, as especificaes HQML fornecem tags para
especificar parmetros de QoS do nvel de aplicao de todos os tipos, polticas de QoS
especficas aplicao (regras de adaptao e de reconfigurao), alm de qualquer
outra tag que o desenvolvedor da aplicao desejar criar. As especificaes de QoS
dessa camada so usadas por aplicaes para ativar e reforar a QoS em benefcio da
aplicao mesmo se o suporte do Sistema Operacional e a QoS da rede est ausente.
Na Camada de Recurso, as especificaes HQML fornecem tags para
especificar diferentes requisitos de recurso de sistema (por exemplo, memria, cpu,
largura de banda, etc.). As especificaes nessa camada visam garantir os servios de
QoS nos nveis de rede e de sistema abordados no captulo 2.
Embora HQML siga a sintaxe padro do XML e pode ser facilmente
utilizado, alguns pontos crticos exigem consideraes cuidadosas:
Algumas informaes em especificaes HQML no podem ser
produzidas diretamente. Por exemplo, o desenvolvedor da aplicao no pode conhecer

previamente os requerimentos de recurso do sistema para suas aplicaes. Para as regras
de adaptao, o desenvolvedor da aplicao precisa especificar os valores mnimos dos
29

Hierarquicamente
parmetros de cada incio de adaptao, que decidiro o tempo de ativao de cada

escolha de adaptao. Mas esses valores mnimos no podem ser facilmente produzidos;
necessrio checar a consistncia ou preciso das especificaes
HQML. J que permitido para os desenvolvedores de aplicao usarem HQML para

especificar suas prprias polticas e requerimento de QoS, qualquer especificao ilegal
pode no produzir os resultados esperados;
Embora o DTD (document type definition), ou definio do tipo
de documento [2] possa ser usado para checar alguns erros nos arquivos baseados em
XML, ele no contm nada especfico sobre especificaes de QoS. Por exemplo, devese ter certeza que no h deadlock nas especificaes das configuraes da aplicao
para uma aplicao multimdia distribuda;
Os parmetros de QoS entre dois componentes conectados devem
ser consistentes. Se, por exemplo, um codificador MPEGII estiver conectado com um
decodificador H261, ou um player de baixa qualidade estiver conectado com um
servidor de vdeo de alto desempenho, a aplicao no funcionar apropriadamente.
Tais problemas de inconsistncias podem ser solucionados por um
verificador da semntica da especificao completa. Um exemplo o QoSTalk [41], que
um ambiente visual que auxilia os desenvolvedores de aplicao a gerar os arquivos
HQML fcil e corretamente.
4.1 - Modelo de Aplicao
Para compreender melhor a aplicao e o correto uso do HQML,

preciso conhecer o modelo de aplicao em que o HQML foi baseado. Foi considerado
um modelo com componentes de aplicao genrico para caracterizar a estrutura de
aplicaes multimdia distribudas. Todos os componentes de aplicao so construdos
como tarefas, que executam operaes especficas nos dados multimdia que passam por
elas, assim como transformao, agregao, prefetching6 e filtragem. Cada componente
aceita a entrada com um nvel de QoS Qin e gera uma sada com um nvel de QoS Qout.
6
Prefetching: tcnica que antecipa a transmisso de possveis requisies.
30

Hierarquicamente
Para poder processar a entrada e gerar a sada, uma quantidade especfica de recursos
necessria.
As tarefas podem ser conectadas em um dgrafo acclico, que chamado
de configurao da aplicao. A configurao da aplicao o fluxograma sob o qual o
dado multimdia passa entre os provedores de servio e o usurio final. Como exemplo,
na aplicao de vdeo sob demanda, ilustrada na Figura 4, o dado lido do disco,
armazenado em buffers no remetente (servidor), transmitido pela rede e novamente
armazenado no buffer no receptor (cliente). Ento decodificado antes de ser
apresentado para o usurio. Os buffers so considerados componentes de aplicao ao
invs de memria de armazenamento, permitindo assim utilizar diferentes formas de
gerenciamento do buffer explicitamente.
Figura 4: Configurao da aplicao para aplicao de VoD.
Pela grande diferena de implementao de uma mesma estrutura de um

sistema distribudo multimdia, o HQML foi projetado para suportar tais diferenas.
Como exemplo, a utilizao de um dispositivo mvel, como um celular, por um usurio
e a utilizao de computador desktop por outro. O simples fato de um usurio portar um
dispositivo distinto de outro usurio faz com que toda a efetivao da informao para
ambos passe por arquiteturas e processos distintos, mesmo que eles busquem a mesma
informao de um nico servidor. A capacidade do celular de processamento e de
recursos inferior capacidade do desktop. O HQML baseado no conceito de
Polimorfismo de Servio [2] para QoS de diferentes sistemas.
Para suportar o polimorfismo de servio foi desenvolvido um modo
hierrquico de caracterizao das configuraes de aplicao. O modo hierrquico ajuda
a solucionar o problema da escalabilidade para aplicaes multimdia distribudas
complexas [41].
31

Hierarquicamente
A arquitetura do HQML contempla a organizao hierrquica da

aplicao, com detalhamento de QoS nos trs diferentes nveis, Usurio, Aplicao e
Recurso. A Figura 5 ilustra essa hierarquia.
Figura 5: Organizao hierrquica do HQML.
Essa hierarquia mostrada na Figura 5 pode ser representada por meio do

seguinte exemplo prtico: uma aplicao multimdia X qualquer pode ter vrias formas
de ser configurada, neste caso, Configurao A e Configurao B. Essas configuraes
A e B podem, por exemplo, ser configuraes para uma aplicao de vdeo sob
demanda, sendo a configurao A para computadores do tipo desktop enquanto a B para
PDAs. Dessa forma, as configuraes A e B possuem caminhos distintos, pois A tem
que suprir requisitos diferentes de B e vice-versa. Por isso, na camada de usurio, A
representa parmetros como qualidade do vdeo de HDTV, enquanto B, devido a
limitaes do dispositivo, no pode tratar a qualidade do vdeo com esse valor. Da
mesma maneira, na camada de aplicao, existem diferenas na forma de representao
dos componentes envolvidos, como a necessidade de um transmissor wireless no caso
da configurao B. Em relao camada de recurso, clara a maior necessidade da
configurao A por processamento e largura de banda em relao B, haja vista o
32

Hierarquicamente
pouco poder de processamento e de uso da largura de banda dos dispositivos finais na

configurao B.
4.2 - Sintaxe HQML para Especificao de QoS da Camada de Usurio
As especificaes de QoS da Camada de Usurio so baseadas nas

seguintes caractersticas [2]: as descries que abrangem toda a aplicao, por exemplo,
o nome da aplicao e qual o servio provido; e a possibilidade de escolha dos servios,
como por exemplo, usurios podem especificar a qualidade que eles desejam pelo
servio desejado. A seguir, so apresentadas algumas tags possveis de serem definidas
na Camada de Usurio: as tags <User Preferences> e </User Preferences> definem o
contedo referente s exigncias do usurio, contendo todas as outras tags dessa
camada; <Application Type> e </Application Type> definem a classe de aplicao
multimdia desejada pelo usurio; <Desired QoS> e </Desired QoS> abordam a
Qualidade de Servio requerida pelo usurio; <Application Name> e </Application
Name> definem o nome da aplicao; <Price> e </Price> se referem a algum possvel
valor pago pelo usurio para ter um informao mediante uso de uma aplicao; <Price
Variation> e </Price Variation> definem a variao do preo pago pelo usurio; <Price
Unit> e </Price Unit> tratam a unidade utilizada pelas tags <Price> e </Price>.
A Figura 6 ilustra um cdigo HQML no nvel da Camada de Usurio,
sendo perceptvel o que importante para o usurio atravs das tags descritas no cdigo,
por exemplo, <Application Type> Video On Demand </Application Type> e <Desired
QoS> High </Desired QoS>. Atravs dessas tags so definidos parmetros importantes
para a definio da faixa de valores que esses parmetros devem receber quando na (re)
negociao da QoS. O contedo descrito pelo par de tags pode variar de acordo com a
necessidade do desenvolvedor, podendo o tipo de aplicao ser Videoconference
(videoconferncia), Audio on Demand (udio sob demanda), ou qualquer outra
aplicao multimdia. O mesmo se aplica ao par de tags que descreve a Qualidade de
Servio desejada, podendo ser ainda Average (mdia), Low (baixa), ou Any (qualquer).
Essas tags presentes na Figura 6 so as tags criadas automaticamente a
partir das definies feitas no ambiente WSE, porm outras tags podem ser criadas de
33

Hierarquicamente
acordo com a necessidade do desenvolvedor da aplicao por meio do ambiente WSE,

que ser abordado no captulo 5. Assim, possvel que o desenvolvedor crie um par de
tags <Image> </Image> a fim de quantificar valores para a resoluo de uma imagem.
<User Preferences>
<Application Type>
Video On Demand
</Application Type>
<Desired QoS>
High
</Desired QoS>
<Application Name>
Untitled
</Application Name>
</User Preferences>
Figura 6: Exemplo de Especificaes HQML na Camada de Usurio.
4.3 - Sintaxe HQML para Especificao de QoS da Camada de

Aplicao
A especificao de QoS da camada de aplicao necessria para que os

desenvolvedores de aplicaes reconheam que para acessar os servios das camadas
mais baixas, e controlar suas qualidades, as aplicaes precisam descrever seus
requerimentos de QoS.
Uma especificao nesta camada uma aplicao especfica, porm
independente de recursos. Dois tipos de caractersticas da camada de aplicao podem
ser definidas: uma especfica ao desempenho, expressa por parmetros quantitativos e
a outra especfica ao comportamento, expressa por parmetros qualitativos. Uma
linguagem de especificao deve prover certas abstraes para que os programadores
no tenham que utilizar detalhes de nveis muitos baixos sobre quais recursos e aes
precisam ser invocados. H duas maneiras de prover abstraes de programao: uma
atravs de APIs e a outra atravs de construtores de linguagem, estendendo uma
34

Hierarquicamente
linguagem existente ou criando outras completamente novas. Um exemplo de cdigo

HQML inerente camada de aplicao est apresentado na Figura 7.
Neste exemplo esto as principais tags referentes a essa camada que so
geradas automaticamente pelo ambiente WSE, que ser detalhado no prximo captulo.
As tags compreendidas entre o par de tags <QoSParameters> e </QoSParameters>
contm os parmetros de Qualidade de Servio e as regras de adaptao definidas no
ambiente WSE. Portanto, as tags <Delay>, </Delay>, <Jitter> e </Jitter> definem os
parmetros de QoS abordados na especificao e as tags <Min>, </Min>, <Max> e
</Max>
definem
os
valores
para
cada
um
desses
parmetros.
As
tags
<AdaptationRules> e </AdaptationRules> contm as regras de adaptao definidas

pelas tags <Name> e </Name> e a ordem de aplicao de cada regra baseada nas tags
<Order> e </Order>.
Alm disso, os valores para os parmetros nessa camada variam de
acordo com a aplicao que se quer especificar, portanto, dependendo da aplicao
podem ser usados diferentes tipos de mdia, formatos de mdia, variao da taxa de
quadro, ou profundidade da cor, por exemplo. Ainda, dependendo da aplicao tem-se
variaes diferentes de outros parmetros, como vazo e taxa de perda. Lembrando que
possvel estender o HQML a fim de se criar tags para delimitar os parmetros que
podem ser utilizados por uma nova aplicao.
35

Hierarquicamente
<QoSParameters>
<Delay>
<Min>
1
</Min>
<Max>
2
</Max>
</Delay>
<AdaptationRules>
<Rule>
<Name>
No sound
</Name>
<Order>
101
</Order>
</Rule>
</AdaptationRules>
<Jitter>
<Min>
0
</Min>
<Max>
1
</Max>
</Jitter>
<AdaptationRules>
<Rule>
<Name>
No video
</Name>
<Order>
201
</Order>
</Rule>
</AdaptationRules>
</QoSParameters>
Figura 7: Exemplo de Especificaes HQML na Camada de Aplicao.
4.4 - Sintaxe HQML para Especificao de QoS da Camada de

Recursos
Especificaes da Camada de Aplicao somente declaram requisitos em

alto nvel e de uma forma abstrata. Mais tarde, esses requisitos devem ser traduzidos em
necessidades de recurso mais concretas, isto , descries de servios devem ser
providas, como quais recursos fsicos sero necessrios para a aplicao, quando eles
precisam ser alocados e quais mecanismos devem ser adotados.
A importncia das especificaes de QoS da Camada de Recurso, de
acordo com [2] so duas: essas especificaes permitem que aplicaes multimdia
utilizem os servios do Sistema Operacional e de QoS da Rede se eles estiverem
disponveis; e as especificaes marcam os valores mnimos que determinam o tempo
36

Hierarquicamente
de ativao de uma adaptao especfica ou uma ao de reconfigurao. A Figura 8

mostra um exemplo de cdigo HQML especfico na camada de recurso do sistema.
Nesse exemplo, podem ser notadas tags que descrevem as necessidades fsicas das
mquinas onde as aplicaes multimdia sero executadas. As tags <Memory>,
</Memory>, <Disk>, </Disk>, <Bandwidth> e </Bandwidth> descrevem essas
necessidades que, na verdade, so recursos que sero alocados na execuo da aplicao
multimdia a fim de garantir os parmetros de QoS definidos nas camadas superiores
(usurio e aplicao). As tags <HardwareEnvironment>, </HardwareEnvironment>,
<SoftwareEnvironment> e </SoftwareEnvironment> contm a arquitetura das
mquinas, enquanto que as tags <Category> e </Category> definem a qual categoria o
componente que est sendo descrito pertence. J as tags <NodeLabel> e </NodeLabel>
descrevem o nmero de cada componente especificado no ambiente WSE.
As especificaes nesta camada so classificadas de acordo com suas
granularidades. Duas categorias de granularidade so adotadas: grossa e fina. Atravs da
granularidade grossa esperada uma especificao meta-nvel, enquanto pela
granularidade fina so esperadas descries concretas de recursos requeridos. Em
relao a granularidade grossa, algumas especificaes na Camada de Recurso de QoS
somente especificam requisitos de recursos, preferivelmente, de uma forma abstrata. Por
exemplo, eles podem especificar qual (quantidade) recurso requerido, mas no
importa quando os recursos precisam ser alocados, ou qual ao tomar se o
requerimento do recurso no for encontrado, ou se vrias instncias do recurso (como
processadores) esto disponveis e qual delas deve-se utilizar.
37

Hierarquicamente
<ServerGroup>
<Server>
<Name>
Server1
</Name>
<Category>
Servers
</Category>
<NodeLabel>
0
</NodeLabel>
<HardwareEnvironment>
Sun Ultra60
</HardwareEnvironment>
<SoftwareEnvironment>
Solaris
</SoftwareEnvironment>
<Memory>
512000 KB
</Memory>
<Disk>
40000 MB
</Disk>
<Bandwidth>
100 Mbits
</Bandwidth>
<AtomicComponent>
<Name>
Software Server
</Name>
<Category>
Clients
</Category>
<NodeLabel>
1
</NodeLabel>
<Memory>
256000KB
</Memory>
<Disk>
20000MB
</Disk>
<Bandwidth>
50 Mbits
</Bandwidth>
</AtomicComponent>
</Server>
</ServerGroup>
Figura 8: Exemplo de Especificaes HQML na Camada de Recurso.
Para aplicaes multimdia, especificaes de granularidades mais finas

so requeridas, pois so esperadas de uma especificao na Camada de Recurso com
granularidade fina descries de requerimentos de QoS quantitativa e qualitativa; tempo
para o requerimento do recurso, como quando e por quanto tempo os recursos precisam
ser alocados e regras de adaptao.
38
5 - Ambiente para Especificao de Aplicaes Multimdia

com Suporte de Qualidade de Servio
O Ambiente para Especificao de Aplicaes Multimdia com Suporte
de Qualidade de Servio (WSE) um ambiente visual desenvolvido na linguagem Java
que disponibiliza componentes visuais ao desenvolvedor de aplicaes para criar
especificaes de sistemas multimdia distribudos com garantia de QoS.
Essas especificaes so descritas por meio de figuras geomtricas
acessadas por botes. Alm disso, o WSE possibilita descrever ainda o tipo de ligao
entre os componentes do sistema multimdia, bastando clicar no boto correspondente
ao tipo de interligao (sem fio ou cabeada).
O estabelecimento de parmetros de QoS acontece por meio de caixas de
dilogo especficas de cada componente (server, client, gateway, peer) e podem ser
preenchidas da forma com que o desenvolvedor queira, desde que utilize palavras
reservadas que sejam entendidas pelo Executor HQML.
neste estabelecimento que se encontra o diferencial do ambiente, pois
possibita estabelecer limites mnimos e mximos para cada parmetro de rede atuante na
QoS do sistema, alm de elencar regras de adaptao do vdeo a cada violao de um
dos limites. Isso acarreta na (re)negociao para a utilizao de filtros nos vdeos que
mantm a reproduo do vdeo de acordo com a qualidade desejada.
Aps a especificao do Sistema, a verificao de consistncia das
Qualidades de Servio pode ser aferida pelo sistema. O WSE inclui ainda o compilador
que executa os mapeamentos automticos entre os parmetros de QoS das camadas de
39
aplicao e de recurso do sistema, auxiliando o desenvolvedor na tarefa de lidar com

especificaes de QoS em um baixo nvel. Alm desses componentes, o WSE
disponibiliza tambm o Gerador de HQML e o Executor HQML.
5.1 - Viso Geral da Arquitetura

Os passos necessrios a serem seguidos pelo desenvolvedor at a
implementao da aplicao, levando em considerao os elementos da arquitetura do
WSE presentes na Figura 9 so:
O incio do desenvolvimento de uma especificao de uma
aplicao multimdia distribuda acontece no Editor Visual de QoS Hierrquico onde

so oferecidas classes de aplicaes multimdia (video on demand, audio on demand,
video conference, audio conference, new application) e escolhida a Qualidade de
Servio
ser
mantida
no
sistema
(high,
average,
low,
any);
40
Captulo5 Ambiente para Especificao de Aplicaes Multimdia com Suporte de

Qualidade de Servio
Figura 9: Arquitetura do Ambiente para Especificao de Aplicaes Multimdia com Suporte de

QoS.
Posteriormente, o desenvolvedor da aplicao usa o Editor Visual
de QoS Hierrquico para desenhar todas as configuraes possveis da aplicao e

colocar as entradas de todos os tipos de requisies de QoS das Camadas Usurio e
Aplicao;
Depois, o desenvolvedor usa o Verificador de Consistncia para
detectar possveis inconsistncias nas especificaes de entrada. Se existir qualquer

inconsistncia, mensagens de erros so retornadas para o desenvolvedor no Editor
Visual de QoS Hierrquico;
Posteriormente, as configuraes corretas da aplicao e as
especificaes de QoS completas (Camadas Usurio, Aplicao e Recurso) so passadas

41

Qualidade de Servio
para o Gerador de HQML, que analisa as configuraes da aplicao para gerar o

arquivo HQML de forma automtica;
Finalmente, o arquivo HQML salvo a fim de poder ser lido
posteriormente pelo Executor HQML, que tem por finalidade ler o arquivo HQML,
entend-lo e passar esses parmetros para o sistema multimdia por meio de comandos
do Sistema Operacional.
5.2 - Editor Visual de QoS Hierrquico

O Editor Visual de QoS Hierrquico uma ferramenta visual que
permite ao desenvolvedor desenhar as configuraes desejadas para aplicaes
multimdia distribudas. Este editor foi adaptado do editor presente no QoSTalk [41],
adicionando, dentre outras funcionalidades, caixas de dilogo para que o desenvolvedor
coloque as entradas para todos os tipos de polticas e parmetros de QoS. O propsito
do Editor Visual de QoS Hierrquico baseado no modelo descrito na seo 4.1 Modelo de Aplicao e segue a proposio hierrquica, isto , o desenvolvedor pode
refinar um componente composto desenhando todos os seus subcomponentes em um
subframe.
Para facilitar o seu uso, o Editor possui formas diferentes para
representar os diferentes tipos de componentes, sendo o componente servidor
representado pelo retngulo, o gateway pelo losango, elipse representa o cliente
componente, e o retngulo arredondado o componente peer7.
Utilizando a ferramenta visual, possvel descrever qualquer sistema
multimdia distribudo, variando desde sistemas simples compostos por somente um
cliente e um servidor at sistemas formados por vrios clientes e servidores. Essa forma
de descrio de vrios clientes e servidores acontece devido forma com que o Editor
descreve cada um dos componentes (servidor, cliente, gateway, peer) envolvidos na
modelagem e pela representao hierrquica dos componentes, sendo que cada
componente pode ser detalhado por uma nova janela (ChildFrame) do Editor, ou por
propriedades do componente.
7
Peer: qualquer host que pode exercer as funes de cliente e servidor.
42

Qualidade de Servio
Os componentes das aplicaes, como grupo (unio de dois ou mais

componentes formando um cluster), hardware e software so representados pelas cores
azul, verde e amarelo, respectivamente, o que facilita no entendimento e na
representao dos objetos no Editor. Exemplos desses componentes podem ser vistos na
Figura 10 representados pelos quadrados.
Figura 10: Editor Visual de QoS Hierrquico.
A Figura 10 traz a interface grfica do Ambiente para Especificao de

Aplicaes Multimdia com Suporte de Qualidade de Servio, sendo possvel verificar
toda a estruturao do ambiente que composto por uma barra de menus na parte
superior, uma barra de atalhos logo abaixo e uma rea para a descrio de aplicaes
multimdia. A presena de dois ChildFrames nessa rea de descrio caracteriza o
desenvolvimento hierrquico dos componentes da aplicao multimdia distribuda, que
ocorre da seguinte forma: aps a representao do componente grupo, obrigatoriamente
so necessrias as representaes de ao menos um componente hardware e um
componente software. Essas representaes devem ser em ChildFrames diferentes, isto
43

Qualidade de Servio
, a partir do componente grupo, deve ser criado um ChildFrame para a representao

do componente hardware e, a partir desse componente, criado outro ChildFrame para a
representao do componente software.
O Editor Visual de QoS Hierrquico possui caixas de dilogos referentes
a cada componente, quando no ser mais refinado. As caractersticas dos componentes
hardware e software so preenchidas nas suas respectivas caixas de dilogo
correspondentes. A Figura 11 mostra a caixa de dilogo referente ao componente
software do cliente. Essa a caixa de dilogo mais importante, pois nela em que so
preenchidos os parmetros e seus valores, alm das regras de adaptao referentes a
cada parmetro, especificamente Camada de Aplicao. A descrio de QoS na
aplicao fica componentizada e tais informaes podem ser utilizadas para a Camada
de Recursos empregar melhor a distribuio dos recursos em tais componentes.
Figura 11: Caixa de dilogo referente ao software do cliente.
44

Qualidade de Servio
A caixa de dilogo referente ao hardware do cliente mostrada na Figura

12. Essa caixa mostra as caractersticas do componente hardware, bem como as
especificaes referentes Camada de Recurso que devem ser preenchidas.
Figura 12: Caixa de dilogo referente ao hardware do cliente.
5.3 - ConfigG: Gramtica Especial de Relao de Smbolo Limitada

As duas principais tarefas da verificao de consistncia so encontrar
configuraes incorretas da aplicao e descobrir parmetros incompatveis entre dois
componentes conectados. Para isso, utiliza-se uma teoria de gramtica de grafos formal
onde cada configurao da aplicao descrita por uma sentena da gramtica de
grafos. Portanto, os problemas de checagem de consistncia nas especificaes de QoS
visuais so reduzidos para o que sobra aps a eliminao dos erros de configurao pela
sentena da gramtica de grafos e seus analisadores sinttico e semntico.
A fim de fortalecer a verificao de consistncia e descobrir parmetros
de QoS incompatveis, existe uma gramtica especial chamada ConfigG [2], sendo que
a mesma baseada em uma outra gramtica, a Relao de Smbolo [43] (Symbol
Relation SR) que reconhecida por ser uma gramtica de grafos para lidar com
estruturas de grafos complexas. A ConfigG previne, por exemplo, inconsistncias em
configuraes semelhantes as descritas na Figura 13, como em (a) onde o componente
45

Qualidade de Servio
c1 no est conectado com nenhum outro componente; (b) o componente cliente c4

no recebe nenhum dado do componente o qual est conectado, neste caso o gateway
c3; e em (c) no h componente cliente para receber a vazo de dados de mdia. Alm
disso, configuraes com parmetros incompatveis de QoS como um codificador de
MPEGII conectado em um decoficador H261, ou um player de vdeo de baixa
qualidade, que consegue reproduzir vdeos com 15 qps (quadros por segundo),
conectado com um servidor de vdeo de alta performance que envia streams de vdeo a
30 qps tambm so analisados pela ConfigG.
Figura 13: Exemplos de Grafos de Configuraes Incorretos.
A verificao de consistncia dividida em dois estgios, sendo o

primeiro a traduo das configuraes de entrada da aplicao pelo Analisador Sinttico
da ConfigG em uma sentena da ConfigG. Se o processo de traduo no obtiver
sucesso, o grafo da configurao incorreto, caso contrrio, uma rvore de derivao
[43] gerada para o grafo de configurao. No segundo estgio, o Analisador
Semntico da ConfigG varre a rvore de derivao para checar as consistncias
semnticas de acordo com as regras semnticas associadas com cada passo da
derivao.
46

Qualidade de Servio
A ConfigG a sextupla (S, T, VN, R, SP, RP) onde:

- S o smbolo inicial;
- O alfabeto T={AudioServer, AudioPlayer, VideoServer, VideoPlayer,
MediaServer,
MediaPlayer,
VoiceMailRecorder,
Prefetch,
ImageServer,
VisualTracker,
ImageDisplay,
MediaRecorder,
RemoteControl,
Transcoder,
FrameDropper, t} o conjunto de terminais representando os componentes de servio

(software), como players de udio e vdeo e visualizador de imagens;
- O conjunto no terminal VN= {S, SC, GWC, CC, A, B, C, D, AT, BT,
CT, DT}. S o smbolo inicial. SC, GWC, CC e GC representam Server Cluster,
Gateway Cluster, Client Cluster e General Cluster, respectivamente. A, B, C e D
representam hardware do servidor, hardware do gateway, hardware do cliente e
hardware geral, respectivamente. AT, BT, CT e DT so smbolos temporrios usados
durante a derivao para evitar ambigidade;
- O Conjunto de Relao de Smbolo R={fl (FixedLink), mul
(MobileUserLink), mhl (Mobile-HostLink)} o conjunto de terminais representando a
relao entre os componentes;
- SP o conjunto de regras de produo para os smbolos, RP o
conjunto de regras de produo para as relaes.
O conjunto completo das regras de produo da ConfigG apresentado
no Apndice C [44].
Esse mdulo de verificao de consistncia utilizou a implementao
feita pelo ambiente QoSTalk [41] que trata a consistncia de mesma forma que o WSE.
5.4 - Gerador de HQML

O Gerador de HQML responsvel por recolher todas as caractersticas
descritas na especificao da aplicao multimdia no Editor Visual de QoS Hierrquico
e transform-las no cdigo HQML. As informaes que descrevem as caractersticas da
especificao so fornecidas mediante o preenchimento das caixas de dilogo
correspondentes a cada componente, alm das informaes escolhidas que definem a
47

Qualidade de Servio
aplicao na Camada de Usurio (tipo de aplicao e QoS da aplicao) e as que so

mapeadas para a Camada de Recurso. Alm disso, a prpria modelagem feita pela
descrio dos objetos (servidor, gateway, cliente, ou peer) existentes tambm far parte
do cdigo HQML.
O cdigo HQML gerado atravs da varredura de todos os
componentes descritos no Editor Visual de QoS Hierrquico. Cada componente possui
informaes que so descritas por meio das suas caixas de dilogo. Essas informaes
so recolhidas e mostradas em uma estrutura que representa o cdigo HQML. Esse
cdigo em linguagem de marcao e especifica a modelagem nas Camadas de
Usurio, Aplicao e Recurso. Essa estrutura remonta todas as tags utilizadas no cdigo
HQML, conforme descrito no captulo anterior, preenchendo as tags com as
informaes da especificao.
5.5 - Executor HQML

O Executor HQML tambm faz parte do WSE e responsvel por
verificar o cdigo HQML e configurar um sistema multimdia qualquer, seja este um
ambiente de emulao, um framework, ou um esquema de aplicao pr-definido.
A partir do Executor, o sistema multimdia (framework, aplicao ou
sistema emulado) alimentado com os valores presentes nas tags escritas em HQML.
Ao implementar uma aplicao que utilize as informaes descritas no
cdigo HQML, esse cdigo base fidedigna para implementao e deve ser consultado
a fim de garantir o que foi descrito na modelagem. Essa consulta ocorre no momento em
que iniciada uma aplicao. Neste momento, chamado o Executor que tem a
capacidade de ler e entender os parmetros descritos no cdigo HQML. Dessa forma, o
Executor detm a garantia de que os parmetros foram interpretados de maneira correta,
e que os mesmos sero passados para a aplicao, a fim de serem utilizados na
negociao e manuteno da QoS.
O Executor, na realidade, baseia-se em um arquivo do tipo texto que
contm somente as informaes necessrias para a alimentao da classe
48

Qualidade de Servio
ControlServer. Essa classe necessita dos parmetros de QoS e das regras de adaptao
para preencher a tabela que contm os comandos de filtragem do vdeo.
O estudo de caso ilustrando uma modelagem possvel por meio do
ambiente WSE uma aplicao de vdeo sob demanda composto por 3 componentes:
um cliente, um servidor e o proxy, como descrito na Figura 14, em que o cliente
requisita um vdeo ao servidor usando o proxy como mediador. O cliente requisita o
vdeo atravs do Mplayer [45], a implementao do proxy descrita a seguir e o
servidor utilizado o Apache [46].
Figura 14: Estrutura da Aplicao de Vdeo Sob Demanda.
As principais classes utilizadas na implementao do proxy nessa

aplicao de vdeo sob demanda esto no Apndice A: Classe Connection, Classe
ProxyTunnel, Classe Server, Classe ControlServer, Classe Controller e Classe
ControllerGUI.
A criao do caminho entre o cliente e o servidor, mediado pelo proxy,
feita pela Classe Connection. Sua nica funo manter esse caminho que foi criado
repassando todo o contedo que chega ao proxy oriundo do servidor para o cliente e
vice-versa. Os comandos que executam a adaptao esto na Classe ControllerGUI. O
executor HQML est na Classe ControlServer. por meio dessa classe que o arquivo
HQML lido e o mtodo setFilter chamado. Esse mtodo responsvel por invocar o
filtro utilizado na adaptao.
O proxy recebe a requisio, verifica qual o servidor e tenta estabelecer
uma conexo com o servidor, repassando a requisio do vdeo feita pelo cliente. O
servidor verifica a existncia do vdeo (arquivo) requisitado. Se a resposta for positiva,
o mesmo envia uma resposta para o proxy estabelecendo a conexo e j enviando os
primeiros bytes referentes ao arquivo. O proxy recebe esses bytes e os envia ao cliente,
estabelecendo a conexo para a transmisso do vdeo.
49

Qualidade de Servio
No momento em que o proxy recebe os primeiros bytes do arquivo

requisitado, j ocorre a medio dos parmetros da rede, atravs da classe Controller.
Essa medio feita por um processo que executado no proxy e por um outro
processo executado no cliente. Isso ocorre devido necessidade do proxy enviar
requisies para o cliente e o mesmo ter que responde-las. Essas requisies e respostas
so feitas por esses processos que compe um monitor de rede que verifica alguns
parmetros como atraso e variao do atraso. A vazo e a perda, outros dois parmetros
importantes em se tratando de QoS, so verificados pelo processo do proxy que recebe
os bytes enviados pelo servidor e os repassa para o cliente.
medida que a transmisso dos dados do vdeo iniciada, a medio
dos parmetros ocorre em paralelo. Esses valores dos parmetros so requisitos para que
ocorra ou no a adaptao no vdeo. Por exemplo, se o valor do atraso est fora do prestabelecido como ideal para uma transmisso de vdeo sob demanda com qualidade
alta repassado pelo monitor para o proxy que executa uma filtragem nesse vdeo,
como determinado pela poltica de adaptao inserida na modelagem e descrito no
cdigo HQML. A filtragem ocorre dependendo das definies inseridas na modelagem
e descritas no cdigo HQML. Para cada regra de adaptao, pode ser associado o nome
de um filtro, ou um nome de uma ao a ser tomada, que ser responsvel por explicitar
o procedimento a ser executado caso necessrio.
A adaptao no vdeo ocorre por meio do comando ffmpeg -qscale X -ab
Y -f mpeg -i - -f mpeg -, existente na biblioteca Ffmpeg [47] em que:
-
ffmpeg a chamada a um programa fornecido junto com a biblioteca
-qscale significa que o filtro atuar na alterao dessa caracterstica
X ilustra somente o valor que pode ser colocado como opo na
homnima;
do vdeo;
alterao da qscale do vdeo;

-
-ab indica que o vdeo sofre alteraes na taxa de bits do udio;
Y ilustra o valor que pode ser colocado como opo para a alterao
da taxa de bits do udio;

50

Qualidade de Servio
o primeiro -f significa que um formato do vdeo de entrada est sendo
forado no formato indicado;

-
mpeg o formato forado para a entrada do vdeo;
-i indica entrada de vdeo;
o primeiro sinal indica que o vdeo est sendo capturado pela
entrada padro do comando (stdin);

-
o segundo -f significa que um formato est sendo forado na sada do
mpeg o formato forado para a sada do vdeo;
o segundo sinal de indica a biblioteca Ffmpeg para usar a sada
vdeo;
padro (stdout) como sada do vdeo filtrado.
5.6 - Mdulo Sistema Multimdia
O Mdulo Sistema Multimdia qualquer sistema multimdia que vai ser

alimentado pela especificao da modelagem no Editor Visual de QoS Hierrquico.
Esse sistema pode ser um framework como em [48], uma aplicao multimdia
qualquer, como uma teleconferncia, ou um sistema emulado.
A fim de garantir resultados vlidos para a execuo dessa aplicao,
optou-se por emular as condies da rede com o uso do Nist Net [49]. A emulao
uma combinao de duas tcnicas comuns para testar o cdigo da rede [50]: simulao,
que possvel definir como um ambiente sinttico para representaes do cdigo de
execuo; e teste real, um ambiente real para a execuo de cdigo real. Nestes termos,
a emulao um ambiente semi-sinttico para a execuo de cdigo real. O ambiente
semi-sinttico no sentido que uma implementao real da rede com meios
suplementares para introduzir parmetros de rede.
O Nist Net [49] uma ferramenta de propsito geral para emulao de
performances dinmicas em redes IP. Esta ferramenta foi projetada para permitir a
reproduo de experimentos controlados com aplicaes adaptativas (ou sensitivas)
51

Qualidade de Servio
performance da rede. Por operar no nvel de roteamento (nvel IP), o Nist Net pode
emular caractersticas crticas de performance fim a fim, tais como congestionamento,
perdas de pacotes e gargalos que limitam a largura de banda.
A emulao oferece assim mais vantagens que as duas situaes:
simulaes (um ambiente controlado que relativamente rpido e fcil de se montar) e
teste real (cdigo real em um ambiente real que evita todas as perguntas sobre a
fidelidade da representao). Ainda, a emulao pode minimizar o investimento
requerido para testar a rede por sua fcil instalao e uso.
A emulao de rede uma soluo intermediria, propiciando um
ambiente capaz de reproduzir situaes crticas e executando cdigo do prprio sistema.
Com este mtodo, possvel testar desde ambientes grandes e complexos, at ambientes
simples, utilizando uma pequena rede em um laboratrio, sendo que no necessrio
refazer o cdigo do sistema para o ambiente de execuo. Alm disso, o custo na
utilizao de um emulador muito baixo, uma vez que com o mesmo equipamento
possvel modelar uma variedade enorme de ambientes.
A implementao do Nist Net consiste em um mdulo de extenso para o
kernel do sistema operacional Linux e uma interface grfica para o usurio da aplicao.
Em uso, a ferramenta permite a um computador pessoal configurado como roteador,
emular numerosos cenrios de performances complexas, como limitaes de largura de
banda, atrasos, duplicao e perdas de pacotes de dados, dentre outros. A interface
grfica permite ao usurio monitorar e selecionar o trfego que passa atravs do
roteador, e aplicar efeitos selecionados de performance aos pacotes IP do fluxo de
informao. Em adio interface interativa, o Nist Net pode ser dirigido por traos de
medidas feitas a partir de condies de redes reais.
O Nist Net um pacote de emulao que executa na maioria dos PCs
equipados com Linux sendo de fcil instalao e de distribuio gratuita. Para interagir
com esse emulador, vrias ferramentas esto disponveis no pacote, tais como o Cnistnet
e o Xnistnet (a interface grfica). O primeiro prov uma interface de linhas de comando
que permite interao com o emulador atravs de argumentos como u (ativa o
emulador) e d (desativa o emulador). O segundo uma interface grfica, a qual
52

Qualidade de Servio
permite monitorar e controlar facilmente o fluxo de informao desejado. As Figuras

15, 16 e 17 mostram a interface grfica Xnistnet e explicam a sua funcionalidade [49].
Endereo de origem e destino dos

pacotes. Podem ser nomes ou IP
Mxima largura de banda

Desvio padro do tempo de permitida bytes/segundo Porcentagem de pacotes
atraso em milisegundos
perdidos ou duplicados
liga e desliga o
Carrega mudanas
emulador
realizadas
L as configuraes
Adiciona outra linha
correntes do
interface do usurio
emulador
Sai da interface do
usurio
Figura 15: Interface Grfica Parcial do Emulador Nist Net (Xnistnet).
Nenhum pacote perdido se o comprimento da fila de espera est abaixo de

DRDmin. 95% dos pacotes so perdidos se o comprimento da fila de espera
maior que DRDmax. A porcentagem de perdas aumenta a medida que o
comprimento da fila vai de DRDmin para DRDmax
Mdia observada na utilizao da

largura de banda ativa
53

Qualidade de Servio
Tempo (do kernel) , em

milissegundos, quando o ltimo
Pacotes perdidos e
duplicados
Tamanho, em bytes, do
ltimo pacote recebido
Nmero de pacotes na
fila de espera
Nmero total de bytes
manipulado pelo par
origem/destino
5.7 Trabalhos Correlatos
Nessa seo apresentado o ambiente motivador para a efetivao desse

trabalho, o QoSTalk. O QoSTalk um framework de desenvolvimento e programao
de QoS visual, que permite de forma visual especificar caractersticas especficas da
aplicao em diferentes granularidades [51]. Ele possui trs partes principais:
Construtor de Configurao Hierrquico, Exemplos de Documentao de QoS e o
Interpretador de QoS.
O Construtor de Configurao Hierrquico apresenta um conjunto de
ferramentas visuais para o desenvolvedor.
54

Qualidade de Servio
Os Exemplos de Documentao de QoS um arquivo HQML que

gerado automaticamente depois de o desenvolvedor da aplicao configurar uma
configurao possvel da aplicao.
O Interpretador de QoS traduz o arquivo HQML em um perfil que
necessrio para o framework de middleware distribudo. Durante a execuo, o
middleware instancia componentes distribudos e refora a entrega da QoS de acordo
com a informao salva no perfil de QoS.
Esse middleware o 2KQ [42], fazendo com que o QoSTalk somente
sobre uma arquitetura pr-definida e com aplicaes especficas. Ele no um ambiente
voltado para o desenvolvimento de qualquer aplicao multimdia, pois esta deve estar
em conformidade com os elementos distribudos utilizados pelo Interpretador de QoS.
O WSE, diferentemente do QoSTalk, voltado para o desenvolvimento
de qualquer aplicao multimdia, no sendo necessrio uma arquitetura distribuda prdefinida, nem a utilizao de um Sistema Operacional distribudo para que suas
especificaes sejam vlidas nas trs camadas (Usurio, Aplicao e Recurso). Alm
disso, o WSE agrega o emulador Nist Net para validar as aplicaes especificadas por
meio de resultados experimentais.
O desenvolvimento de uma aplicao no ambiente WSE e sua interao
com o Mdulo Sistema Multimdia, que, nesse trabalho, o emulador de rede Nist Net,
ser apresentado no captulo 6 na forma de estudo de caso.
55
6 - Estudo de Caso: Uma Aplicao de Vdeo Sob Demanda

O ambiente WSE de descrio de sistemas multimdia distribudos
permite que seja especificada a Qualidade de Servio de seus componentes e as regras
de adaptao. A especificao de sistemas multimdia de forma hierrquica, de modo
que a QoS possa tambm ser descrita nas Camadas de Usurio, Aplicao e Recurso,
sendo descrita pelo WSE desde a fase de especificao do sistema at a implementao
do mesmo. Este captulo apresenta um estudo de caso de uma aplicao de vdeo sob
demanda que possui aspectos de monitoramento, (re) negociao, notificao e reaes
a mudanas na QoS. Dessa forma, ficam evidenciadas as caractersticas descritas nas
camadas de Usurio, Aplicao e Recursos e comprovados os mecanismos de controle
da QoS. Sero explicitados todos os passos necessrios para a modelagem de uma
aplicao multimdia e sua posterior execuo no ambiente de emulao utilizado como
estudo de caso.
O Ambiente para Especificao de Aplicaes Multimdia com Suporte
de Qualidade de Servio, WSE, possui caractersticas pertinentes que o tornam ideal
para a descrio de sistemas capazes de representar com exatido os principais
componentes envolvidos numa aplicao multimdia distribuda, alm de poder
descrever caractersticas especficas de cada componente.
O desenvolvimento de um modelo de aplicao multimdia distribuda
acontece no ambiente WSE, primeiramente, pela escolha do tipo de aplicao a ser
modelada (video on demand, audio on demand, video conference, audio conference,
new application) e da qualidade de servio a ser mantida no sistema (high, average, low,
any). Nesse estudo de caso, foram escolhidas para a classe de aplicao video on
56
Captulo 6 Estudo de Caso: Uma Aplicao de Vdeo Sob Demanda
demand (vdeo sob demanda) e para requisitos de Qualidade de Servio high (alta).
A figura 18 ilustra essas opes.
Figura 18: Caixa de dilogos referente a classe de aplicao e a Qualidade de Servio exigidos na
camada de usurio.
necessria a escolha do tipo de aplicao e da QoS a ser aplicada pois

cada aplicao possui valores mnimos e mximos diferentes para cada parmetro, pois
a qualidade high para uma aplicao de vdeo sob demanda, necessita que a largura de
banda seja maior do que para uma aplicao de videoconferncia que tambm exija
qualidade high. Nesse ponto, fica definida a QoS que ser aplicada no nvel do
usurio, isto , a qualidade pertinente a aplicao que ser evidenciada pelo cliente,
como taxa de bits e quadros por segundo em uma transmisso de vdeo e taxa de
amostra e bits por amostra em transmisso de udio.
Aps a escolha do tipo de aplicao e da QoS exigida, o ambiente WSE
apresenta a descrio do modelo da aplicao multimdia distribuda de forma visual.
Essa representao hierrquica uma capacidade do editor de representar
por categorias cada um dos componentes, podendo ser grupo, hardware ou software. O
grupo descrito pelos componentes de cor azul, o hardware pelos de cor verde e o
software pelos componentes de cor amarela. necessrio ressaltar que cada
componente representado por uma figura geomtrica, sendo que o retngulo, losango,
crculo e retngulo arredondado representam servidor, gateway, peer e cliente,
respectivamente.
O grupo uma forma de apresentar componentes que formam um
cluster, ou um conjunto de componentes que desempenham o mesmo papel na
modelagem do sistema multimdia. J o hardware apresenta o contedo fsico das
57
mquinas envolvidas na modelagem, como largura de banda, memria, etc., enquanto o

software apresenta o sistema operacional e toda a parte que ser consumida pelo
contedo lgico da mquina descrita no hardware.
Em cada grupo, obrigatoriamente, tem-se que apresentar ao menos um
componente hardware e para cada hardware ao menos um componente software. Dessa
forma fica estruturada a representao hierrquica dos componentes na modelagem,
garantindo facilidade no entendimento do modelo, bem como na prpria gerao do
cdigo HQML. Nesse estudo de caso, foram escolhidos os componentes que descrevem
um grupo de servidores e um grupo de clientes, como descrito na Figura 19. Em cada
componente grupo escolhido, foi ainda inseridos um componente hardware e um
componente software, como se a aplicao de vdeo sob demanda fosse composta por
um servidor e um cliente.
Figura 19: Descrio de uma aplicao de vdeo sob demanda no Editor Visual de QoS
Hierrquico.
Aps a descrio do modelo no editor, o prximo passo o

preenchimento das caixas de dilogo dos componentes existentes no modelo. Cada
58
componente com exceo do componente do tipo grupo contm caixas de dilogos a

serem preenchidas com informaes pertinentes ao sistema que ser modelado, como
largura de banda, capacidade de memria RAM, capacidade do disco rgido, sistema
operacional, arquitetura da mquina (Sun, Pentium, etc.), e muitas outras informaes
teis para o funcionamento do sistema multimdia. As caixas de dilogo preenchidas
referentes aos componentes hardware e software do cliente, e hardware e software do
servidor ficaram como descrito na Figura 20, sendo as caixas de dilogo referentes ao
componente hardware aplicadas Camada de Recurso e as referentes ao software
Camada de Aplicao.
(a)
(b)
(c)
(d)
Figura 20: (a) Hardware do Servidor, (b) Software do Servidor, (c) Hardware do Cliente e (d)
Software do Cliente.
Dentre essas informaes, destacam-se as que so inseridas na caixa de

dilogo Client Software Input Dialog, pois nessa caixa de dilogo que so definidos os
59
parmetros de QoS e as regras de adaptao pertinentes a cada parmetro, alm da

ordem execuo de cada regra, se necessrio. Nesse ponto possvel inserir qualquer
parmetro que precisa ser monitorado pela aplicao, como padro, esto disponveis os
parmetros atraso (delay), variao do atraso (jitter) e loss (perda de pacotes), porm
com a possibilidade de insero/criao de qualquer parmetro que o desenvolvedor da
aplicao julgar pertinente ao sistema.
As informaes condizentes com a QoS e as regras de adaptao so
definidas na Camada de Aplicao, isto , dependendo da variao dos parmetros,
aplica-se uma regra referente ao mesmo, de acordo com a prioridade estabelecida para
cada parmetro. Essas regras, na realidade, so aes, ou codinomes para aes que
compreendem a aplicao de filtros, em tempo real, na mdia que vai ser transmitida.
Neste estudo de caso, esses filtros so converses feitas em uma streaming, podendo
variar desde a diminuio da taxa de bits, o nmero de quadros por segundo, at a
retirada do udio de um vdeo. Esses filtros podem ser encontrados em programas e
bibliotecas como o Ffmpeg [47], o Mencoder [45] e o Mplayer [45].
Aps a edio de todo o modelo, o mesmo passa por uma checagem de
consistncia por meio do Verificador de Consistncia para validar esse modelo a fim de
garantir que no exista nenhuma inconsistncia, como maior largura de banda no
software do cliente do que no hardware do cliente, alm de incompatibilidades
verificadas pela gramtica ConfigG.
Se o modelo no tiver inconsistncias, o mesmo est pronto para a
gerao do cdigo HQML referente ao que foi descrito no modelo. No HQML todo o
modelo fica representado por tags que identificam todas as suas caractersticas, desde a
definio do tipo de aplicao e QoS adotados, at os recursos de hardware que sero
consumidos pelo sistema multimdia modelado. Para que o HQML pudesse suportar as
polticas (regras) de adaptao, bem como os parmetros e uma possvel (re) negociao
da QoS, foram feitas modificaes na sua DTD para que novas tags fossem criadas para
cumprir essa finalidade. baseado no cdigo HQML que ser feito todo o mapeamento
da aplicao multimdia distribuda, da Camada de Usurio para a de Aplicao e da
Camada de Aplicao para a Camada de Recurso. O cdigo HQML gerado por esse
estudo de caso est disponvel no Apndice D.
60
Esse cdigo HQML gerado responsvel por conter todas as

informaes pertinentes ao modelo do sistema multimdia, para a partir da, haver um
mapeamento para uma aplicao capaz de agregar todas as informaes e utiliz-las
conforme descrito em suas caractersticas. Ao implementar uma aplicao que utilize as
informaes descritas no cdigo HQML, esse cdigo base fidedigna para
implementao e deve ser consultado a fim de garantir o que foi descrito na modelagem.
Essa consulta ocorre no momento em que iniciada uma aplicao. Neste momento,
chamado um executor que tem a capacidade de ler e entender os parmetros descritos
no cdigo HQML. Dessa forma, o executor detm a garantia de que os parmetros
foram interpretados de maneira correta, e que os mesmos sero passados para a
aplicao, a fim de serem utilizados na negociao e manuteno da QoS. O executor
funciona baseado em um analisador que reconhece as tags presentes no arquivo HQML
e captura seus valores. Assim, esses valores formaro uma tabela no proxy que designa
o filtro correto, por meio de comandos, dependendo do intervalo dos valores dos
parmetros.
Foi escolhido o modelo de implementao da classe de aplicao Vdeo
Sob Demanda, descrito na seo 5.6 do captulo anterior.
Por meio da emulao do Nist Net, os parmetros so medidos e, de
acordo com a variao dos mesmos, mudanas na qualidade dos vdeos so notadas
devido adoo de filtros determinados para cada faixa de valores dos parmetros. O
Nist Net alimentado por meio de um script que contm os comandos a serem
executados com os valores para os parmetros de QoS que desejam ser medidos.
Os filtros utilizados encontram-se na Tabela 6 no Apndice E e variam
de acordo com o parmetro e com o seu respectivo valor. interessante ressaltar os
valores alcanados em relao ao tamanho do arquivo original na coluna Porcentagem.
Esses valores correspondem aos tamanhos dos arquivos aps a aplicao do filtro.
Portanto, possvel obter um arquivo com pouco mais de 5% do tamanho do arquivo
original se o filtro aplicado tirar o vdeo e diminuir a qualidade do udio a 32 kbits por
segundo. Isso indica que o nmero de pacotes a serem enviados para o cliente diminui,
o que favorece a aplicao quando h uma largura de banda delimitada e quando a perda
de pacotes est alta.
61
Os resultados obtidos ao final de todo o processo so explicitados atravs

das imagens presentes na Figura 21.
Na Figura 21.a mostrado um quadro do vdeo original, isto , sem a
aplicao de nenhum filtro. J nas Figuras 21.b e 21.c so mostrados quadros aps a
utilizao dos filtros que diminuem a qualidade do vdeo pela metade e o de pior
qualidade, respectivamente. Pode ser percebido que esses quadros possuem qualidade
pior devido estarem mais quadriculados que o original. Isso ocorreu porque os filtros
que foram aplicados diminuem a taxa de amostras do vdeo, causando o efeito chamado
pixellation [1] em que pixels distintos representados por retngulos pequenos so
notados na imagem.
Esses filtros foram utilizados baseando-se na Tabela 5.
Parmetro
Perda
Largura de Banda
Delay
Jitter
Faixa de Valores
10 20%
20 24%
25 30%
31 35%
36 acima
10 50 Mbits
50 100 Mbits
100 acima
0 10000 ms
0 10000 ms
Filtro
qscale 8 ab 96
qscale 10 ab 96
qscale 15 ab 64
qscale 30 ab 32
inaceitvel
qscale 5 ab 96
qscale 30 ab 32
inaceitvel
Ignorado
Ignorado
Tabela 5: Valores dos parmetros e os respectivos filtros aplicados.
vlido ressaltar que o vdeo original tinha por volta de 3134 KB e

conforme a aplicao de cada filtro, seu tamanho final era diminudo, o que pode ser
observado pelos dados da Tabela 6 no Apndice D. Especificamente nas aplicaes dos
filtros da Tabela 5 para a soluo do aumento da perda de pacotes, os tamanhos finais
do vdeo foram:
- qscale 8 ab 96 = 2030KB;
- qscale 10 ab 96 = 1754 KB;
- qscale 15 ab 64 = 1212KB;
62
- qscale 30 ab 32 = 674KB.
Pode ser percebido que a diminuio do nmero de quadros contribui
para que o vdeo continuasse a sua reproduo, porm, isso inversamente proporcional
a qualidade do vdeo, pois, ao diminuir o nmero de quadros com a aplicao dos
filtros, a qualidade caiu causando deformaes na imagem e aumento de rudos no
udio. Os valores dos tamanhos do vdeo aps a aplicao dos filtros variou de,
aproximadamente, 64% a 21% em relao ao tamanho original, respectivamente qscale
8 ab 96 e qscale 30 ab 32.
O mesmo acontece quando ocorre a aplicao de filtros para conter os
problemas com relao a largura de banda. Neste caso, os tamanhos finais do vdeo aps
a aplicao dos filtros foram:
- qscale 5 ab 96 = 2790KB;
- qscale 30 ab 32 = 674KB.
Esses tamanhos correspondem a, aproximadamente, 89% e 21% do
tamanho original, sendo este ltimo filtro considerado o que deixa o vdeo pior, porm
ainda com a possibilidade de se ter vdeo e udio, mesmo com uma degradao dos
mesmos.
Existe ainda a possibilidade de aplicao de filtros que diminuam ainda
mais o nmero de quadros do vdeo, acarretando em arquivos com pouco mais de 5% do
tamanho original, porm estes no foram considerados na Tabela 5 por tirarem o vdeo
ou o udio completamente.
63
(a)
(b)
(c)
Figura 21: Imagens com aplicao de filtros. (a) Imagem original. (b) Imagem com aplicao do
filtro qscale 15 ab 64. (c) Imagem com aplicao do filtro qscale 30 ab 32.
Pode ser percebido que no foram aplicados filtros em relao ao atraso e

a variao do atraso, pois no foi notada nenhuma diferena no comportamento do
vdeo na variao dos valores dos mesmos desde zero at 10000 ms. Portanto, os
valores relevantes ficaram por conta da largura de banda e da perda de pacotes.
64
7 Concluses e Trabalhos Futuros

Esse trabalho descreve um ambiente para especificao de aplicaes
multimdia distribuda com detalhamento da Qualidade de Servio (WSE) exigida,
permitindo especificaes desses sistemas multimdia de forma hierrquica e restries
de QoS tambm de forma hierrquica nas Camadas de Usurio, Aplicao e Recurso.
No h na literatura tal abordagem sem restries a arquitetura e a classes de aplicaes
multimdia. Sendo as principais vantagens do WSE:
- possibilidade de ilustrar qualquer aplicao multimdia distribuda por
meio do Editor Visual de QoS Hierrquico, sem nenhuma restrio;
- ainda no Editor, o usurio pode estabelecer parmetros de QoS e regras
para adaptao/(re)negociao da aplicao multimdia distribuda, caso seja necessrio;
- a gramtica ConfigG que valida de maneira automtica a descrio feita
pelo Editor, deixando a modelagem de aplicaes multimdia distribuda extremamente
rpida, haja vista que no necessrio nenhuma implementao;
- o cdigo HQML obtido por meio do Gerador HQML, que ilustra toda a
configurao descrita pelo Editor Visual de QoS Hierrquico, bem como os parmetros
de QoS e as regras de adaptao. Este cdigo uma documentao da especificao do
sistema multimdia em linguagem de marcao que descreve todo o sistema;
- o Executor HQML que o responsvel por verificar a documentao
HQML obtida pelo Gerador HQML e configurar um sistema multimdia qualquer, seja
este um ambiente de emulao, um framework, ou um esquema de aplicao prdefinido.
65
7 Concluses e Trabalhos Futuros
O ambiente WSE avalia as aplicaes multimdia por meio de um

emulador, trazendo ao desenvolvedor resultados experimentais da aplicao, o que
facilita o desenvolvimento de tais aplicaes haja vista a rapidez na aquisio de
resultados prvios.
Para a validao de resultados foi realizado um estudo de caso utilizando
uma aplicao de vdeo sob demanda como aplicao multimdia distribuda. Como
resultado experimental, foi constatado o comportamento esperado do ambiente, bem
como da aplicao de vdeo sob demanda, haja vista que todos os mdulos realizaram
os seus papis com sucesso, e o vdeo efetivamente sofreu alteraes como adaptao s
regras descritas no Editor. A adaptao sofrida pelo vdeo e a (re)negociao da sua
QoS so fatores positivos, pois minimiza o trabalho de um desenvolvedor de aplicaes
multimdia devido fato de ele no ter que implementar todo o sistema para saber se seus
resultados sero vlidos ou no, basta utilizar o ambiente WSE com o Emulador NistNet
para tanto.
Em contrapartida ajustes devem ser feitos no WSE de maneira que mais
aplicaes multimdia distribudas possam ser implementadas, haja vista que somente
aplicaes de vdeo sob demanda so possveis de serem validadas. Por isso, como
trabalhos futuros, proposto um mapeamento automtico de uma aplicao multimdia
descrita no ambiente WSE para o emulador Nist Net, ou para outros ambientes reais
sem interferncias. Alm disso, a implementao de Executores para outras classes de
aplicao multimdia, ou mapeamento da especificao feita no ambiente WSE para
arquiteturas existentes.
66
Referncias Bibliogrficas
[1] Lu, G. Communication and Computing for Distributed Multimedia Systems.
Artech House, 1996.
[2] Gu, X.; Nahrstedt, K.; Yuan, W.; Wichadakul, D.; Xu, D. An XML-based QoS
Enabling Language for the Web, Journal of Visual Language and Computing (Special
Issue on Multimedia Languages for the Web), Publicao Acadmica, 2001.
[3] Hermann, A. C. Qualidade de Servio em Aplicaes Multimdia Distribudas,

Programa de Ps-Graduao em Cincia da Computao, 3 Semana Acadmica do
CPG-CC, Porto Alegre, 1998.
[4] Lunardi, S. C. Integrao e Qualidade de Servio na Internet, Porto Alegre,

Relatrio de Trabalho, 1999.
[5] Hansen, G. Quality of Service (QoS), Objects Services and Consulting, Inc,
Janeiro de 1997. Disponvel em http://www.objs.com/survey/QoS.htm. Acessado em 22
de julho de 2004.
[6] http://www.tticom.com/atmglosy/atmlex.htm#qos, visualizado em 22 de julho de

2004.
67
[7] Shenker, S.; Partiridge, C.; Guerin, R. Sprecification of Guaranteed Quality of

Service. RFC 2212, 1997.
[8] Vogel, L.; Kerherve, B.; Bochmann, G.; Gecse, J. Distributed Multimedia and QoS:
A Survey, IEEE Multimedia, p. 10-19, 1995.
[9] Wolf, L. C.; Griodz, C.; Steirmetz, R. Multimedia communications, Proceedings

of IEEE, vol 85, , n 12, p. 1915-1933, 1997.
[10] Li, V. O. K.; Liao, W. Distributed Multimedia Systems. Proceedings of IEEE, p.

1061-1108, 1997.
[11] Dobson, G. Quality of Service: a Service-Centric Perspective. Computer

Department, Lancaster University, 2004.
[12] Bernet, Y. et al. A Framework for Differentiated Services. Internet Draft,

Disponvel
em:
http://www.ietf.org/proceedings/98aug/I-D/draft-ietf-diffserv-
framework-00.txt. Acessado em: 15/07/2004.
[13] Nahrstedt, K.; Steinmetez, R. Resource Managemente in Networket Multimedia

Systems. IEEE Computer, pags. 52-63, 1995.
[14] Willrich, R. Dados Multimdia. Disponvel em:

http://www.sidie.nurcad.ufsc.br/treinamento/cap2.pdf. Acesso em: 15 de Julho de 2004.
68
[15] Gopal, P. M.; Wong, J. W.; Majithia, J. C., Analysis of Playout Strategis for
Voice Transmission using Packet Switching Techniques, Preformance Evaluation, vol.
4, pp. 11-18, 1984.
[16] Hehmann, D.; Salmony, M.; Stuttgen, H., Transport Services for Multimedia
Applications on Broadband Networks, Computer Communications, vol. 13, n 4, pp.
197-203, 1990.
[17] ITU ITU-T Study Group 12 Workshop on QoS and user-perceived transmission
quality in evolving networks. ITU Telecommunication Standardization Sector, 2001.
[18] Nave, C. R. HyperPhysics. Department of Physics and Astronomy. Georgia State

University,
2000.
Disponvel
em:
http://hyperphysics.phy-
astr.gsu.edu/hbase/electronic/adc.html. Acessado em: 25/07/2004.
[19] Nave, C. R. HyperPhysics. Department of Physics and Astronomy. Georgia State

University,
2000.
Disponvel
em:
http://hyperphysics.phy-
astr.gsu.edu/hbase/electronic/dac.html. Acessado em: 25/07/2004.
[20] Goulart, C. C.; Nogueira, J. M. S.; Neufeld, G. A Scheme for Dynamic QoS
Renegotiation at Intermediate Nodes. Em Wanderley Lopes de Souza and Rogrio
Drummond, editores, Anais do 15o. Simpsio Brasileiro de Redes de Computadores
(SBRC '97), pages 383-398, So Carlos, SP, 1997. UFSCar.
[21]
Federal
Standart
1037C:
Glossary
of
Telecommunications
Terms,
http://www.its.bldrdoc.gov/fs-1037, visualizado em 26/08/2003.
69
[22] Lunardi, Sediane C. Integrao e Qualidade de Servio na Internet, Porto Alegre,

1999.
[23] Jin, J.; Nahrstedt, K. Classification and Comparison of QoS Specification

Languages for Distributed Multimedia Applications, Relatrio Tcnico, University of
Illinois at Urbana-Champaign, Illinois, EUA, 2002.
[24] Nahrstedt, K.; Smith, J. M. The QoS Broker. IEEE Multimedia Magazine,
2(1):5367, 1995.
[25] Steinmetz, R.; Nahrstedt, K. Multimedia: Computing, Communications and

Applications. Prentice Hall, 1995.
[26] Nishio, N.; Tokuda, H. Simplified Method for Session Coordination Using Multilevel QoS Specification and Translation. Em Fifth International Workshop on Quality
of Service (IWQoS97), Nova Iorque, EUA, 1997.
[27] Roscoe, T.; Bowen, G. Script-driven Packet Marking for Quality of Service
Support in Legacy Applications. In Proceedings of SPIE Conference on Multimedia
Computing and Networking 2000, San Jose, CA, 2000.
[28] Levy , J. Y.; Ousterhout, J. K.; Welch, B. B.. The Safe-Tcl Security Model.
Relatrio Tcnico TR-97-60, Sun Microsystems Laboratories, 1997.
[29] Campbell, A. T. A Quality of Service Architecture. PhD thesis, Computing

Department, Lancaster University, 1996.
70
[30] Florissi, P. QoSME: QoS Management Environment. PhD thesis, Department of

Computer Science, Columbia University, 1996.
[31] Nahrstedt, K.; Li, B. Dynamic Reconfiguration for Complex Multimedia

Applications. In Proceedings of IEEE International Conference on Multimedia
Computing and Systems (IEEE ICMCS 99), Florence, Itlia, 1999.
[32]
World
Wide
Web
Consortium.
eXtensible
Markup
Language.
http://www.w3c.org/XML/, visualizado em 10/07/2004.
[33] Exposito, E.; Gineste, M.; Peyrichou, R.; Senac, P.; Diaz, M. XqoS: XML-Based
QoS Specification Language. 2002.
[34] Mendhekar, A.; Maeda, C.; Lopes, C. V.; Loingtier, J.; Irwin, J.; Kiczales, G.;
Lamping, J. Aspect-Oriented Programming. In Proceedings of the European
Conference on Object-Oriented Programming (ECOOP), Finlndia, Springer-Verlag
LNCS 1241, 1997.
[35] Zinky, J. A.; Loyall, J. P.; Schantz, R. E.; Bakken, D. E. Specifying and
Measuring Quality of Service in Distributed Object Systems. In Proceedings of
ISORC98, Kyoto, Japo, 1998.
[36] Bakken, D. E.; Zinky, J. A.; Schantz, R. D. Architectural Support for Quality of
Service for CORBA Objects. Theory and Practice of Object Systems, 1997.
[37] Schantz, R. E.; Zinky, J. A.; Karr, D. A.; Vanegas, R.; Loyall, J. P.; Bakken, D. E.;
Anderson, K. R. QoS Aspect Languages and Their Runtime Integration. Lecture
Notes in Computer Science, Springer - Verlag, 1511, 1998.
71
[38] Frolund, S.; Koistinen, J. QML: A Language for Quality of Service

Specification. Technical Report HPL-98-10, HP Laboratories, 1998.
[39] Gu, X.; Nahrstedt, K. An Event-Driven, User-Centric, QoS-aware Middleware

Framework for Ubiquitous Multimedia Applications. Proc.of 9th ACM Multimedia
(Multimedia Middleware Workshop), 2001.
[40] http://www.htmlstaff.org/xml/xml71.php, visualizado em 12/05/2003.
[41] Gu, X.; Wichadakul, D.; Nahrstedt, K.. Visual Quality of Service Programming
Environment for Ubiquitous Multimedia Services, em Proceedings of IEEE
International Conference on Multimedia and Expo 2001 (ICME2001), Tkio, Japo,
2001.
[42] Kon, F.; Campbell, R.; Mickunas, M. D.; Nahrstedt K.; Ballesteros, F. J. 2K: A
Distributed Operating System for Dynamic Heterogeneous Environments. 9th IEEE
International Symposium on High Performance Distributed Computing. Pittsburgh,
2000.
[43] Ferrucci, F.; Pacini, G.; Satta, G. Symbol-Relation Grammars: A Formalism for
Graphical Languages. Information and Computation, 131, 1996.
[44] Gu, X. Visual Quality of Service Programming Environment for Distributed

Heterogeneus Systems. University of Illinois, 2001.
[45] Mplayer The Movie Player. Disponvel em: http://www.mplayerhq.hu. Acessado

em 22/07/2004.
72
[46] The Apache Software Foundation. Disponvel em: http://www.apache.org/.

Acessado em: 22/07/2004.
[47] http://ffmpeg.sourceforge.net/. Acessado em 22/07/2004.
[48] Silva, L. C. Um Framework para Adaptao de Aplicaes Multimdia em

Ambientes de Redes Sem Fio. Dissertao de Mestrado. Universidade Federal de So
Carlos, So Carlos, 2002.
[49] http://snad.ncsl.nist.gov/itg/nistnet/. Acessado em 22/07/2004.
[50] Carson, M.; Santay, Darrin. Nist Net A Linux-based Network Emulation Tool.
National Institute of Standarts and Technology, 2002.
[51] Gu, X.; Xu, D.; Wichadakul, D.; Nahrstedt, K. QoSTalk: A Visual Quality of
Service Programming Environment, Illinois Computer Affiliates Program (ICAP)
Workshop, 2000.
73
Apndice A Cdigo do Proxy

Principais classes referentes ao componente Proxy citado no estudo de
caso descrito no captulo 6.
Classe Connection
package proxy;
import java.net.*;
import java.io.*;
public class Connection extends Thread {
//---------------------------------------------------------------------------private Socket s;
private Socket sserver;
private Server server;
private DataInputStream is;
private DataOutputStream os;
private DataInputStream serveris;
private ProxyTunnel server2client;
private ProxyTunnel server2filter;
private ProxyTunnel filter2client;
private Process process;
private OutputStream filteros;
private InputStream filteris;
private InputStream filtererr;
//---------------------------------------------------------------------------public Connection(Socket client, Server server) throws Exception {
this.s = client;
this.server = server;
this.is = new DataInputStream( s.getInputStream() );
74
Apndice A Cdigos do Proxy
this.os = new DataOutputStream( s.getOutputStream() );

this.start();
}
//---------------------------------------------------------------------------public void run() {
DataOutputStream serveros = null;
try {
byte bb[] = new byte[65536];
while ( s.isConnected() ) {
// Reading client http Header
int total = is.read(bb);
if (total<0) throw new Exception("Fim cliente!");
String header = new String(bb, 0, total, "ISO-8859-1");;
// Finding host to connect to
int hi = header.indexOf("Host") + 6;
int he = header.indexOf("\r", hi);
String host = header.substring(hi, he);
// Connecting to the host to do the proxy
sserver = new Socket(host, 80);
serveros = new DataOutputStream(sserver.getOutputStream());
serveris = new DataInputStream(sserver.getInputStream());
header = header.replaceAll("Proxy-Connection: keep-alive", "Connection: close");
System.out.println("Pedido de " + s.getInetAddress() + " para " +
sserver.getInetAddress() +
" com tamanho " + total + "(" + header.length() + ")");
serveros.writeBytes(header);
//direto
server2client = new ProxyTunnel(1, "direto", serveris, os);
// Separar e enviar cabealho sem filtrar
/*
int c1=0,c2=0,c3=0,c4=0;
String h = "";
while (c1!='\r' || c2!='\n' || c3!='\r' || c4!='\n') {
c1 = c2;
c2 = c3;
c3 = c4;
c4 = serveris.read();
h += (char)c4;
}
os.writeBytes(h);
System.out.println(h);
*/
while(isActive()) {
Thread.sleep(500);
server2client.join();
}
75
server.removeConnection(this);
}
} catch (Exception e) { e.printStackTrace(); }
}
//=============================================================
===
public boolean isActive() {
return !sserver.isClosed();
}
//=============================================================
===
public void setFilter(String filter) throws java.io.IOException {
if ( server2filter != null && filter2client != null ) {
server2filter.interrupt();
filter2client.interrupt();
filteris.close();
filteros.close();
filtererr.close();
process.destroy();
} else
server2client.interrupt();
process = Runtime.getRuntime().exec(filter);
filteros = process.getOutputStream();
filteris = process.getInputStream();
filtererr = process.getErrorStream();
server2filter = new ProxyTunnel(1, "1", serveris, filteros);
filter2client = new ProxyTunnel(1, "2", filteris, os);
server2client = server2filter;
//consumir err
new ProxyTunnel(1, "3", filtererr, new ByteArrayOutputStream(1024));
}
//=============================================================
===
public String toString() {
return s.getInetAddress().getHostAddress();
}
//=============================================================
===
}
Classe ProxyTunnel
package proxy;
76
import java.net.Socket;
import java.io.InputStream;
import java.io.OutputStream;
public class ProxyTunnel extends Thread {
//---------------------------------------------------------------------------private Socket proxy;
private OutputStream clientos;
private InputStream proxyis;
private boolean adapt = false;
private String name;
private int timeToSleep;
//---------------------------------------------------------------------------public ProxyTunnel(int timeToSleep, String name, InputStream proxyis, OutputStream
os) {
this.timeToSleep = timeToSleep;
this.name = name;
this.proxyis = proxyis;
this.clientos = os;
this.start();
}
//---------------------------------------------------------------------------public void run() {
try {
byte bb[] = new byte[65536];
while (true) {
int iii = proxyis.read(bb);
if (iii < 0)
throw new Exception("Server acabou!");
clientos.write(bb, 0, iii);
System.out.println(name + " > enviou (" + iii + ")");
clientos.flush();
Thread.sleep(timeToSleep);
}
} catch (InterruptedException e) {
System.out.println("Parei " + name);
} catch (Exception e) {
e.printStackTrace();
if ( !this.isInterrupted() ) {
try{ clientos.close(); } catch (Exception e1) { e.printStackTrace(); }
try{ proxyis.close(); } catch (Exception e1) { e.printStackTrace(); }
}
} finally {
}
}
//---------------------------------------------------------------------------}
77
Classe Server
package proxy;
import java.net.*;
//import java.io.*;
import java.util.Vector;
import java.util.Enumeration;
public class Server {
//=============================================================
===
private Vector connections = new Vector();
//=============================================================
===
public static void main(String args[]) {
try {
if (args.length != 1) {
System.out.println("Usage: Server port");
return;
}
Server server = new Server();
ServerSocket ss = new ServerSocket(Integer.parseInt(args[0]));
System.out.println("Server activated at port " + ss.getLocalPort());
ControlServer cs = new ControlServer(ss.getLocalPort()+1, server);
while (true) {
try {
server.addConnection( new Connection( ss.accept(), server ) );
}
}
//=============================================================
===
public Vector getConnections() {
return connections;
}
//---------------------------------------------------------------------------public void addConnection(Connection connection) {
connections.add(connection);
}
//---------------------------------------------------------------------------public void removeConnection(Connection connection) {
connections.remove(connection);
78
}
//=============================================================
===
}
Classe ControlServer
package proxy;
import java.net.ServerSocket;
import java.io.ObjectInputStream;
import java.io.ObjectOutputStream;
import java.util.Enumeration;
public class ControlServer extends Thread {
//=============================================================
===
private ServerSocket ss;
private Server server;
//=============================================================
===
public ControlServer( int port, Server server ) throws java.io.IOException {
this.server = server;
this.ss = new ServerSocket(port);
System.out.println("Control Server activated at port " + ss.getLocalPort());
this.start();
}
//=============================================================
===
public void run() {
while(true) {
try {
Socket s = ss.accept();
System.out.println("Controller connected.");
ObjectOutputStream oos = new ObjectOutputStream(s.getOutputStream());
ObjectInputStream ois = new ObjectInputStream(s.getInputStream());
while (true) {
System.out.println("receber commando");
String command = ois.readUTF();
if (command.equals("getConnections")) {
System.out.println("getConnections");
Vector v = new Vector();
79
Enumeration e = server.getConnections().elements();
while (e.hasMoreElements())
v.add(e.nextElement().toString());
oos.writeObject(v);
} else if (command.equals("setFilter")) {
System.out.println("setFilter");
int index = ois.readInt();
String filter = ois.readUTF();
Connection c = (Connection) server.getConnections().elementAt(index);
c.setFilter(filter);
} else if (command.equals("exit")) {
break;
}
}
}
}
//=============================================================
===
}
Classe Controller
package proxy;
import java.io.*;
public class Controller {
//=============================================================
===
public static void main(String[] args) {
System.out.println("Usage: Controller serverAddress serverPort");
return;
}
try {
Socket s = new Socket(args[0], Integer.parseInt(args[1]));
ObjectOutputStream oos = new ObjectOutputStream(s.getOutputStream());
ObjectInputStream ois = new ObjectInputStream(s.getInputStream());
BufferedReader br = new BufferedReader( new InputStreamReader(System.in) );
while(true) {
System.out.print("Command (h for help): ");
String command = br.readLine();
if (command.equals("h")) {
80
System.out.println("l - list connections");

System.out.println("s - set filter");
System.out.println("x - exit");
System.out.println("");
} else if (command.equals("l")) {
oos.writeUTF("getConnections");
oos.flush();
Vector connections = (Vector)ois.readObject();
for (int i=0; i<connections.size(); i++)
System.out.println((i+1) + " - " + connections.get(i));
} else if (command.equals("s")) {
System.out.print("Connection index: ");
int index = Integer.parseInt(br.readLine());
System.out.print("Filter command: ");
String filter = br.readLine();
oos.writeUTF("setFilter");
oos.writeInt(index-1);
oos.writeUTF(filter);
oos.flush();
} else if (command.equals("x")) {
oos.writeUTF("exit");
oos.flush();
break;
}
}
}
//=============================================================
===
}
Classe ControllerGUI
package controller;
import javax.swing.*;
import java.awt.*;
import java.awt.event.*;
import java.net.*;
import java.io.*;
import java.util.*;
public class ControllerGUI extends JFrame {
ObjectOutputStream oos;
ObjectInputStream ois;
81
JPanel jPanel1 = new JPanel();

JScrollPane jScrollPane1 = new JScrollPane();
JList jlConnections = new JList();
JButton jbRefresh = new JButton();
JButton jbExit = new JButton();
JButton jbFilter = new JButton();
JComboBox jcbFilter = new JComboBox();
public ControllerGUI(String host, int port) {
try {
Socket s = new Socket(host, port);
oos = new ObjectOutputStream(s.getOutputStream());
ois = new ObjectInputStream(s.getInputStream());
jbInit();
}
catch(Exception e) {
e.printStackTrace();
}
}
public static void main(String[] args) {
System.out.println("Usage: Controller serverAddress serverPort");
return;
}
ControllerGUI controllerGUI = new ControllerGUI(args[0],
Integer.parseInt(args[1]));
controllerGUI.setSize(600,300);
controllerGUI.setVisible(true);
}
private void jbInit() throws Exception {
this.setDefaultCloseOperation(DISPOSE_ON_CLOSE);
jbRefresh.setText("Refresh");
jbRefresh.addActionListener(new ControllerGUI_jbRefresh_actionAdapter(this));
jbExit.setText("Exit");
jbExit.addActionListener(new ControllerGUI_jbExit_actionAdapter(this));
jbFilter.setText("Filter");
jbFilter.addActionListener(new ControllerGUI_jbFilter_actionAdapter(this));
this.getContentPane().add(jPanel1, BorderLayout.NORTH);
jPanel1.add(jbRefresh, null);
jPanel1.add(jbExit, null);
jPanel1.add(jbExit, null);
this.getContentPane().add(jScrollPane1, BorderLayout.CENTER);
jScrollPane1.getViewport().add(jlConnections, null);
jcbFilter.addItem("ffmpeg -y -qscale 5 -ab 96 -f mpeg -i - -f mpeg -");
82

jcbFilter.addItem("ffmpeg -y -qscale 5 -an -f mpeg -i - -f mpeg -");
jcbFilter.addItem("ffmpeg -y -ab 96 -f mpeg -i - -f mpeg -");
jcbFilter.addItem("ffmpeg -y -vn -ab 96 -f mpeg -i - -f mpeg -");
jPanel1.add(jcbFilter, null);
jPanel1.add(jbFilter, null);
new ListUpdater(this);
}
83
void jbRefresh_actionPerformed(ActionEvent e) {
try {
int sel = jlConnections.getSelectedIndex();
oos.writeUTF("getConnections");
oos.flush();
Vector connections = (Vector) ois.readObject();
jlConnections.setListData(connections);
jlConnections.setSelectedIndex(sel);
} catch(Exception error) {
error.printStackTrace();
}
}
void jbExit_actionPerformed(ActionEvent e) {
try {
oos.writeUTF("exit");
oos.flush();
this.dispose();
}
}
void jbFilter_actionPerformed(ActionEvent e) {
if (jlConnections.getSelectedIndex()<0)
JOptionPane.showMessageDialog(null, "You may choose a connection in the list.",
"Alert", JOptionPane.PLAIN_MESSAGE);
else {
try{
oos.writeUTF("setFilter");
oos.writeInt(jlConnections.getSelectedIndex());
oos.writeUTF(jcbFilter.getSelectedItem().toString());
oos.flush();
}
}
}
}
class ListUpdater implements Runnable {
ControllerGUI adaptee;
public ListUpdater(ControllerGUI adaptee) {
this.adaptee = adaptee;
Thread thread = new Thread(this);
thread.setDaemon(true);
84
thread.start();
}
public void run() {
while (true) {
try { Thread.sleep(1000); } catch (Exception e) {}
adaptee.jbRefresh_actionPerformed(null);
}
}
}
class ControllerGUI_jbRefresh_actionAdapter implements
java.awt.event.ActionListener {
ControllerGUI_jbRefresh_actionAdapter(ControllerGUI adaptee) {
}
public void actionPerformed(ActionEvent e) {
adaptee.jbRefresh_actionPerformed(e);
}
}
class ControllerGUI_jbExit_actionAdapter implements java.awt.event.ActionListener {
ControllerGUI_jbExit_actionAdapter(ControllerGUI adaptee) {
}
adaptee.jbExit_actionPerformed(e);
}
}
class ControllerGUI_jbFilter_actionAdapter implements java.awt.event.ActionListener
{
ControllerGUI_jbFilter_actionAdapter(ControllerGUI adaptee) {
}
adaptee.jbFilter_actionPerformed(e);
}
}
85
Apndice B Conjunto Completo de Regras de Produo da

ConfigG
{AudioServer, VideoServer, MediaServer, VoiceMailRecorder,
TrackingServer, t}
{Prefetch, Tracker, Transcoder, FrameDropper, FrameFilter,
Synchronization, Broadcast, t}
{AudioPlayer, VideoPlayer, MediaPlayer, MediaRecorder,
AudioRecorder, VideoRecorder, VoiceMailRecorder, Prefetch, Tracker,
RemoteControl, t}
{AudioRecorder, VideoRecorder, MediaRecorder,
VoiceMailRecorder, AudioPlayer, VideoPlayer, MediaPlayer, Syncronization, t}.
SP: Produes de smbolos
1. S0 <{SC2, CC2}, {FixedLink(SC2, CC2)}>
2. S0 <{SC2, CC2}, {mhl(SC2, CC2)}>
3. S0 <{SC2, CC2}, {mul(SC2, CC2)}>
4. S0 <{SC2, GWC2, CC2}, {fl(SC2, GWC2), fl(GWC2, CC2)}>
5. S0 <{SC2, GWC2, CC2}, {fl(SC2, GWC2), mul(GWC2, CC2)}>
6. S0 <{SC2, GWC2, CC2}, {fl(SC2, GWC2), mhl(GWC2, CC2)}
86
Apndice B Conjunto Completo de Regras de Produo da ConfigG
7. S0 <{GC2, GC3}, {fl(GC2, GC3), fl(GC3, GC2)}>

8. S0 <{GC2, GC3}, {mul(GC2, GC3), mul(GC3, GC2)}>
9. S0 <{GC2, GC3}, {mhl(GC2, GC3), mhl(GC3, GC2)}>
10. S0 <{GC2, GC2}, {fl(GC2, GC2), fl(GWC2, GC2)}>
11. S0 <{GC2, GC2}, {mul(GC2, GC2), mul(GWC2, GC2)}>
12. S0 <{GC2, GC2}, {mhl(GC2, GC2), mhl(GWC2, GC2)}>
13. SC0 <{SC2, SC3}, 0}>
14. SC0 <{SC2, A2}, {fl(A2, SC2)}>
15. SC0 <{SC2, A2}, {fl(SC2, A2)}>
16. SC0 <{SC2, A2}, {fl(SC2, A2), fl(A2, SC2)}>
17. SC0 <{A2}, 0>
18. GWC0 <{GWC2, GWC3}, 0>
19. GWC0 <{GWC2, B2}, {fl(B2, GWC2)}>
20. GWC0 <{GWC2, B2}, {fl(GWC2, B2)}>
21. GWC0 <{GWC2, B2}, {fl(GWC2, B2), fl(B2, GWC2)}>
22. GWC0 <{B2}, 0>
23. CC0 <{CC2, CC3}, 0>
24. CC0 <{C2, CC2}, fl(C2, CC2)}>
25. CC0 <{C2, CC2}, mhl(C2, CC2)}>
26. CC0 <{C2, CC2}, mul(C2, CC2)}>
27. CC0 <{C2, CC2}, fl(CC2, C2)}>
28. CC0 <{C2, CC2}, fl(CC2, C2), fl(C2, CC2)}>
29. CC0 <{C2, CC2}, mul(CC2, C2) }>
30. CC0 <{C2, CC2}, mul(CC2, C2), mhl(C2, CC2)}>
87
31. CC0 <{C2, CC2}, mhl(CC2, CC3)}>

32. CC0 <{C2, CC2}, mhl(CC2, C2), mhl(C2, CC2)}>
33. CC0 <{C2}, 0}>
34. GC0 <{GC2, GC3}, 0}>
35. GC0 <{D2, GC2}, {fl(D2, GC2)}>
36. GC0 <{D2, GC2}, mhl(D2, GC2)}>
37. GC0 <{D2, GC2}, mul(D2, GC2)}>
38. GC0 <{GC2, D2}, mhl(D2, GC2)}>
39. GC0 <{GC2, D2}, mul(GC2, D2)}>
40. GC0 <{GC2, D2}, {fl(GC2, D2), fl(D2, GC2)}>
41. GC0 <{GC2, D2}, {mul(GC2, D2), mul(D2, GC2)}>
42. GC0 <{GC2, D2}, {mhl(GC2, D2), mhl(D2, GC2)}>
43. GC0 <{D2}, 0}>
44. A0 <{AT2}, 0}>
45. AT0 <{AT2, AT3}, 0}>
46. AT0 <{AT2, 2}, 0}>
47. AT0 <{AT2, 2}, {l(2, AT2)}>
48. AT0 <{AT2, 2}, {l(AT2, 2)}>
49. AT0 <{2}, 0}>
50. B0 <{BT2}, 0}>
51. BT0 <{BT2, BT3}, 0}>
52. BT0 <{BT2, 2}, {l(2, BT2)}>
53. BT0 <{BT2, 2}, {l(BT2, 2)}>
54. BT0 <{BT2, 2}, {l(BT2, 2), l(2, BT2)}>
88
55. BT0 <{2}, 0}>

56. C0 <{CT2}, 0}>
57. CT0 <{CT2, CT3}, 0}>
58. CT0 <{CT2, 2}, {l(2, CT2)}>
59. CT0 <{CT2, 2}, {l(CT2, 2)}>
60. CT0 <{CT2, 2}, {l(CT2, 2), l(2, CT)}>
61. CT0 <{2}, 0}>
62. D0 <{DT2}, 0}>
63. DT0 <{DT2, DT3}, 0}>
64. DT0 <{DT2, 2}, {l(2, DT2)}>
65. DT0 <{DT2, 2}, {l(DT2, 2)}>
66. DT0 <{DT2, 2}, {l(DT2, 2), l(2, DT2)}>
67. DT0 <{2}, 0}>
RP: Produes de relao
R1. fl(SC0, CC1) [13]{fl(SC2, CC1), fl(SC3, CC1)}
R2. mul(SC0, CC1) [13]{mul(SC2, CC1), mul(SC3, CC1)}
R3. mhl(SC0, CC1) [13]{mhl(SC2, CC1), mhl(SC3, CC1)}
R4. fl(SC0, CC1) [14]{fl(SC2, CC1)}
R5. mul(SC0, CC1) [14]{mul(SC2, CC1)}
R6. mhl(SC0, CC1) [14]{mhl(SC2, CC1)}
R7. fl(SC0, CC1) [15, 16, 17]{fl(A2, CC1)}
R8. mul(SC0, CC1) [15, 16, 17]{mul(A2, CC1)}
R9. mhl(SC0, CC1) [15, 16, 17]{mhl(A2, CC1)}
R10. fl(SC0, GWC1) [13]{fl(SC2, GWC1), fl(SC3, GWC1)}
89
R11. fl(SC0, GWC1) [14]{fl(SC2, GWC1)}

R12. fl(SC0, GWC1) [15, 16, 17]{fl(A2, GWC1)}
R13. fl(SC0, A1) [13]{fl(SC2, A1), fl(SC3, A1)}
R14. fl(SC0, A1) [14]{fl(SC2, A1)}
R15. fl(SC0, A1) [15, 16, 17]{fl(A2, A1)}
R16. fl(A0, SC1) [13]{fl(A1, SC2), fl(A1, SC3)}
R17. fl(A1, SC0) [14, 17]{fl(A1, A2)}
R18. fl(A1, SC0) [15, 16]{fl(A1, SC2)}
R19. fl(GWC0, CC1) [18]{fl(GWC2, CC1), fl(GWC3, CC1)}
R20. mul(GWC0, CC1) [18]{mul(GWC2, CC1), mul(GWC3, CC1)}
R21. mhl(GWC0, CC1) [18]{mhl(GWC2, CC1), mhl(GWC3, CC1)}
R22. fl(GWC0, CC1) [19]{fl(GWC2, CC1)}
R23. mhl(GWC0, CC1) [19]{mhl(GWC2, CC1)}
R24. mul(GWC0, CC1) [19]{mul(GWC2, CC1)}
R25. fl(GWC0, CC1) [20, 21, 22]{fl(B2, CC1)}
R26. mhl(GWC0, CC1) [20, 21, 22]{mhl(B2, CC1)}
R27. mul(GWC0, CC1) [20, 21, 22]{mul(B2, CC1)}
R28. fl(GWC0, CC1) [18]{l(GWC2, CC1), l(GWC3, GC1)}
R29. mul(GWC0, CC1) [18]{mul(GWC2, CC1), mul(GWC3, GC1)}
R30. mhl(GWC0, CC1) [18]{mhl(GWC2, CC1), mhl(GWC3, GC1)}
R31. fl(GWC0, CC1) [19]{fl(GWC2, GC1)}
R32. mul(GWC0, CC1) [19]{mul(GWC2, GC1)}
R33. mhl(GWC0, CC1) [19]{mhl(GWC2, GC1)}
R34. fl(GWC0, CC1) [20, 21, 22]{fl(B2, GC1)}
90
R35. mhl(GWC0, CC1) [20, 21, 22]{mhl(B2, GC1)}

R36. mul(GWC0, CC1) [20, 21, 22]{mul(B2, GC1)}
R37. fl(GWC0, B1) [18]{fl(GWC2, B1), l(GWC3, B1)}
R38. fl(GWC0, B1) [19]{fl(B3, B1)}
R39. fl(GWC0, B1) [20, 21, 22]{fl(B2, B1)}
R40. fl(B1, GWC0) [18]{fl(B1, GWC2), l(B1, GWC3)}
R41. fl(B1, GWC0) [19, 22]{fl(B1, B2)}
R42. fl(B1, GWC0) [20, 21]{fl(B1, GWC2)}
R43. fl(CC0, C1) [23]{fl(CC2, C1), fl(CC3, C1)}
R44. mhl(CC0, C1) [23]{mhl(CC2, C1), mhl(CC3, C1)}
R45. mul(CC0, C1) [23]{mul(CC2, C1), mhl(CC3, C1)}
R46. fl(CC0, C1) [24, 25, 26]{fl(CC2, C1)}
R47. mul(CC0, C1) [24, 25, 26]{mul(CC2, C1)}
R48. mhl(CC0, C1) [24, 25, 26]{mhl(CC2, C1)}
R49. fl(CC0, C1) [27, 28, 29, 30, 31, 32, 32, 33]{fl(C2, C1)}
R50. mhl(CC0, C1) [29, 30, 31, 32, 32, 33, 34, 35]{mhl(C2, C1)}
R51. mul(CC0, C1) [27, 28, 29, 30, 31, 32, 33]{mul(C2, C1)}
R52. fl(C1, CC0) [23]{fl(C1, CC2), fl(C1, CC3)}
R53. mhl(C1, CC0) [23]{mhl(C1, CC2), mhl(C1, CC3)}
R54. mul(C1, CC0) [23]{mul(C1, CC2), mul(C1, CC3)}
R55. fl(C1, CC0) [24, 25, 26, 33]{fl(C1, C2)}
R56. mul(C1, CC0) [24, 25, 26, 33]{mul(C1, C2)}
R57. mhl(C1, CC0) [24, 25, 26, 33]{mhl(C1, C2)}
R58. fl(C1, CC0) [27, 28, 29, 30 ,31 ,32] {fl(C1, CC2)}
91
R59. mhl(C1, CC0) [27, 28, 29, 30 ,31 ,32] {mhl(C1, CC2)}
R60. mul(C1, CC0) [27, 28, 29, 30 ,31 ,32] {mul(C1, CC2)}
R61. fl(D1, GC0) [34] {fl(D1, GC2), fl(D1, GC3)}
R62. mhl(D1, GC0) [34] {mhl(D1, GC2), mhl(D1, GC3)}
R63. mul(D1, GC0) [34] {mul(D1, GC2), mul(D1, GC3)}
R64. fl(D1, GC0) [35, 36, 37, 43] {fl(D1, D2)}
R65. mhl(D1, GC0) [35, 36, 37, 43] {mhl(D1, D2)}
R66. mul(D1, GC0) [35, 36, 37, 43] {mul(D1, D2)}
R67. fl(D1, GC0) [38, 39, 40, 41, 42] {fl(D1, GC2)}
R68. mhl(D1, GC0) [38, 39, 40, 41, 42] {mhl(D1, GC2)}
R69. mul(D1, GC0) [38, 39, 40, 41, 42] {mul(D1, GC2)}
R70. fl(GC0, D1) [34] {fl(GC2, D1), fl(GC3, D1)}
R71. mul(GC0, D1) [34] {mul(GC2, D1), mul(GC3, D1)}
R72. mhl(GC0, D1) [34] {mhl(GC2, D1), mhl(GC3, D1)}
R73. fl(GC0, D1) [35, 36, 37] {fl(GC2, D1)}
R74. mhl(GC0, D1) [35, 36, 37] {mhl(GC2, D1)}
R75. mul(GC0, D1) [35, 36, 37] {mul(GC2, D1)}
R76. fl(GC0, D1) [38, 39, 40, 41, 42, 43] {fl(D2, D1)}
R77. mhl(GC0, D1) [38, 39, 40, 41, 42, 43] {mhl(D2, D1)}
R78. mul(GC0, D1) [38, 39, 40, 41, 42, 43] {mul(D2, D1)}
R79. fl(GC0, GWC1) [34] {fl(GC2, GWC1), fl(GC3, GWC1)}
R80. mul(GC0, GWC1) [34] {mul(GC2, GWC1), mul(GC3, GWC1)}
R81. mhl(GC0, GWC1) [34] {mhl(GC2, GWC1), mhl(GC3, GWC1)}
R82. fl(GC0, GWC1) [35, 36, 37] {fl(GC2, GWC1)}
92
R83. mhl(GC0, GWC1) [35, 36, 37] {mhl(GC2, GWC1)}

R84. mul(GC0, GWC1) [35, 36, 37] {mul(GC2, GWC1)}
R85. mul(GC0, GWC1) [38, 39, 40, 41, 42, 43] {fl(D2, GWC1)}
R86. mhl(GC0, GWC1) [38, 39, 40, 41, 42, 43] {mhl(D2, GWC1)}
R87. mul(GC0, GWC1) [38, 39, 40, 41, 42, 43] {mul(D2, GWC1)}
R88. l(AT0, 1) [45] {mul(AT2, 1), l(AT3, 1)}
R89. l(AT0, 1) [46] {l(AT2, 1)}
R90. l(AT0, 1) [47, 48, 49] {l(2, 1)}
R91. l(0, AT0) [45] {l(1, AT2), l(1, AT3)}
R92. l(0, AT0) [46, 49] {l(1, 2)}
R93. l(0, AT0) [47, 48] {l(1, AT2)}
R94. l(BT0, 1) [51] {l(BT1, 2), l(BT3, 1)}
R95. l(BT0, 1) [55] {l(BT2, 1)}
R96. l(BT0, 1) [53, 54, 55] {l(2, 1)}
R97. l(1, BT0) [51] {l(1, BT2), l(1, BT3)}
R98. l(1, BT0) [52, 55] {l(1, 2)}
R99. l(1, BT0) [53, 54] {l(1, BT2)}
R100. l(CT0, 1) [57] {l(CT2, 1), l(CT3, 1)}
R101. l(CT0, 1) [58] {l(CT2, 1)}
R102. l(CT0, 1) [59, 60, 61] {l(2, 1)}
R103. l(1, CT0) [57] {l(1, CT2), l(1, CT3)}
R104. l(1, CT0) [58, 61] {l(1, 2)}
R105. l(1, CT0) [59, 60] {l(1, CT2)}
R106. ml(DT0, 1) [63] {l(DT2, 1), l(DT3, 1)}
93
R107. l(DT0, 1) [64] {l(DT2, 1)}

R108. l(DT0, 1) [65, 66, 67] {l(2, 1)}
R109. l(1, DT0) [63] {l(1, DT2), l(1, DT3)}
R110. l(1, DT0) [64, 67] {l(1, 2)}
R111. l(1, DT0) [65, 66] {l(1, DT2)}
94
Apndice C Cdigo HQML especificado no Estudo de Caso

<HQML>
<User Preferences>
<Application Type>
Video On Demand
</Application Type>
<Desired QoS>
High
</Desired QoS>
</User Preferences>
<Application Name>
Case Study
</Application Name>
<ServerGroup>
<Server>
<Name>
Hardware Server
</Name>
<Category>
Server
</Category>
<NodeLabel>
0
</NodeLabel>
PC PentiumIII
Windows 2000
<Memory>
512000 KB
95
Apndice C Cdigo HQML Especificado no Estudo de Caso
</Memory>
<Disk>
80000 MB
</Disk>
<Bandwidth>
100 Mbits
</Bandwidth>
<AtomicComponent>
<Name>
Software Server
</Name>
<Category>
Server
</Category>
<NodeLabel>
0
</NodeLabel>
<Memory>
256000KB
</Memory>
<Disk>
40000MB
</Disk>
<Bandwidth>
100Mbits
</Bandwidth>
</AtomicComponent>
</Server>
</ServerGroup>
<ClientGroup>
<Client>
<Name>
Hardware Client
</Name>
<Category>
Client
</Category>
<NodeLabel>
1
</NodeLabel>
PC PentiumIII
Windows 2000
<Memory>
512000KB
96
</Memory>
<Disk>
50000MB
</Disk>
<Bandwidth>
100Mbits
</Bandwidth>
<AtomicComponent>
<Name>
Software Client
</Name>
<Category>
Client
</Category>
<NodeLabel>
1
</NodeLabel>
<Memory>
256000KB
</Memory>
<Disk>
20000MB
</Disk>
<Bandwidth>
100Mbits
</Bandwidth>
<QoSParameters>
<Delay>
<Min>
0
</Min>
<Max>
1
</Max>
</Delay>
<AdaptationRules>
<Rule>
<Name>
Rule1
</Name>
<Order>
101
</Order>
</Rule>
<Rule>
<Name>
Rule2
</Name>
97
<Order>
102
</Order>
</Rule>
</AdaptationRules>
<Jitter>
<Min>
0
</Min>
<Max>
1
</Max>
</Jitter>
<AdaptationRules>
<Rule>
<Name>
Rule1
</Name>
<Order>
201
</Order>
</Rule>
<Rule>
<Name>
Rule3
</Name>
<Order>
202
</Order>
</Rule>
</AdaptationRules>
<Loss>
<Min>
0
</Min>
<Max>
1
</Max>
</Loss>
<AdaptationRules>
<Rule>
<Name>
Rule4
</Name>
<Order>
301
</Order>
</Rule>
98
<Rule>
<Name>
Rule6
</Name>
<Order>
302
</Order>
</Rule>
</AdaptationRules>
</QoSParameters>
</AtomicComponent>
</Client>
</ClientGroup>
</HQML>
99
Apndice D Tabela 6
100

Ambiente para Especificação de Aplicações Multimídia Com Suporte de Qualidade de Serviço

Încărcat de

Informații document

Titlu original

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

Ambiente para Especificação de Aplicações Multimídia Com Suporte de Qualidade de Serviço

Încărcat de

Drepturi de autor:

Formate disponibile

UNIVERSIDADE FEDERAL DE SO CARLOS

CENTRO DE CINCIAS EXATAS E DE TECNOLOGIA

Ambiente para Especificao de Aplicaes

Wesley Barbosa Thereza

Ficha catalogrfica elaborada pelo DePT da

Thereza, Wesley Barbosa.

Dedico este trabalho a Deus, meus pais e irmos

Inicialmente a minha famlia pai (Testa), me (Gansa) e irmos

Em especial ao grande amigo Fernando (Bocudo). Acho que aps todo

This work describes an environment for specification of distributed

5.5 - Executor HQML ...............................................................................................48

fim de analisar os resultados dessa especificao por meio de um sistema multimdia

O captulo 4 descreve a linguagem de especificao de sistemas proposta

Apesar de Qualidade de Servio (QoS) no ser um conceito novo,

Captulo 2 Qualidade de Servio

Abaixo esto algumas definies no nvel de comunicao utilizadas

O International Telecommunication Union (ITU), refere-se a QoS

como "Um conjunto de requisitos de qualidade de comportamento coletivo de um ou

A ATM Lexicon define em [6] QoS como "Um termo que se

refere a um conjunto de parmetros de desempenho ATM que caracteriza o trfego

J em [7], os autores definem que Qualidade de Servio um

Streams: fluxos de dados multimdia.

Captulo 2 Qualidade de Servio

2.2 - Mapeamento de QoS

Dobson em [11] trata QoS em sistemas multimdia distribudos,

Figura 1: Modelo conceitual de QoS.

Captulo 2 Qualidade de Servio

2.2.1 - QoS de Usurio

2.2.2 - QoS de Aplicao

Captulo 2 Qualidade de Servio

2.2.3 - QoS de Sistema (Software e Hardware)

Os parmetros dessa camada representam caractersticas de cada host

Captulo 2 Qualidade de Servio

Captulo 2 Qualidade de Servio

Taxa de Dados (kbit/s)

Na Tabela 1 e na Figura 2 possvel perceber que as mdias digitais

Captulo 2 Qualidade de Servio

Figura 2: Requisitos de armazenamento para algumas mdias. [Willrich, 2004]

2.2.4 - QoS de Rede

Captulo 2 Qualidade de Servio

udio e vdeo digitais so mdias contnuas dependentes do tempo, e por

ADC (Analog to Digital Converter): converso de analgico para digital. [18]

Captulo 2 Qualidade de Servio

Considerando QoS como sendo o conjunto de caractersticas que um

Captulo 2 Qualidade de Servio

Figura 3: Esquema funcional do controle da Qualidade de Servio.

Os parmetros de QoS devem ser escolhidos de acordo com o ambiente

Captulo 2 Qualidade de Servio

3 - Linguagens de Especificao de Qualidade de Servio para

Tipicamente, o gerenciamento de aplicaes multimdia distribudas

devem permitir descries de parmetros de QoS quantitativos e

qualitativos, assim como regras de adaptao;

devem ser informativas, isto , devem especificar somente o que

Captulo 3 Linguagens de Especificao de QoS para Aplicaes Multimdia

precisam ser acompanhadas por um processo de mapeamento e

Captulo 3 Linguagens de Especificao de QoS para Aplicaes Multimdia

3.1 - Particionamento das Linguagens de Especificao de QoS em

O particionamento em camada necessrio porque especificaes em

Camada de Usurio (critrios subjetivos)

Camada da Aplicao (independente de hardware

Camada de Recurso (dependente de hardware e

Tabela 2: QoS para as trs camadas: Usurio, Aplicao e Recurso.

Captulo 3 Linguagens de Especificao de QoS para Aplicaes Multimdia