dissertaÇÃo apresentada à utfpr para obtenção do título de · karina paula de camargo curcio...
TRANSCRIPT
UNIVERSIDADE TECNOLÓGICA FEDERAL DO PARANÁ Programa de Pós-Graduação em Engenharia Elétrica e Informática Industrial
DISSERTAÇÃO apresentada à UTFPR
para obtenção do título de
MESTRE EM CIÊNCIAS
por
KARINA PAULA DE CAMARGO CURCIO
ADAPTAÇÃO E ANÁLISE DE UM SISTEMA
PUBLISH/SUBSCRIBE PARA TRANSMISSÃO DE FLUXOS
CONTÍNUOS EM REDES 802.11G
Banca Examinadora:
Presidente e Orientador:
PROF. DR. LUIZ NACAMURA JÚNIOR UTFPR
Examinadores:
PROFa. DRa. ANELISE MUNARETTO FONSECA UTFPR
PROF. DR. CARLOS MONTEZ UFSC
PROF. DR. LAU CHEUK LUNG PUC - PR
Curitiba, Maio 2006.
KARINA PAULA DE CAMARGO CURCIO
ADAPTAÇÃO E ANÁLISE DE UM SISTEMA PUBLISH/SUBSCRIBE PARA
TRANSMISSÃO DE FLUXOS CONTÍNUOS EM REDES 802.11G
Dissertação apresentada ao Programa de Pós-
Graduação em Engenharia Elétrica e Informática
Industrial da Universidade Tecnológica Federal do
Paraná, como requisito parcial para a obtenção do
título de “Mestre em Ciências” – Área de
Concentração: Telemática.
Orientador: Prof. Dr. Luiz Nacamura Júnior
Curitiba
2006
iii
"A mente que se abre a uma nova idéia
jamais voltará ao seu tamanho original”.
Albert Einstein
iv
Agradecimentos
Em primeiro lugar agradeço aos meus pais Leonel Ricardo Curcio Jr. e Maria
Aparecida de Camargo Curcio por me proporcionarem condições para a realização deste
trabalho, sempre me apoiando e incentivando a buscar novos desafios.
Meu agradecimento especial a meu orientador Professor Luiz Nacamura Júnior que
acreditou no meu potencial e com muita paciência me aconselhou durante a realização deste
trabalho.
Ao meu querido noivo, Cláudio Marcio, cujo amor, carinho e compreensão foram
essenciais durante os anos de estudo.
Aos amigos do Laboratório de Sistema Distribuídos (LaSD) pela colaboração e pela
companhia que tivemos ao longo da execução do trabalho.
A minha eterna gratidão a todos os meus amigos, familiares, colegas da CELEPAR e
professores que, direta ou indiretamente, me acompanharam e me apoiaram para a
concretização deste sonho.
v
Sumário
1 Introdução ..............................................................................................................................1 1.1 Motivações ......................................................................................................................1 1.2 Objetivo...........................................................................................................................2 1.3 Trabalhos Relacionados ..................................................................................................2 1.4 Organização do Documento ............................................................................................4
2 Paradigma Publish/Subscribe ................................................................................................5 2.1 Introdução........................................................................................................................5 2.1.1 Passagem de Mensagens...........................................................................................6 2.1.2 Invocação Remota ....................................................................................................6 2.1.3 Espaços Compartilhados ..........................................................................................6 2.1.4 Filas de Mensagens...................................................................................................7
2.2 A Interação Publish/Subscribe ........................................................................................7 2.2.1 Independência em relação ao espaço........................................................................9 2.2.2 Independência em relação ao tempo.........................................................................9 2.2.3 Independência em relação ao fluxo de execução....................................................10
2.3 Considerações Gerais ....................................................................................................10 2.4 Arquiteturas Publish/Subscribe.....................................................................................11 2.4.1 Arquitetura Centralizada.........................................................................................11 2.4.2 Arquitetura Distribuída...........................................................................................12 2.4.2.1 Distribuição Física...............................................................................................12 2.4.2.2 Distribuição Lógica .............................................................................................14
2.5 Conclusão......................................................................................................................14 3 Redes Locais Sem Fio (802.11) ...........................................................................................16 3.1 Introdução......................................................................................................................16 3.2 O Padrão 802.11............................................................................................................17 3.2.1 A Interação entre os componentes da rede .............................................................18 3.2.2 Autenticação e Associação .....................................................................................20
3.3 Segurança ......................................................................................................................22 3.4 Mobilidade ....................................................................................................................25 3.5 Qualidade de Serviço em Redes 802.11........................................................................27 3.5.1 Requisitos ...............................................................................................................27 3.5.1.1 Latência ...............................................................................................................28 3.5.1.2 Jitter de atraso .....................................................................................................29 3.5.1.3 Largura de banda.................................................................................................29 3.5.1.4 Confiabilidade .....................................................................................................29
3.5.2 Categorização das Aplicações ................................................................................30 3.5.2.1 Classe Conversational.........................................................................................30 3.5.2.2 Classe Streaming .................................................................................................30 3.5.2.3 Classe Interactive ................................................................................................30 3.5.2.4 Classe Background..............................................................................................30
3.5.3 Transmissão de Fluxos Contínuos em Redes sem Fio ...........................................31 3.5.3.1 Maior taxa de erros..............................................................................................31 3.5.3.2 Mobilidade ..........................................................................................................31 3.5.3.3 Compartilhamento de Canal................................................................................32 3.5.3.4 Comportamento das interfaces ............................................................................32 3.5.3.5 Variabilidade .......................................................................................................32 3.5.3.6 Requisitos de Tempo Real...................................................................................32
3.5.4 A utilização do protocolo UDP ..............................................................................32
vi
3.5.4.1 Baixo Isolamento.................................................................................................33 3.5.4.2 Tamanho dos pacotes ..........................................................................................33
3.5.5 Políticas de adaptação.............................................................................................34 3.5.5.1 Bufferização ........................................................................................................34 3.5.5.2 Retransmissão......................................................................................................34 3.5.5.3 Adaptação do Conteúdo ......................................................................................34
3.6 Conclusão......................................................................................................................35 4 Modelo Publish/Subscribe para redes sem fio.....................................................................36 4.1 Introdução......................................................................................................................36 4.2 A Arquitetura.................................................................................................................36 4.2.1 Estrutura dos Coordenadores..................................................................................38 4.2.2 Estrutura dos MSS..................................................................................................39 4.2.3 Infra-estrutura de Comunicação .............................................................................40 4.2.4 Infra-estrutura de Comunicação publish/subscribe ................................................40
4.3 Ferramentas e Linguagens de Programação Utilizadas.................................................41 4.3.1 Java .........................................................................................................................41 4.3.2 JMS.........................................................................................................................42 4.3.2.1 Modelos de Mensagens JMS...............................................................................42 4.3.2.2 Elementos do modelo Publish/Subscribe ............................................................43
4.3.3 Protocolo Multicast (LRMP)..................................................................................44 4.4 Interação dos Componentes ..........................................................................................46
4.4.1 Scanning .................................................................................................................46 4.4.2 Subscribe ................................................................................................................49 4.4.3 Publish ....................................................................................................................50 4.4.4 Deslocamento .........................................................................................................55 4.4.5 Unsubscribe ............................................................................................................57
4.5 Conclusão......................................................................................................................58 5 Modelo de Implementação...................................................................................................60 5.1 Introdução......................................................................................................................60 5.2 Arquitetura do Sistema..................................................................................................61 5.3 Cenários.........................................................................................................................62 5.3.1 Cenário nº 1 ............................................................................................................63 5.3.2 Cenário nº 2 ............................................................................................................65 5.3.3 Cenário nº 3 ............................................................................................................67 5.3.4 Cenário nº 4 ............................................................................................................69
5.4 Conclusão......................................................................................................................70 6 Conclusões Gerais................................................................................................................72 6.1 Trabalhos Futuros..........................................................................................................72
7 Referências...........................................................................................................................74
vii
Índice de Figuras
Figura 1 - Interações do modelo Publish/Subscribe .....................................................................8 Figura 2 - Modelo de Independência em relação ao espaço.........................................................9 Figura 3 - Modelo de Independência em relação ao tempo........................................................10 Figura 4 - Modelo de Independência em relação ao fluxo de execução.....................................10 Figura 5 - Serviços estendidos (ESS – Extended Service Set) ...................................................17 Figura 6 - Scanning através do modo passivo ............................................................................19 Figura 7 - Scanning através do modo ativo ................................................................................19 Figura 8 - Processo de Autenticação e Associação ....................................................................21 Figura 9 - Possíveis Processos de Autenticação no 802.11........................................................22 Figura 10 - Entidades envolvidas (802.1x).................................................................................25 Figura 11 - Roaming restrito.......................................................................................................27 Figura 12 - Cenário de integração (rede fixa / redes móveis) ....................................................37 Figura 13 - Arquitetura Publish/Subscribe .................................................................................37 Figura 14 - Estrutura do Coordenador........................................................................................39 Figura 15 - Estrutura do MSS.....................................................................................................39 Figura 16 - Configuração da Infra-estrutura...............................................................................41 Figura 17 - Modo Persistente .....................................................................................................44 Figura 18 - Modo Não Persistente..............................................................................................44 Figura 19 - Scanning ..................................................................................................................47 Figura 20- Processo de Associação ............................................................................................48 Figura 21 - Processo de Subscrição............................................................................................50 Figura 22 - Processo de Publicação de Eventos .........................................................................51 Figura 23 - Envio do evento ao subscriber.................................................................................52 Figura 24 - Confirmação do Recebimento .................................................................................53 Figura 25 - Leitura do buffer ......................................................................................................54 Figura 26 - Procedimento de Deslocamento...............................................................................55 Figura 27 - Reenvio da Subscrição.............................................................................................56 Figura 28 - Validação do Coordenador ......................................................................................57 Figura 29 - Processo de Cancelamento da Subscrição ...............................................................58 Figura 30 - Ambiente de Implementação ...................................................................................61 Figura 31 - Resultados obtidos utilizando o parâmetro de confiabilidade LimitedLoss.............64 Figura 32 - Resultados obtidos utilizando o parâmetro de confiabilidade LossAllowed............66 Figura 33 - Resultados obtidos utilizando o parâmetro de confiabilidade NoLoss. ...................68 Figura 34 - Resultados obtidos utilizando o parâmetro de confiabilidade BestEffort. ...............69
viii
Índice de Tabelas
Tabela 1 - Tabela de configuração do sistema ...........................................................................62 Tabela 2 - Taxa de perda de pacotes utilizando parâmetro LimitedLoss....................................65 Tabela 3 - Taxa de perda de pacotes utilizando parâmetro LossAllowed...................................66 Tabela 4 - Taxa de perda de pacotes utilizando parâmetro NoLoss. ..........................................68 Tabela 5 - Taxa de perda de pacotes utilizando parâmetro BestEffort. ......................................70
ix
Lista de Abreviaturas
IEEE Institute of Electrical and Electronics Engineers
MOM Message Oriented Middleware
XGSP XML Based General Session Protocol
MMCS Global Multimedia Collaboration System
QoS Qualidade de Serviço
RMI Remote Method Invocation
CORBA Common Object Request Broker Architecture
DCOM Distributed Component Object Model
RPC Remote Procedure Call
DSM Distributed Shared Memory
OSI Opens System Interconnection of the International Standardization
Organization
BSS Basic Service Set
ESS Extended Service Set
BSSID Basic Service Set Identification
DS Distribution System
AP Access Point
MAC Medium Access Control
IAPP Inter Access Point Protocol
SSID Service Set Identifier
ACL Access Control List
WEP Wired Equivalent Privacy
PRNG Pseudo Random Number Generator
CRC Cyclic Redundancy Check
IV Initialization Vector
ICV Integrity Check Value
RSN Robust Security Network
Wi-Fi Wireless Fidelity
WPA Wi-Fi Protected Access
TKIP Temporal Key Integrity Protocol
EAP Extensible Authentication Protocol
WLAN Wireless Local Area Network
ACL Access Control List
x
IP Internet Protocol
ETSI European Telecommunications Standards Institute
IETF Internet Engineering Task Force
IPv4 Internet Protocol version 4
IPv6 Internet Protocol version 6
RFC Request for Comments
FTP File Transfer Protocol
SMS Short Message Service
BER Bit Error Rate
TCP Transmission Control Protocol
UDP User Datagram Protocol
ARC Automatic Repeat Request
FEC Forward Error Correction
MPEG Motion Picture Experts Group
WANs Wide Área Networks
MSS Mobile Support Station
JMS Java Message Service
J2EE Java 2 Enterprise Edition
API Application Software Interface
LRMP Light-weight Reliable Multicasting Protocol
RTP Real Time Protocol
RTCP Real Time Transport Control Protocol
REP Random Expanding Probe
ACK Acknowledgement
NACK Negative Acknowledgement
AID Association Identifier
DHCP Dynamic Host Configuration Protocol
MTU Maximum Transfer Unit
PCI Peripheral Component Interconnect
USB Universal Serial Bus
xi
Resumo
Crescentes trabalhos estão sendo realizados na área de comunicação distribuída,
especialmente utilizando aplicações baseadas no paradigma de comunicação publish/subscribe.
Baseadas nisso novas linhas de pesquisa estão sendo propostas. A vantagem da utilização desse
paradigma está principalmente relacionada ao fato de prover uma fraca forma de interação
entre os membros do sistema. Dessa maneira é possível desenvolver aplicações distribuídas
bem estruturadas, flexíveis e altamente escaláveis. Nesse contexto, este trabalho se propõe a
realizar adaptações em um modelo baseado no paradigma publish/subscribe, anteriormente
proposto, para possibilitar a utilização de fluxos contínuos sobre uma rede 802.11g. O objetivo
desse trabalho é analisar o comportamento do sistema e verificar se o modelo proposto atende
aos requisitos de qualidade de serviço peculiares a tais aplicações.
xii
Abstract
Works have been emerged in distributes communication area, especially using
publish/subscribe communication paradigm. Based on that new lines of researches are been
proposed. The advantage of using this communication paradigm is mainly related to the fact of
provides a loosely coupled form of interaction among members of the system. In this way is
possible to develop well structured, flexible and highly scalable applications. In this context
this paper proposes some adaptations in a previous proposed model based on publish/subscribe
paradigm to make possible the use of continuous flows over an 802.11g network. The goal of
this paper is to analyze the behavior of the system and verify if the proposed model achieves
the specifics quality of service requirements to such applications.
1
1 Introdução
1.1 Motivações
Com a expansão da Internet, surgiu a necessidade de manter-se sempre informado e mais
que isso, atualizado. A velocidade dos fatos e acontecimentos deve, atualmente, caminhar
paralelamente com a distribuição das informações. Por esse motivo, cada vez mais as redes
sem fio estão ganhando maiores espaços no mercado. Elas permitem a mobilidade dos usuários
e isso agrega valor a qualquer aplicação. A partir disso, vários estudos estão sendo
desenvolvidos nesta área, principalmente utilizando as redes locais com padrão 802.11 (IEEE,
2001).
Além dessas tecnologias, que acabaram se tornando padrões efetivos no mercado, houve
a necessidade de se criar aplicações capazes de atender as peculiaridades de cada um desses
padrões. A maioria das aplicações, hoje no mercado, foi desenvolvida para atender os
requisitos das redes fixas e, portanto se torna uma tarefa complexa a tentativa de se obter os
mesmos resultados alcançados nestas redes.
Vários estudos estão sendo desenvolvidos para a criação de aplicações que possam ser
utilizadas em ambientes abertos, heterogêneos e distribuídos. A utilização de aplicações
baseada em eventos, definida em (ORVALHO, 1999) como uma ocorrência de um ponto de
interação entre dois objetos computáveis de um sistema, é um paradigma emergente. Uma
extensão desse modelo é o paradigma publish/subscribe que tem sido foco de inúmeros estudos
na área de desenvolvimento de aplicações para sistemas distribuídos como, por exemplo, os
sistemas Siena (CARZANIGA, 2000), Rebeca (MÜHL et al., 2004), Hermes (PIETZUCH,
2004).
Apesar das redes sem fio apresentarem vários complicadores, o estudo e o
desenvolvimento de aplicações para atender estas necessidades se torna bastante desafiante.
Com o crescimento da utilização da Internet surgiu uma alternativa para a disponibilização de
arquivos multimídia como, por exemplo, voz e vídeo. Devido à pouca largura de banda
disponível nas redes atuais em uso, o tráfego gerado por essas aplicações requer uma atenção
especial. A transmissão de arquivos multimídia exige um esforço no que diz respeito à
investigação dos parâmetros e requisitos de qualidade de serviço.
Atento a tantas tecnologias emergentes e motivado a partir da análise de estudos
previamente realizados, este trabalho propõe a adaptação de uma arquitetura, anteriormente
proposta, para o transporte de fluxo contínuo de vídeo sobre uma rede sem fio.
2
1.2 Objetivo
Neste trabalho é apresentada uma proposta de adaptação do modelo definido por
(DEQUECH, 2003) para a transmissão de arquivos multimídia, especificamente arquivos de
vídeo, sobre uma rede 802.11g. O modelo proposto anteriormente tinha como objetivo a
definição de um modelo, adaptado da arquitetura publish/subscribe, para redes móveis. Para
tanto foi desenvolvido um protótipo com base no modelo proposto e foram realizadas
simulações com envio de mensagens do tipo texto.
Portanto a partir de estudos crescentes, tanto na área de aplicações baseadas em redes
sem fio quanto na utilização de arquivos multimídia, sentiu-se a necessidade de aprofundar os
estudos já realizados e adaptar o modelo existente para atender os requisitos peculiares de tais
aplicações. Para isso, além de implementar essas adaptações foram realizadas algumas
simulações, com o objetivo de se encontrar valores adequados em termos de requisitos de
qualidade de serviço, variando os níveis de confiabilidade do protocolo de comunicação de
grupo.
1.3 Trabalhos Relacionados
Atualmente várias aplicações comerciais vem sendo desenvolvidas utilizando a
arquitetura publish/subscribe, pois a partir dela é possível que diferentes componentes de
negócio se integrem, formando um sistema confiável e flexível. Além dos tradicionais
fornecedores de produtos MOM´s (Message Oriented Middleware) outras empresas estão
desenvolvendo aplicações baseadas em trocas e mensagens, pois estão se tornando
componentes essenciais na integração de operações corporativas.
Este crescente aumento da utilização de ferramentas baseado em trocas de mensagem
vem despertando interesse também nas universidades, que estão desenvolvendo vários estudos
e protótipos baseados nessa arquitetura.
A exemplo disso, alunos da universidade de Indiana (USA) desenvolveram um protótipo
utilizando a arquitetura publish/subscribe para prover videoconferência entre sistemas
heterogêneos (H.232, SIP e Access Grid) (GEOFFREY, 2002). Nesse artigo é apresentado um
framework conhecido por XGSP (XML Based General Session Protocol), que é baseado em
web services para prover o controle das videoconferências, e o middleware NaradaBrokering,
baseado na arquitetura publish/subscribe. O intuito desta pesquisa é o desenvolvimento de um
3
produto batizado como Global-MMCS (Global Multimedia Collaboration System) que irá
integrar vários serviços, incluindo videoconferência, instant messaging e streaming e dar
suporte a diferentes tecnologias de videoconferência e ambientes heterogêneos.
Em (YONEKI, 2003) foi proposto o desenvolvimento de um middleware (gateway) para
aplicações móveis, baseado no paradigma publish/subscribe. Neste projeto também é discutida
a heterogeneidade das aplicações, principalmente no que diz respeito às restrições dos
dispositivos móveis atuais, dando ênfase ao modelo de transmissões descentralizadas (redes
ad-hoc).
Neste contexto é importante se avaliar que por trás de todas as tecnologias envolvidas o
desenvolvimento de protótipos permite a avaliação de estudos de casos e verificar se o produto
que está sendo desenvolvido atende os requisitos de qualidade impostos por cada tipo de
aplicação. Uma das grandes limitações presentes na maior parte das arquiteturas que suportam
comunicação indireta consiste na falta de suporte aos parâmetros de Qualidade de Serviço
(QoS). As soluções existentes, na sua maioria, baseiam-se no estabelecimento de canais de
comunicação, tornando difícil à utilização no modelo publish/subscribe.
A partir desta necessidade, vários trabalhos estão sendo desenvolvidos e propostos
como em (CARVALHO, 2005) que apresenta uma solução para garantir a qualidade de serviço
utilizando o paradigma publish/subscribe. Com este modelo, chamado de IndiQoS, é possível
fornecer às aplicações uma forma de expressão de parâmetros de QoS e remover da aplicação a
tarefa de efetuar reserva de recursos necessários. Em (ZIEBA, 2005) um outro modelo foi
proposto para atender os parâmetros de QoS. Neste modelo o ponto chave baseia-se na
determinação das rotas utilizadas na entrega das notificações aos subscribers. Segundo o autor,
a subscrição por si só não é suficiente para a escolha das rotas e, portanto esta decisão deverá
depender de critérios adicionais. A maior contribuição deste trabalho esta justamente na
identificação desses critérios e para isso foram extraídas três camadas de abstração as quais
impõem restrições ao modelo.
Um outro modelo também foi proposto por (ARAÚJO, 2001) onde uma arquitetura em
três camadas foi utilizada. As três camadas identificadas foram: camada de aplicação, o
middleware (message broker) e a camada do sistema operacional / rede. Neste artigo são
discutidas algumas maneiras de se obter QoS nas duas camadas mais altas (aplicação e
middleware) sendo que na camada de rede são utilizados mecanismos já conhecidos de
reservas de recursos.
4
Como se pode perceber, vários trabalhos já foram propostos nesta área e cada vez mais
haverá uma preocupação ainda maior em relação ao suporte a QoS nas aplicações para
ambientes móveis.
1.4 Organização do Documento
No Capítulo 2 deste trabalho será apresentado o paradigma publish/subscribe tendo como
principal objetivo à contextualização da sua arquitetura, a identificação dos principais
componentes e principalmente da interação entre eles. Isso porque o modelo adaptado baseia-
se neste paradigma e o entendimento de todas as interações é de fundamental importância.
Logo em seguida, no Capítulo 3, é apresentada a arquitetura das redes 802.11 assim
como algumas de suas características que envolvem aspectos de segurança, mobilidade e
qualidade de serviço. Neste capítulo também são apresentados os maiores desafios enfrentados
na transmissão de fluxos contínuos nas redes sem fio, assim como algumas formas de amenizar
e adaptar os grandes complicadores dessas transmissões. Este capítulo é capaz de fornecer
informações e argumentos importantes para dar subsídios às conclusões alcançadas nas
simulações desenvolvidas no trabalho.
No Capítulo 4 é apresentado o modelo propriamente dito e as adaptações que foram
necessárias para possibilitar a transmissão de arquivos de vídeo sobre uma rede 802.11g. Além
disso, são apresentadas as ferramentas e a linguagem de programação que foram utilizadas
durante a implementação, assim como as características dos protocolos e dos servidores
utilizados em questão.
Por fim o Capítulo 5 apresenta os cenários em que foram realizadas as simulações. Em
cada um deles são descritas as variáveis utilizadas e seus respectivos valores utilizados durante
as simulações. Em seguida são apresentados, graficamente, os resultados obtidos.
Por último são apresentadas, no Capítulo 6, as conclusões finais em relação à
implementação das adaptações e da análise dos resultados obtidos durante as simulações. Neste
capítulo também são apresentadas algumas propostas de melhorias no modelo aqui apresentado
e sugestões de trabalhos futuros que podem ser realizados a partir do trabalho desenvolvido.
5
2 Paradigma Publish/Subscribe
2.1 Introdução
Com a grande explosão no uso da Internet nos últimos anos, a arquitetura cliente-servidor
ganhou espaço no mercado e atualmente pode-se dizer que a maioria das aplicações comerciais
baseia-se nesta arquitetura.
Antes dessa grande explosão da Internet o desenvolvimento das aplicações era baseado
em arquitetura centralizada, ou seja, toda a “inteligência” era concentrada em um único
computador central. Para suportar a grande quantidade de processamento eram necessárias
máquinas de grande porte (mainframes). A principal restrição dessa arquitetura era a
escalabilidade, pois se houvesse a necessidade de se aumentar a capacidade de processamento
o sistema tinha de ser todo substituído. Apesar do aumento da capacidade de processamento os
custos acabavam se tornando cada vez mais proibitivos, além da arquitetura não se apresentar
adequada para a utilização de interfaces gráficas. Por esses motivos essa arquitetura foi
considerada limitada e, portanto outros modelos foram sendo propostos na literatura. Entre
estes modelos surgiu a arquitetura cliente-servidor.
Ao contrário da arquitetura centralizada, a arquitetura cliente-servidor apresenta uma
infra-estrutura composta por dois módulos distintos. O módulo cliente que é definido como
requisitor de serviços e o servidor que é definido como provedor de serviços. Dependendo de
como for definida a configuração do software, uma máquina pode ser ambos: cliente e
servidor.
Para ser possível a comunicação entre os processos clientes e servidores, vários métodos
podem ser utilizados, entre eles estão: passagem de mensagens, invocação remota, espaços
compartilhados e filas de mensagens apresentados em (EUGSTER, 2001). Todos estes
métodos são considerados paradigmas no desenvolvimento de aplicações distribuídas que
antecedem o paradigma publish/subscribe.
O grande diferencial do modelo de comunicação publish/subscribe é que ele é baseado na
troca assíncrona de mensagens, conhecida por eventos. Além do assincronismo, esse modelo
fornece forte desacoplamento entre módulos do sistema, fornecendo maior flexibilidade e
extensibilidade às aplicações.
6
2.1.1 Passagem de Mensagens
A passagem de mensagem foi um dos primeiros mecanismos disponíveis como solução
para a comunicação entre processos. Teve como base a comunicação através de sockets que é
considerada uma forma de comunicação de baixo nível, pois dependendo da sua utilização é
necessária a criação de um protocolo de comunicação de alto nível, ou seja, de nível de
aplicação.
Neste paradigma o envio das mensagens é assíncrono enquanto o consumo das mesmas é
síncrono, portanto existe uma dependência temporal entre os componentes do sistema, devendo
estar ativos durante o mesmo intervalo de tempo. Além da dependência temporal existe a
dependência espacial, pois a forma de endereçamento é baseada em portas que são associadas a
processos.
A sua utilização no desenvolvimento de aplicações distribuídas de grande porte é
considerada pequena, pois além dos fatores já descritos, existe a não transparência do
endereçamento físico, a formatação dos dados e controle de fluxo, que ficam a encargo da
camada de aplicação.
2.1.2 Invocação Remota
A invocação de métodos remotos surgiu na década de oitenta com a programação
procedural, ou seja, era possível que um programa chamasse funções residentes em outras
máquinas da rede tão convenientemente como se a função fosse parte do mesmo programa que
executa no mesmo computador. Tecnologias como (JAVA RMI, CORBA, Microsoft DCOM)
basearam-se nas chamadas, conhecidas por RPC (Remote Procedure Call), para utilizar as
chamadas de métodos remotos, porém em outro contexto, não mais utilizando programas
procedurais e sim orientados a objetos.
Todas as tecnologias citadas anteriormente possuem dependência de tempo e espaço
entre os componentes, pois estes devem estar sincronizados e o destino das mensagens deve ser
explicitamente citado. Portanto, este paradigma é totalmente o oposto do paradigma
publish/subscribe em termos de dependência e sincronização entre os participantes.
2.1.3 Espaços Compartilhados
Os espaços compartilhados de memória ou DSM (Distributed Shared Memory)
trabalham com o conceito de que vários hosts, conectados por uma rede, compartilham um
espaço de endereçamento global, ou seja, um módulo local da memória física aponta, total ou
parcialmente, para um espaço de endereçamento global. Desta maneira é possível prover a
7
independência de tempo e espaço, pois os participantes desta rede não precisam ter
conhecimento uns dos outros. Porém não existe a independência do fluxo de execução, pois o
recebimento de mensagens do sistema é realizado de forma síncrona.
2.1.4 Filas de Mensagens
Sistemas baseados em filas de mensagens possuem uma área (Fila) aonde os produtores
armazenam suas mensagens e os consumidores buscam estas mensagens. Este paradigma
oferece independência temporal e espacial entre os componentes do sistema, mas não possui
independência em relação ao fluxo de execução, visto que as mensagens são consumidas da
“Fila” de forma síncrona.
Este paradigma se assemelha ao de espaço compartilhado devido à existência de uma
área compartilhada entre os componentes do sistema, porém do ponto de vista funcional
possuem algumas diferenças. Nas filas de mensagens existe a garantia de entrega e da
ordenação das mensagens.
2.2 A Interação Publish/Subscribe
Na arquitetura de um sistema publish/subscribe existem módulos responsáveis por prover
informações, as quais serão consumidas por usuários do sistema que demonstrarem interesse
em recebê-las. Este interesse deverá ser expresso ao sistema através da submissão de um
pedido, contendo as características do evento desejado. Essa ação é conhecida como subscrição
e deverá ser realizada pelos usuários do sistema, conhecido por “subscribers”, como ilustrado
na Figura 1.
Em um modelo básico de um sistema publish/subscribe, a interação entre os
componentes do sistema conta com a participação de um Serviço de Notificação que armazena
e gerencia as subscrições dos clientes, além de enviar as notificações aos subscribers de
maneira eficiente. Este serviço atua como um mediador entre os publishers, que são os
produtores de notificações e os subscribers, que possuem o papel de consumidores de
notificações (EUGSTER, 2001).
8
Publisher
Publisher
Publisher
Serviço de Notificação
Subscriber
Subscriber
SubscriberObjetos Administrativos
Publicação
Notificações
Subscrição
Figura 1 - Interações do modelo Publish/Subscribe
Os subscribers, ao realizarem a subscrição no sistema, estarão demonstrando interesse
em um determinado evento, que pode ser classificado em quatro diferentes esquemas: baseado
em canais, baseado em tópicos, baseado em conteúdos ou nos tipos de eventos.
No esquema baseado em canal os subscribers podem se inscrever em um determinado
canal e assim passam a estar associados a ele. Portanto o Serviço de Notificação, ao receber
publicações a um determinado canal, deverá enviá-las somente aos subscribers que estiverem
associados a este canal.
No esquema baseado em tópico (ou assunto), os publishers deverão publicar os eventos
baseando-se em um tópico que indicará o conteúdo da publicação. Este tópico pode ser
representado por uma string, permitindo que o subscriber defina sua subscrição a partir dela.
Já no esquema baseado em conteúdo, foi introduzido um modelo de subscrição que
permite ao subscriber expressar seus interesses utilizando uma query no conteúdo dos eventos
e não mais em um tópico atribuído ao evento. Com isso, eventos não são mais pré-classificados
de acordo com os critérios do componente responsável pela geração dos eventos (publishers),
tornando este esquema mais flexível. Apesar da flexibilidade oferecida pelo esquema baseado
em conteúdo, este esquema adiciona uma certa complexidade na sua estrutura e implementação
(CARZANIGA et al., 1998a).
Uma outra forma de classificar os eventos gerados pelos publishers, proposta por
(EUGSTER, 2000), é classificá-los de acordo com a estrutura do evento enviado. Uma
extensão da proposta de classificação dos eventos baseada na sua estrutura, também é apresenta
por Eugster, onde os eventos são tratados como objetos, e a classificação é realizada de acordo
com o tipo do objeto. Destas propostas, surgiu a idéia de substituir a classificação de eventos
de acordo com um tópico, e passar a classificá-los de acordo com seu tipo.
Assim como os subscribers registram o seu interesse em um determinado evento a partir
de uma operação subscribe() a operação unsubscribe() encerra a mesma subscrição, fazendo
com que os subscribers não recebam mais os eventos do Servidor de Notificação.
9
Para dar início a uma notificação, basta que o provider invoque a operação publish() e
todos os subscribers que registraram interesse neste evento serão notificados.
Todos os passos descritos acima são realizados de forma assíncrona, pois o paradigma
publish/subscribe provê o assincronismo das aplicações através da independência em relação
ao espaço, tempo e fluxo de execução (EUGSTER, 2001).
2.2.1 Independência em relação ao espaço
Esta independência foi adquirida, pois os componentes do sistema não têm a necessidade
de conhecer uns aos outros. Os publishers apenas publicam seus eventos e não fazem
referência aos subscribers, assim como os subscribers, apenas realizam as subscrições e
consomem as notificações vindas do Servidor de Notificação. Tudo é realizado de forma
independente, como ilustrado na Figura 2.
Publisher Publish
Subscriber
Notify()
Subscriber
Notify()
Subscriber
Notify()
Notify
Notify
Notify
Serviço de
Notificação
Figura 2 - Modelo de Independência em relação ao espaço
2.2.2 Independência em relação ao tempo
Em um sistema publish/subscribe as interações podem ser executadas em instantes
diferentes, ou seja, as partes que compõem o sistema são totalmente independentes. A Figura 3
ilustra duas possíveis situações. Na situação de número um, o publisher pode ser capaz de
realizar uma publicação enquanto os subscribers estiverem desconectados. O contrário também
é verdadeiro, ou seja, na situação de número dois um subscriber pode receber uma notificação
enquanto o publisher, que publicou o evento, estiver fora de operação.
10
PublisherPublisherPublisherPublisher
Serviço de NotificaçãoServiço de NotificaçãoServiço de NotificaçãoServiço de Notificação
Publish SubscriberSubscriberSubscriberSubscriber
Notify()
SubscriberSubscriberSubscriberSubscriber
Notify()Notify
PublisherPublisherPublisherPublisher
Serviço de NotificaçãoServiço de NotificaçãoServiço de NotificaçãoServiço de NotificaçãoTT TT
ee eemm mm
pp ppoo oo
1)
2)
Figura 3 - Modelo de Independência em relação ao tempo
2.2.3 Independência em relação ao fluxo de execução
A independência do fluxo de execução decorre do fato de que tanto os publishers quanto
os subscribers não interrompem seus fluxos de execução principal na realização da produção e
consumo de mensagens. Como mostra a Figura 4, o fluxo de execução principal é representado
pelas flechas que partem das entidades (Publisher e Subscriber). Portanto a produção e o
consumo de mensagens, representados pelos eventos Publish e Notify respectivamente, não
interrompem o fluxo de controle principal das entidades (Publisher e Subscriber).
Publisher
Serviço de
NotificaçãoPublish
Notify
Notify()
Subscriber
Figura 4 - Modelo de Independência em relação ao fluxo de execução
2.3 Considerações Gerais
Além das características de independência descritas acima, um sistema publish/subscribe
também apresenta mais uma característica que é o esquema de comunicação multicast. Isto se
deve ao fato de que ao publicar um evento o Serviço de Notificação pode enviar o mesmo
evento a vários subscribers em uma mesma operação. Portanto, pode-se dizer que um sistema
publish/subscribe possui três características básicas: possui comunicação anônima, assíncrona
e de natureza multicast (EUGSTER, 2001).
11
2.4 Arquiteturas Publish/Subscribe
Um sistema publish/subscribe pode ser construído levando-se em consideração duas
possíveis arquiteturas (CUGOLA, 2002). A primeira é a centralizada onde um único Serviço de
Notificação é responsável por manter o registro de interesse dos consumidores e por disseminar
os eventos que são gerados. A segunda é a distribuída onde vários servidores são
interconectados, sendo que cada um será responsável por atender uma parte dos clientes.
2.4.1 Arquitetura Centralizada
Na arquitetura centralizada o Serviço de Notificação será composto por um único
servidor, o qual será responsável por armazenar todas as subscrições ativas do sistema,
verificar se as subscrições são compatíveis com o sistema, para então enviar as mensagens à
todos os subscribers que demonstraram interesse em recebê-las.
O maior problema encontrado neste tipo de implementação é em relação ao desempenho
do sistema. Visto que o número de publicações e subscrições pode variar bastante, o
atendimento dessas solicitações pelo Serviço de Notificação pode acabar se tornando um
gargalo (HUANG, 2001). Na tentativa de amenizar problemas relacionados ao desempenho do
sistema, surgiram alternativas como a utilização de quenching.
Nesta nova alternativa, proposta por Segall (SEGALL, 1997), o publisher possui um
novo módulo chamado de call, que representa o conjunto de todas as subscrições ativas no
sistema. Ao ser gerado um novo evento o publisher fica responsável por comparar se call (e) =
falso ou se call (e) = verdadeiro. Sendo falso significa que nenhum subscriber está interessado
no evento. Caso contrario pelo menos um subscriber está interessado no evento e então é
enviado ao Serviço de Notificação.
A utilização de quenching tem se mostrado particularmente eficiente na redução de
tráfego na rede e na utilização de recursos (processamento e memória) do Serviço de
Notificação, principalmente se uma grande quantidade de eventos não satisfizerem as
subscrições armazenadas no sistema (HUANG, 2001).
Entretanto a sua utilização pode ser problemática no caso do publisher estar
desconectado, pois o call poderá ser incapaz de realizar as atualizações quando uma ação de
subscribe( ) ou unsubscribe( ) for executada pelos subscribers. Mesmo o quenching podendo
apresentar melhoras no sistema, requer publishers com capacidade de processamento e de
12
armazenamento, além de poder apresentar baixo desempenho para sistemas com vários
participantes.
2.4.2 Arquitetura Distribuída
O principal objetivo da utilização da arquitetura distribuída é a melhora do desempenho
do sistema. Este objetivo é alcançado, pois cada servidor pode ser responsável por apenas um
sub conjunto de todas as subscrições que estão armazenadas no sistema ou receber somente
parte de todos os eventos publicados no Serviço de Notificação (CARZANIGA, 1998b). Além
disso, esta arquitetura é escalável, ou seja, quando houver necessidade de se melhorar o
desempenho do sistema, devido à inclusão de novos participantes, é possível a inclusão de mais
um servidor facilmente.
Apesar de ser escalável, o sistema pode apresentar alguns problemas quanto a latência na
comunicação, roteamento das mensagens, e a heterogeneidade dos componentes da infra-
estrutura. Alguns exemplos de sistemas publish/subscribe que utilizam a arquitetura distribuída
são: Siena (CARZANIGA, 2000), Rebeca (MÜHL, 2004), Hermes (PIETZUCH, 2004),
Meghdoot (GUPTA et al., 2004), Ready (GRUBER, 1999), Jedi (CUGOLA, 2001).
Na construção de arquiteturas distribuídas, dois tipos de distribuição devem ser
analisados: a distribuição física onde são tratadas as possíveis topologias que o conjunto de
servidores podem assumir, e a sua distribuição lógica, que indica como os eventos e as
subscrições são distribuídos entre os servidores.
2.4.2.1 Distribuição Física
A distribuição física do Serviço de Notificação pode ser realizada de acordo com um
conjunto de topologias, acarretando diferentes tipos de interconexões entre servidores e a
utilização de diferentes protocolos de interação. Em (CARZANIGA, 1998b) são apresentadas
diferentes topologias que demonstram as conexões entre os servidores, são elas:
Topologia Hierárquica
Na topologia hierárquica cada servidor possui um número de clientes associados, que
podem ser tanto publishers quanto subscribers, ou outros servidores, ou seja, o protocolo
utilizado na comunicação cliente-servidor é o mesmo utilizado na comunicação entre servidor-
13
servidor. Portanto um servidor não distingue um outro servidor de publishers ou subscribers. O
servidor que se encontra no nível superior da hierarquia será capaz de receber notificações e
subscrições de todos os seus clientes, mas enviará somente notificações.
O principal problema desta topologia está no fato de que poderão ocorrer sobrecargas
dos servidores de níveis mais altos da hierarquia, somado ao fato de que todo servidor será um
ponto potencial de falha. Esta condição poderá ocorrer visto que a falha de um servidor
desconecta todos os servidores que se encontram abaixo do seu nível hierárquico.
Topologia Ponto-a-Ponto Acíclica
Na topologia Ponto-a-Ponto Acíclica, os servidores se comunicam uns com os outros,
como pares, utilizando um protocolo que permite a transmissão de notificações e subscrições
de forma bi-direcional. Considerando a comunicação entre servidores como enlaces não
direcionados, a configuração das conexões entre os servidores produz um gráfico acíclico, o
que assegura que exista somente um caminho conectando dois servidores.
Como na topologia hierárquica, a topologia Ponto-a-Ponto Acíclica não apresenta
redundância no gráfico de conexão e, portanto como o gráfico de conexão é uma árvore,
qualquer falha em um servidor isola todo o grupo de sub-redes acessadas a partir deste
servidor.
Topologia Ponto-a-Ponto Genérica
Com a topologia Ponto-a-Ponto Genérica foram eliminadas as restrições de
comunicações acíclicas, permitindo a comunicação bi-direcional entre dois servidores, porém
utilizando um gráfico genérico. Isso significa que existem vários caminhos possíveis entre os
servidores. Esta topologia oferece várias vantagens em relação à anterior, pois requer menor
coordenação, maior flexibilidade na configuração das conexões entre os servidores e maior
robustez, visto que existem alternativas de contorno em caso de falhas do sistema.
Apesar de tantas vantagens em relação à topologia anterior, a topologia Ponto-a-Ponto
Genérica apresenta uma grande desvantagem, pois necessita de algoritmos especiais que devem
ser implementados para a escolha do melhor caminho entre servidores, além de ter que evitar
que um servidor receba a mesma mensagem mais de uma vez.
14
2.4.2.2 Distribuição Lógica
Na distribuição de Serviços de Notificação entre servidores, além da análise da topologia
a ser utilizada, um outro fator deve ser analisado: a distribuição lógica. Esta distribuição trata
da forma como os eventos serão entregues entre os servidores, ou seja, utilizando a distribuição
broadcast e a multicast (HUANG, 2001).
Distribuição broadcast
Na distribuição lógica broadcast, apesar de cada servidor ser responsável por uma parte
do conjunto total das subscrições do sistema, ao receber um novo evento será responsável por
enviá-lo para todos os outros servidores que compõem o sistema (daí o nome distribuição
broadcast). Embora cada servidor tenha que processar todos os eventos enviados ao Serviço de
Notificação, este esquema reduz o trabalho dos servidores do Serviço de Notificação se
comparado à arquitetura centralizada, pois cada servidor é responsável somente por uma parte
das subscrições do sistema.
Distribuição multicast
A distribuição multicast veio como uma alternativa à distribuição broadcast, pois apesar
de amenizar o problema de escalabilidade e de desempenho da arquitetura centralizada, pode
causar uma grande quantidade de tráfego na rede. Isso acontece porque todos os eventos
gerados pelos publishers são enviados a todos os servidores que compõem o Serviço de
Notificação.
Com a distribuição multicast um servidor não conhece somente as subscrições pelas
quais ele é responsável, mas sim as subscrições de todos os servidores que o seguem na
estrutura da rede. Assim quando ocorre a publicação de um evento, só serão repassados aos
próximos servidores os eventos que satisfizerem as subscrições destes servidores. No pior caso,
o servidor deve armazenar todas as subscrições ativas do sistema.
2.5 Conclusão
Neste capítulo foi descrito em detalhes os componentes envolvidos numa arquitetura
baseada no paradigma publish/subscribe e as possíveis interações realizadas entre eles. Além
disso, foram apresentadas as principais características desse modelo, o que torna possível a
15
caracterização deste paradigma. É possível assumir, portanto que este modelo possui
comunicação anônima, assíncrona e de natureza multicast.
A arquitetura do modelo também é apresentada para possibilitar a escolha de um
modelo adequado no desenvolvimento de uma aplicação. A escolha deverá depender não só do
número de participantes do sistema quanto do grau de escalabilidade desejado para o sistema.
No capítulo a seguir será detalhada a arquitetura das redes 802.11 para em seguida
serem detalhadas questões referentes à Qualidade de Serviço (QoS), principalmente no que diz
respeito às transmissões de fluxo contínuo de dados (streams), que serão o objetivo deste
trabalho.
16
3 Redes Locais Sem Fio (802.11)
3.1 Introdução
Em (AMORIN, 2002) as redes sem fio são descritas como uma coleção de terminais com
transmissores e receptores que se movimentam em uma determinada área, geralmente utilizam
transmissões com freqüências de rádio ou infravermelho e configuram uma rede utilizando ou
não uma infra-estrutura.
A partir desta definição pode-se perceber que as redes sem fio propiciam o acesso a
informações sem restrições de tempo e espaço. Por esses motivos várias tecnologias de
comunicação de dados sem fio estão sendo bastante utilizadas. Além de permitirem a
mobilidade durante o envio de dados, estas tecnologias permitem a cobertura de sinal em locais
de difícil acesso ou em locais em que a não há instalações apropriadas para uma estrutura de
rede cabeada. Esta situação ocorre com freqüência em construções mais antigas, onde um
projeto de utilização de redes de computadores nunca fora idealizado e, portanto exige a
necessidade da utilização de tecnologias ligadas as redes sem fio.
Para que fosse possível a interligação de redes sem fio através de diferentes
equipamentos e fabricantes, tornou-se necessário à padronização dessas tecnologias para a
comunicação de dados. Vários órgãos de padronização internacional da área de
telecomunicações auxiliam na criação desses padrões. O IEEE (Institute of Electrical and
Electronics Engineers) é um deles e para a efetivação da criação de padronizações foram
criados os chamados grupos de trabalhos ou Working Groups. O Grupo de Trabalho 11 é o
responsável pelo padrão 802.11 (IEEE, 2001). Estas redes utilizam faixas de freqüências
conhecidas como não licenciadas, e por este motivo, dependendo do local aonde forem
instaladas poderão ter interferências de equipamentos eletrônicos como telefones e microondas.
A especificação original do 802.11 fornece faixas de transmissão de dados de 1 ou
2Mbps. Já a extensão 802.11b fornece taxas um pouco maiores, em torno de 5,5 a 11Mbps. A
freqüência utilizadas nessas duas especificações é de 2,4GHz. As extensões 802.11a e 802.11g,
que são as mais recentes, utilizam taxas de transmissões que variam em torno de 6 a 54Mbps,
porém a diferença entre elas está na faixa de freqüência utilizada. As redes 802.11a utilizam a
freqüência em torno de 5GHz, já as redes 802.11g operam na faixa de 2.4GHz.
17
3.2 O Padrão 802.11
A família IEEE 802 reúne um conjunto de especificações focadas na camada física e de
controle de acesso ao meio, respectivamente camadas um e dois do modelo de Referência OSI
(Referencial Model – Opens System Interconnection of the International Standardization
Organization). O padrão 802.11 é mais um membro pertencente à família 802.
A arquitetura do IEEE 802.11 consiste em vários componentes que interagem para
prover uma rede local sem-fio, com suporte à mobilidade, baseada na divisão de área de
cobertura, de modo transparente para as camadas superiores. O Basic Service Set (BSS),
conjunto fundamental para o controle das transmissões, é definido como um grupo de estações
que estão sob o controle direto de uma única função coordenadora chamada ponto de acesso.
Esta função é que irá determinar quando uma estação poderá transmitir e receber os dados.
No padrão 802.11 existem dois tipos de redes sem-fio: ad-hoc ou de infra-estrutura. No
modo ad-hoc (referidas pelo IETF como MANET – Mobile Ad hoc NETworks ) um conjunto
de estações é capaz de se comunicar dentro de uma mesma BSS sem o auxílio de um ponto de
acesso centralizado. Já no modo infra-estruturado é utilizado um ponto de acesso que será
responsável pelo controle da comunicação entre os periféricos. Devido à incapacidade de uma
BSS realizar a cobertura de grandes áreas, o padrão 802.11 permite a interligação de vários
pontos de acesso através de um sistema de distribuição (Distribution System – DS)
estabelecendo um conjunto de serviços estendidos ou Extended Service Set (ESS). A Figura 5
ilustra duas BSS´s sendo interligadas através de um sistema de distribuição, estabelecendo a
criação de um serviço estendido.
Figura 5 - Serviços estendidos (ESS – Extended Service Set)
18
3.2.1 A Interação entre os componentes da rede
Antes de uma estação móvel iniciar qualquer tentativa de acesso a uma rede móvel é
necessário que ela encontre uma rede disponível. Esse processo de procura de sinais de redes
móveis é conhecido como scanning. Vários parâmetros são utilizados neste procedimento, tais
como:
• Basic Service Set Type (BSSType): Especifica o tipo de rede que está sendo
utilizada (ad-hoc, infraestruturado ou todas).
• Basic Service Set Identification (BSSID): É um identificador de 48bits, utilizado
para identificar uma BSS. Nas redes infra-estruturadas este identificador é o
endereço MAC (Medium Access Control).
• Service Set Identifier (SSID): Refere-se a uma string que representará o nome da
rede propriamente dita, podendo este identificador ser enviado via broadcast
através dos quadros Beacons.
• Scan Type : Especifica o tipo de scanning está sendo utilizado (ativo ou passivo)
• Channel List: Especifica uma lista de possíveis canais a serem percorridos, com
intuito de se encontrar informações de uma BSS.
• Probe Delay: Especifica o tempo em microsegundos em que a ação de scanning
deverá esperar antes do início da sua atividade.
• MinChannelTime e MaxChannelTime: Especifica a duração de tempo mínimo e
máximo em que a ação de scanning deverá ocorrer em um determinado canal.
Para realizar esse processo de procura por uma rede, dois modos podem ser utilizados: o
modo passivo ou o modo ativo. No modo passivo a estação não necessita realizar nenhuma
transmissão de dados. Ela vai apenas percorrer uma lista de canais e esperar o recebimento de
um anúncio de uma rede disponível. Este anúncio é realizado através dos pontos de acessos
disponíveis que enviam informações da rede através de quadros Beacon. Qualquer quadro
Beacon recebido é armazenado para posteriormente ser utilizado na extração de informações
referentes a cada BSS. A Figura 6 ilustra o processo de scanning através do modo passivo, ou
seja, todos os sinais de redes recebidos pelo dispositivo móvel são armazenados para serem
posteriormente analisados.
19
PA 1
PA 2
PA 3
PA 4
Quadros Beacon
Dispositivo Móvel
Encontrou: * PA 1 * PA 2 * PA 3
Figura 6 - Scanning através do modo passivo
No modo ativo, representado na Figura 7, uma requisição chamada de Probe Requests é
enviada em cada canal a procura de uma rede com um identificador determinado e uma
subseqüente resposta é esperada da rede. Ao invés de ficar esperando por uma resposta da rede
(Probe Response) em cada canal, como descrito no modo passivo, neste modo a procura se
torna mais otimizada, pois como o identificador é conhecido, a procura acaba sendo mais
rápida (GAST, 2002).
Probe Request
Probe Request
ACK
DIFS SIFS DIFS
Estação Móvel
Ponto de Acesso 1
Ponto de Acesso 2
SIFS
ACK
Probe Request
Figura 7 - Scanning através do modo ativo
20
Depois de realizada a procura por uma rede, um relatório é gerado a partir da lista
armazenada no recebimento dos quadros Beacon, contendo informações de cada BSS
encontrada. Além de todos os parâmetros necessários para a realização do scanning, alguns
outros parâmetros também estarão inclusos, tais como:
• Beacon Interval: Intervalo de tempo utilizado entre o envio dos quadros Beacon.
• Timing Parameter: Informações de sincronização utilizadas pelas BSS´s.
• PHY parameters, CF parameters, IBSS parameters: Informações referentes à
camada física, quadros de controle e por último informações sobre os endereços
de origem, destino e BSSID.
• BSSBasicRateSet: Lista as taxas de transmissões que devem ser suportadas por
qualquer estação que desejar se juntar a rede.
Ao se avaliar os resultados obtidos, uma estação móvel deverá eleger uma BSS para se
autenticar e se associar a ela, para então ter acesso à rede. Essa escolha pode variar, pois
depende da implementação de cada fabricante, porém na sua grande maioria os requisitos
levados em consideração são: o nível do sinal obtido e sua potência.
3.2.2 Autenticação e Associação
No item 3.2 deste trabalho foram apresentados os dois possíveis tipos de redes
encontrados no padrão 802.11, as redes ad-hoc e as infra-estruturadas. A utilização das redes
infra-estruturadas, diferentemente das redes ad-hoc, é totalmente dependente de uma estrutura
central, para possibilitar a comunicação entre diferentes entidades. Diante dessa situação, uma
estação móvel deverá passar por duas etapas que antecedem o processo de comunicação entre
diferentes dispositivos móveis: o de autenticação e o de associação a um ponto de acesso. As
combinações entre essas duas etapas resultam em três estados diferentes: não autenticado e não
associado, autenticado e não associado, autenticado e associado como ilustrado na Figura 8.
Na primeira etapa do processo, o ponto de acesso tenta identificar qualquer nova estação
móvel que esteja iniciando alguma comunicação dentro da sua área de cobertura. No padrão
802.11 as estações móveis não têm a necessidade de autenticar os pontos de acesso, pois se
parte do princípio que esses, por já fazerem parte da infra-estrutura da rede, são unidades
gerenciáveis pelo administrador da rede.
21
Estado 1
Não Autenticado e
Não Associando
Estado 2
Autenticado e
Não Associando
Estado 3
Autenticado e
Associando
Desautenticação
Desassociação
Autenticação
Associação ou
Reassociação
Figura 8 - Processo de Autenticação e Associação
Para realizar o processo de autenticação existem dois padrões que podem ser utilizados: o
Open System Authentication e o Shared-Key Authentication (TAVARES, 2002). No padrão
Open System Authentication toda a negociação entre a estação móvel e o ponto de acesso é
realizada em texto simples, ou seja, sem qualquer mecanismo de segurança associado. Já no
padrão Shared-Key existe o conceito de compartilhamento de uma chave secreta, que é
conhecida tanto pelo ponto de acesso quanto pela estação móvel. Ao iniciarem o processo, o
ponto de acesso envia um pacote contendo um desafio ao cliente, que deverá responder com o
mesmo pacote, porém contendo a chave cifrada. Logo ao receber o pacote de resposta, o ponto
de acesso decifra-o e compara com o pacote enviado. Se ambos coincidirem, então a estação
móvel é autenticada.
As estações móveis, após se autenticarem em um ponto de acesso, deverão realizar o
processo de associação ou reassociação para então ter acesso à rede, ou seja, neste ponto as
estações se encontrariam no estado de número dois. O processo de associação nada mais é do
que um procedimento de localização da estação móvel, para que os pacotes que forem
endereçados a ele sejam entregues pelo ponto de acesso correto. Portanto existe uma
associação do endereço MAC (Medium Access Control) da estação móvel a um único ponto de
acesso, que passará a encaminhar os pacotes corretamente.
Já no processo de reassociação, quando as estações se movem e saem de uma área de
cobertura para uma nova, é necessária uma comunicação entre os pontos de acesso para que
seja identificada a desassociação e conseqüente associação ao novo ponto de acesso. Toda a
22
troca de informações entre pontos de acesso é realizada através de um protocolo de
intercomunicação conhecido como IAPP (Inter Access Point Protocol).
Portanto depois de autenticadas e associadas, as estações móveis se encontrariam no
estado de número três do processo.
3.3 Segurança
Como foi descrito no item anterior, para que uma estação móvel tenha acesso à rede é
necessário que ocorra o processo de autenticação. Neste processo o padrão IEEE 802.11
estabelece três mecanismos para prover segurança, são eles: filtragem por identificador
(Service Set Identifier – SSID), filtragem por endereço (Access Control List – ACL) e
privacidade equivalente à rede cabeada (Wired Equivalent Privacy – WEP). A Figura 9 ilustra
as possíveis opções para realizar o processo.
Processo deAutenticação no 802.11
A comunicação é permitida se o SSID estiver vazio
A comunicação é permitida se o SSID for informado
A comunicação é permitida ao provar que a chave WEP está compartilhada
Sem CriptografiaBaseado na Identidade
Com CriptografiaBaseado na Resposta do Desafio
Sistema de Autenticação Aberto Sistema de Autenticação Fechado
Figura 9 - Possíveis Processos de Autenticação no 802.11
O primeiro mecanismo a ser descrito é considerado o mais simples, pois está relacionado
à identificação da uma rede sem fio sem criptografia, utilizando o sistema de autenticação
aberto. Isso significa que o mecanismo se utiliza do SSID, que é um parâmetro alfanumérico
utilizado para identificar uma rede geralmente configurado com a opção de broadcast ativa, ou
seja, este identificador é transmitido periodicamente pelo ponto de acesso, permitindo que
todos os clientes que estejam dentro da sua área de cobertura possam se conectar à rede sem
saber previamente o SSID. Portanto ao se optar por este tipo de configuração não há
23
necessidade de configurar manualmente os códigos SSID´s nas estações clientes, porém
significa abrir mão da camada de segurança.
Esta opção é bastante utilizada na criação de redes públicas, onde vários usuários
poderão acessar a rede sem a necessidade de uma prévia configuração das estações.
Em questão de segurança, apenas desabilitar a opção de broadcast ainda torna o sistema
muito vulnerável e por isso o padrão Wired Equivalent Privacy (WEP) foi criado. Como o seu
próprio nome diz, o WEP tenta criar um nível de segurança muito próximo ao das redes
cabeadas (WALKER, 2000), encarregando-se de encriptar os dados que trafegam entre o ponto
de acesso e as estações móveis através de algorítmos criptográficos baseados no RC4 no nível
da camada de enlace. A forma com que o RC4 cifra os dados é através de uma operação XOR
bit a bit entre a mensagem que está sendo enviada e uma chave, ou seja, uma mensagem
composta pelos bits p1,p2,p3,..... e uma chave k1,k2,k3,..... o texto final seria composto por :
ci = pi XOR ki para i=1,2,3,......
Este algorítmo utiliza um processo de criptografia conhecido como simétrico, pois a
mesma chave (40 bits) utilizada na cifragem dos dados também será utilizada na decifragem
dos dados. Portanto ao receber a mensagem o destinatário deverá repetir a operação XOR bit a
bit para poder recuperar a mensagem original:
pi = ci XOR ki para i=1,2,3,......
Assim, cada uma das partes que desejarem participar da comunicação deverá possuir a
chave para serem capazes de cifrar os dados e também de recuperar a mensagem original.
Como os dispositivos não possuem conhecimento prévio do tamanho das mensagens a serem
trafegadas e a chave para cifragem deve ter o mesmo tamanho da mensagem é necessária a
utilização de uma “semente” (segredo compartilhado entre as estações) em um gerador de
números pseudo-aleatórios (PRNG – Pseudo Random Number Generator). O PRNG deverá
gerar o número de bits necessários para que a mensagem seja cifrada. Como o destinatário
possui o conhecimento da “semente”, deverá gerar a mesma seqüência de bits para decifrar a
mensagem.
Uma semente nunca deve ser reutilizada, pois a rede fica exposta a um ataque. Se o
atacante enviar uma mensagem à rede e realizar uma operação de XOR entre a mensagem
original e a mensagem cifrada, consegue-se recuperar a chave utilizada. Desta maneira se a
chave for reutilizada o atacante consegue decifrar a mensagem, mesmo não tendo acesso ao
segredo compartilhado.
24
Para tentar garantir que uma semente não seja reutilizada, o WEP possui um vetor de
inicialização ou Initialization Vector (IV) de 24 bits, gerado aleatoriamente, que é combinado
ao segredo compartilhado (40 bits) formando uma nova semente. Assim, para que o
destinatário possa recuperar a semente, o vetor de inicialização deverá ser enviado sem
criptografia (BORISOV, 2001):
ci = pi XOR RC4 (IV, k)
Além deste processo o protocolo WEP utiliza um algorítmo conhecido como Cyclic
Redundancy Check (CRC), para verificar se a mensagem sofreu alterações durante o processo
de transmissão dos dados. Essa verificação é conhecida por Integrity Check Value (ICV).
Apesar de proporcionar um nível de segurança um pouco maior se comparado ao SSID, o
WEP apresenta algumas falhas já conhecidas. Para aumentar o nível de segurança das redes
sem fio e combater algumas vulnerabilidades do WEP o IEEE iniciou um trabalho para propor
um novo padrão chamado 802.11i, também conhecido como Robust Security Network (RSN).
A partir disso surgiu um esforço em conjunto dos membros da Wi-Fi Alliance, que
considerando algumas das vantagens anunciadas pelo 802.11i, criou o Wi-Fi Protected Access
(WPA) ou também chamado de WEP2. Ao publicar o WPA a Wi-Fi Alliance conseguiu
obrigar a conformidade de todos os equipamentos com o logotipo Wi-Fi ao WPA, oferecendo
uma opção de segurança de alto padrão antes mesmo da publicação do padrão 802.11i.
Alguma das vantagens do WPA é a melhora da criptografia dos dados ao utilizar um
protocolo conhecido por TKIP (Temporal Key Integrity Protocol) que possibilita a criação de
chaves por pacotes, um vetor de inicialização de 48 bits e não mais de 24 bits, um processo de
autenticação que utiliza o protocolo 802.1x e o EAP (Extensible Authentication Protocol) que
através de um servidor de autenticação central faz a autenticação de cada usuário antes de ter
acesso à rede.
O IEEE 802.1x ou (Port Based Network Access Control) é um padrão que oferece uma
forma de autenticar e associar dispositivos de rede, ao nível 2 da pilha OSI, conectados a uma
porta seja ela uma conexão Ethernet física ou uma conexão sem fio com um ponto de acesso.
Este padrão utiliza o protocolo Extensible Authentication Protocol (EAP) para transportar as
credenciais do usuário entre o seu dispositivo WLAN (Wireless LAN) e um servidor de
autenticação (RADIUS). Se a autenticação for bem sucedida, então o usuário estará habilitado
a acessar toda a infra-estrutura da rede.
Para a utilização do padrão 802.1x é necessário definir as entidades envolvidas, sendo
elas: o cliente, entidade que está solicitando a autenticação; o autenticador, entidade que faz a
intermediação da autenticação; o servidor de autenticação, entidade que provê o serviço de
25
autenticação ao autenticador (SILVA, 2003). O servidor de autenticação pode estar combinado
ao autenticador ou pode ser acessado remotamente como representado na Figura 10, aonde o
cliente é representado por um dispositivo sem fio, o autenticador pelo ponto de acesso e o
servidor de autenticação pode ser representado por um RADIUS localizado na rede cabeada.
AutenticadorCliente
Servidor de Autenticação
Figura 10 - Entidades envolvidas (802.1x)
O RADIUS é um protocolo, criado para uso em serviço de acesso discado, amplamente
empregado para disponibilizar acesso às redes com Autenticação, Autorização e
Contabilização. Porém, devido a sua eficiência e simplicidade é utilizado em diversos tipos de
redes. O RADIUS centraliza as três atividades descritas e pode ser utilizado no caso das redes
sem fio. Neste caso um ponto de acesso pode se tornar um cliente RADIUS que enviará as
credenciais e parâmetros da conexão ao servidor. Este servidor ao receber a mensagem
RADIUS deverá autenticar e autorizar ou não a requisição do cliente RADIUS.
Apesar de ter sido bastante utilizado este padrão possui algumas falhas já comprovadas
por (ARBAUGH, 2002) e por isso vários estudos nesta área estão sendo amplamente discutidos
(CARRIÓN, 2003).
Uma outra prática herdada das redes cabeadas e dos administradores de rede foi o ACL -
Access Control List, ou seja, é um controle que consiste em uma lista contendo todos os
endereços físicos (MAC) dos adaptadores de rede que se deseja permitir o acesso à rede sem
fio. A cada nova estação que tente ter acesso a rede terá seu endereço MAC comparado com os
endereços previamente cadastrados na lista. Caso seu endereço exista na lista o acesso é então
liberado.
3.4 Mobilidade
Para poder se entender as restrições estruturais de uma rede 802.11 é necessário o
completo entendimento das diferenças entre os conceitos de mobilidade e portabilidade.
Segundo encontrado na literatura (GAST, 2002) e nas especificações do 802.11, uma estação
26
portátil é aquela que pode ser desconectada da sua rede de origem e ao ser transportada a uma
nova localidade poderá ser reconectada. Isso devido ao peso reduzido e também pelas pequenas
dimensões dos dispositivos atualmente utilizados. A estação portátil usa a rede somente quando
está parada em suas possíveis localizações e nunca em movimento. Portanto nestes casos os
dispositivos portáteis podem utilizar qualquer meio de comunicação, seja empregando
interfaces de rede sem fio ou com ligações diretas aos cabos de rede fixa.
Já uma estação móvel, além de ser portátil, deve possuir a capacidade de estabelecer uma
comunicação e não interrompê-la durante a sua movimentação. Neste caso é necessária a
utilização de redes sem fio e um mecanismo para prover as transferências de conexões entre as
estações, ao mudarem de área de cobertura.
Nas redes 802.11, para que as estações consigam manter suas conexões durante a troca
de área de cobertura é necessário que elas mantenham seus endereços IP. Isso acontece, pois a
cada novo endereço IP adquirido, uma nova conexão é iniciada, impossibilitando a
comunicação contínua entre as estações móveis. Portanto o backbone dos pontos de acesso
deverá possuir um único endereço de sub-rede possibilitando assim a comunicação contínua.
No caso de universidades ou locais amplos o backbone dos pontos de acesso deverá ser
desmembrado em pequenas redes para se obter um melhor alcance dos sinais. Como descrito
anteriormente, a arquitetura 802.11 permite a extensão dos limites de uma rede móvel através
do aumento da área de alcance ou (Extended Service Set –ESS). Na Figura 11 ilustramos as
opções de configurações das redes 802.11 utilizando esta definição.
Na primeira opção todas as sub-redes estarão configuradas com o mesmo SSID, portanto
os usuários poderão realizar o roaming entre as “ilhas” estabelecidas sem a necessidade de se
substituir o SSID configurado no dispositivo móvel. Neste caso o único problema está
relacionado ao aspecto de segurança, pois muitas vezes, devido ao alcance dos sinais, as redes
não estejam alocadas em determinadas localidades, impedindo o acesso na direção desejada.
Já no segundo caso, cada “ilha” recebeu um identificado único e, portanto foi
estabelecido um nível de segurança um pouco maior, tornando o acesso à rede muito mais
ampla. Entretanto ao mudar de área de cobertura o usuário deverá re-configurar o SSID para ter
acesso à nova rede.
27
Figura 11 - Roaming restrito
Nas duas soluções temos vantagens e desvantagens, porém em ambos os casos o usuário
ao se deslocar e se conectar a uma nova rede, todas as suas conexões serão interrompidas, pois
estará recebendo um novo endereço IP. Portanto para que seja possível a completa mobilidade
dos dispositivos, sem haver a interrupção das conexões já abertas, é necessário se manter o
mesmo endereço IP ao realizar o hand-off. Para atender esta demanda a IETF (Internet
Engineering Task Force) criou um grupo de trabalho que propôs o IPv4 Móvel ou IP Móvel
baseado no IPv6, publicado na RFC2002 (PERKINS, 1996), atualizado na RFC3220
(PERKINS, 2002a) e atualmente disponível na RFC3344 (PERKINS, 2002b). O IP Móvel
surgiu, portanto a partir do protocolo IP, pois para que uma estação consiga receber os
datagramas destinados a ela é preciso saber, antes de qualquer coisa, a sua localização na rede.
Esta localização é realizada através do número IP, porém para que uma estação possa se
deslocar, mudando seu ponto de acesso a rede, sem perder as conexões existentes foi necessária
a inclusão de algumas novas estruturas de controle.
3.5 Qualidade de Serviço em Redes 802.11
3.5.1 Requisitos
As redes de computadores foram desenvolvidas para possibilitar a conexão de
computadores, localizados em lugares distintos, com o objetivo de realizar trocas de dados. Por
muito tempo a maioria dos dados que trafegavam na rede era no formato texto. Atualmente
existe uma grande tendência que aplicações de voz, vídeo, dados, imagens, músicas convirjam
para um único meio físico, sendo possível transportá-los através do mesmo meio. Porém o
tráfego gerado por essas mídias impõe exigências sobre a rede para que possam ter um bom
desempenho.
28
Algumas aplicações como as de tempo real exigem confiabilidade absoluta, já as
aplicações multimídia são menos rígidas em relação à confiabilidade, pois toleram perdas
ocasionais de pacotes, porém requerem limites rígidos em relação à uniformidade na entrega de
pacotes. Idealmente, um fluxo multimídia deve ser recepcionado de forma suave e contínua.
Neste contexto surge o estudo sobre (QoS - Quality of Service), que vem basicamente
proporcionar garantias nas transmissões de dados, podendo ser aplicadas a diversas redes para
atender determinados requisitos exigidos pelos usuários ou aplicações, utilizando parâmetros
dentro de valores bem definidos.
O conceito de Qualidade de Serviço foi introduzido pela ISO para mensurar a qualidade
dos serviços oferecidos por uma rede de comunicação, ou seja, refletir o quanto ela é capaz de
atender às expectativas de seus usuários através dos serviços que oferece (ISO, 1994). Seu
principal desafio é atender os diferentes requisitos em termos de disponibilidade de rede,
variação do atraso, latência e taxas de confiabilidade para diferentes aplicações.
Apesar de muitos acreditarem que apenas aumentando a largura de banda na transmissão
de dados fará com que a implementação de QoS se torne uma tarefa dispensável, a realidade
nos mostra que quanto mais banda passante houver mais aplicações serão introduzidas no
mercado para consumi-las.
Portanto existe uma grande necessidade de prover qualidade de serviço para diferentes
aplicações, pois caso contrário poderá gerar um grande impacto no congestionamento das
redes. Desta maneira faz-se necessário uma negociação entre as aplicações e a rede dos
parâmetros que QoS os quais serão descritos na seção a seguir.
3.5.1.1 Latência
A latência é o tempo em que um pacote leva desde a sua origem até seu destino
(BARCELLOS, 2000). No caso de aplicações multimídia, caso este tempo seja muito longo irá
prejudicar a qualidade de reprodução das aplicações unidirecionais ou tornará impraticável a
interatividade no caso de outras aplicações. Um atraso considerado praticável para o ser
humano fica na ordem de 100ms (PASSMORE, 1997).
Para se calcular o atraso fim a fim de um pacote é necessário que os relógios das
máquinas estejam sincronizados, pois o tempo de envio de um pacote será armazenado em uma
máquina diferente da máquina que armazenará o tempo de recepção do pacote.
29
3.5.1.2 Jitter de atraso
O jitter de atraso é o tempo de interchegada de pacotes. Ao contrário do atraso, o jitter
não necessita da sincronização de fase dos relógios (se possuírem a mesma hora) quando
calculado para pacotes consecutivos. Apesar de depender apenas da sincronização da
freqüência dos relógios, para um relógio não se adiantar em relação ao outro com o passar do
tempo, esse valor é tão pequeno que pode ser desconsiderado.
Para exemplificar porque a sincronização é desnecessária considerou-se a seguinte
situação descrita em (BARBOSA, 2005): sejam TiA e T
kA o instante de saídas de dois pacotes
consecutivos i e k marcados no relógio de A e sejam T iB e T
kB os instantes de chegada dos
mesmos pacotes na máquina B. Considerando-se que os relógios estão afastados por εεεε unidades
de tempo, tem-se que o jitter é calculado pela diferença entre os atrasos:
dvik
= dk - d
i
Cada atraso é calculado pela diferença entre o momento de chegada na máquina B e a
saída na máquina somada ao erro dado a diferença entre fases do relógio.
dvik
=( TkB - T
kA + ε ε ε εk
) – ( T iB - T
iA + ε ε ε εi )
εεεεk ≅ εεεεi
Tem-se, portanto que:
dvik
=( TkB - T
kA
) – ( T
iB - T
iA )
3.5.1.3 Largura de banda
É a taxa de transmissão de dados máxima que pode ser sustentada entre dois pontos. O
termo vazão é utilizado para designar a taxa máxima que alguma aplicação ou protocolo
consegue manter em uma rede;
3.5.1.4 Confiabilidade
Está relacionada principalmente ao descarte de pacotes em roteadores devido a
congestionamentos.
30
3.5.2 Categorização das Aplicações
Para possibilitar o provisionamento de Qos em diferentes aplicações foi necessário
categorizá-las baseando-se nas necessidades de cada uma delas. A partir disso as aplicações
foram divididas em quatro diferentes classes (ETSI, 2004):
3.5.2.1 Classe Conversational
Uma aplicação Conversational está relacionada a aplicações em tempo real. Dentro deste
contexto, “tempo real” se refere a um atraso mínimo, uma pequena variação de atraso (jitter) e
mínimas perdas de pacotes. Para exemplificar este modelo podemos nos referir a uma
videoconferência, onde a perda de pacotes seria indesejável visto que seria impossível manter a
comunicação e tão pouco retransmitir os pacotes perdidos. Dentro desta classe encontram
aplicações como: Telnet, Jogos Interativos, Voz e Videofone.
3.5.2.2 Classe Streaming
Na classe Streaming as aplicações não necessitam de restrições tão rígidas em relação ao
atraso, se comparado à classe Conversational. Como não se trata de aplicações de tempo real, o
que mais importa é a variação no atraso, visto que um fluxo de vídeo deve ser suave e
constante. Aplicações de FTP, áudio e vídeo streaming se enquadram nesta classe.
3.5.2.3 Classe Interactive
A classe Interactive atende os requisitos de aplicações em que o primordial é a
consistência dos dados. Dentro desta classe estão serviços de comércio eletrônico, web
browsing, e mensagens de voz. Portanto serviços como comércio eletrônico e web browsing
não permitem perdas de pacotes, pois qualquer perda de pacote acarretaria em possíveis perdas
de dados pessoais.
3.5.2.4 Classe Background
Outras aplicações, apesar de não necessitarem de respostas imediatas (tráfegos de melhor
esforço), requerem que o conteúdo da informação seja preservado. Como exemplo dessas
31
aplicações temos os serviços de e-mail e SMS (Short Message Service), onde a prioridade de
entrega destes serviços está baseada simplesmente no modelo do negócio.
3.5.3 Transmissão de Fluxos Contínuos em Redes sem Fio
Com o crescimento da Internet nos últimos anos várias tecnologias deixaram de ser
emergentes para se tornarem padrões de fato. Este é o caso, por exemplo, das redes sem fio
802.11. Estas redes possibilitam mobilidade, o que agrega muito valor às novas aplicações.
Portanto cada vez mais novas aplicações estão sendo desenvolvidas, principalmente aquelas
que envolvem multimídia.
Porém a maioria dos protocolos atuais, utilizados para transmissão de arquivos
multimídia, foi desenvolvida para as redes cabeadas, o que implica numa inadequação destes
protocolos para as redes sem fio. No trabalho apresentado por (CONCEIÇÃO, 2003), vários
fatores tornam os protocolos atuais inadequados para a utilização em redes sem fio, entre eles
estão: maior taxa de erros, mobilidade, compartilhamento de canal, comportamento das
interfaces, variabilidade, requisitos de tempo real.
3.5.3.1 Maior taxa de erros
Uma das principais razões da inadequação dos protocolos atuais está relacionada à taxa
de erros (BER - Bit Error Rate). Nas redes sem fio esta taxa é muito maior (10-3 a 10-5) se
comparada às taxas das redes cabeadas (10-6 a 10-8) (SANTANA, 2004). A exemplo disso tem-
se o mecanismo de controle de congestionamento do protocolo TCP, que reduz a vazão da
transmissão ao perceber perdas de dados. Nas redes sem fio a maioria das perdas advém da
mobilidade e não de congestionamentos.
3.5.3.2 Mobilidade
Durante a transmissão de dados, as condições de transmissão podem variar muito devido
à mobilidade. Locais em que os sinais para transmissão dos dados das redes não têm muita
intensidade (áreas de sombra), acabam por diminuir a capacidade de transmissão de dados.
Além disso, podem acontecer situações de hand-off o que acarreta em breves interrupções na
comunicação.
32
3.5.3.3 Compartilhamento de Canal
Como apresentado na seção 3.1 as comunicações realizadas através das redes 802.11
pelas estações móveis são realizadas através de canais compartilhados. Portanto se uma das
estações fizer um mau uso da rede, todos os usuários desta rede poderão ter a qualidade de suas
transmissões afetadas.
3.5.3.4 Comportamento das interfaces
Diante de diferentes fabricantes, o comportamento das interfaces de comunicação para
redes 802.11 pode variar bastante.
3.5.3.5 Variabilidade
Como as redes 802.11 são mais instáveis do que as redes cabeadas, estas acabam sendo
mais suscetíveis a interferências e perdas de sinal contribuindo para um comportamento
aleatório de colisão de pacotes. Execuções distintas utilizando as redes 802.11 podem
apresentar grandes variações no comportamento.
Apesar de muitos desses fatores apresentados não serem exclusivos às redes sem fio,
pode-se se dizer que pelas características das redes 802.11, acabam sendo potencializados.
3.5.3.6 Requisitos de Tempo Real
Em transmissões de arquivos multimídia, principalmente de vídeos, existem exigências
mínimas da própria aplicação e, portanto os quadros devem ter um tempo limite para serem
exibidos. Se o quadro ultrapassa esse tempo limite ele deve ser descartado. O resultado disso é
a baixa qualidade de exibição. Apesar das aplicações de vídeo serem tolerantes a perdas
moderadas de pacotes, o ideal em uma transmissão é que ela seja suave e contínua, livre de
falhas e estável.
3.5.4 A utilização do protocolo UDP
Com a evolução de aplicações para a distribuição de vídeo, foi adotada a utilização do
protocolo UDP (User Datagram Protocol) para transmissão de quadros de vídeo. O UDP
33
fornece um serviço de transmissão sem conexão, não confiável, usando o IP para transportar
mensagens entre máquinas (COMER, 1998).
A escolha do UDP deveu-se principalmente a dois fatores. O primeiro pelo protocolo
UDP ser mais leve, ou seja, não usa confirmação para certificar-se que as mensagens
chegaram, não ordena as mensagens de entrada e não fornece informações para controlar a
velocidade com que os dados fluem entre as máquinas. Diante disso, permite alcançar taxas de
transmissões maiores, o que se torna fundamental em transmissões de vídeos. O segundo se
deve ao fato de que em transmissões de fluxos contínuos de dados são permitidas pequenas
taxas de perdas de pacotes, sem comprometer a exibição.
Apesar do protocolo UDP atender as necessidades das aplicações multimídias de maneira
geral, existem alguns problemas para as transmissões de pacotes UDP sobre as redes 802.11.
São eles:
3.5.4.1 Baixo Isolamento
Os pacotes de dados do protocolo UDP, conhecidos por datagramas, serão divididos em
unidades de dados menores chamadas de quadros, na camada abaixo (Enlace). A princípio, esta
quebra dos dados em porções menores ocorre, pois no caso de perda dos mesmos não existirá a
necessidade de transmitir o pacote como um todo, mas sim uma parte dele (um quadro). Porém,
antes da camada de enlace notificar a camada superior da perda de um quadro, esta realiza o
reenvio do quadro, de quatro a sete vezes, dependendo do seu tamanho. Este mecanismo de
reenvio tem impacto em todo o sistema, podendo levar a um congestionamento severo da rede,
pois a interface de comunicação entre os usuários do sistema é compartilhada. Portanto se há
desperdício de banda para um, isso trará impacto a todos os usuários da rede devido ao baixo
isolamento dos mesmos.
3.5.4.2 Tamanho dos pacotes
Um dos fatores de maior influência na qualidade da transmissão de arquivos de vídeo é o
tamanho dos pacotes transmitidos. Quanto maiores os pacotes, maior será a quantidade de
quadros transmitidos ou maior será o quadro a ser transmitido pela camada de enlace. Isso
possibilita uma maior probabilidade de perda de pacotes. Portanto quanto menores os pacotes
transmitidos pela rede, menores serão as taxas de erros. Porém, pacotes excessivamente
pequenos reduzem a relação de carga útil (dados) e cabeçalho e, portanto reduzem a eficiência
34
da transmissão. O empacotamento dos dados vai depender, portanto do vídeo em questão,
possibilitando diferentes otimizações no seu empacotamento.
3.5.5 Políticas de adaptação
3.5.5.1 Bufferização
Na tentativa de suavizar os efeitos dos atrasos e possíveis falhas nas comunicações,
técnicas de bufferização são amplamente utilizadas. Para gerenciar os buffers é necessário
apenas alterar o seu tamanho e controlar sua utilização média. Apesar de parecer o contrário,
buffers excessivamente grandes, muitas vezes prejudicam o desempenho da aplicação, pois
comprometem a interatividade e necessitam de grandes espaços de armazenamento.
3.5.5.2 Retransmissão
A técnica de retransmissão de dados é bastante simples, pois ao ser verificada uma
situação de perda de pacote, é realizada uma requisição para poder retransmiti-lo. Porém o
tempo para se realizar esta tarefa é crucial, pois se este for muito longo é possível que este
pacote não seja mais útil.
Outras técnicas para reduzir o impacto das perdas de pacotes na rede podem ser
utilizadas, como por exemplo a ARC (Automatic Repeat Request) onde a informação
redundante é enviada automaticamente ou a FEC (Forward Error Correction) onde são
adicionadas umas seqüências de bits ao pacote original, para que um pacote perdido possa ser
reconstituído a partir dos pacotes já recebidos.
3.5.5.3 Adaptação do Conteúdo
Além das técnicas descritas anteriormente é possível realizar a adaptação do conteúdo a
partir das taxas de transmissões disponíveis e a capacidade de exibição do dispositivo em
questão. Para isso estão disponíveis vários padrões de codificação e algoritmos de compactação
de vídeo. Em muitos desses padrões como, por exemplo, no padrão MPEG (Motion Picture
Experts Group) é possível realizar a priorização dos pacotes, descartando os pacotes menos
importantes para a exibição do vídeo.
35
3.6 Conclusão
Neste capítulo foi apresentado o padrão 802.11, através do detalhamento de sua
arquitetura e iterações realizadas durante os processos de autenticação e associação dos
componentes móveis a um ponto de acesso. Em seguida foram descritos os padrões de
segurança atualmente existentes, baseados em três mecanismos: filtragem por identificador,
filtragem por endereço e privacidade equivalente à rede cabeada. Além disso, um breve
histórico da evolução desses mecanismos também foi descrito.
Outro aspecto bastante importante das redes sem fio e que não poderia deixar de ser
relatado neste capítulo é a questão da mobilidade. Neste item são descritos os conceitos de
roaming e hand-off que são muito importantes na configuração e alocação das redes sem fio.
Como o objetivo deste trabalho é realizar a adaptação de um modelo publish/subscribe
para a transmissão de fluxos contínuos em redes 802.11, sentiu-se a necessidade de introduzir
conceitos relacionados à qualidade de serviço e os requisitos exigidos para atender os
diferentes usuários ou aplicações. Para isso são descritos os parâmetros utilizados para atender
esta necessidade, como jitter, latência, largura de banda e confiabilidade, além de ser
apresentada a classificação das aplicações em diferentes classes para atender diferentes
requisitos.
Em seguida são apresentados alguns complicadores que envolvem a transmissão de
fluxos contínuos em redes sem fio, assim como algumas políticas de adaptação que podem ser
realizadas na tentativa de minimizar os efeitos destes complicadores na rede.
Portanto, no próximo capítulo serão apresentadas as adaptações que serão necessárias
para que o modelo proposto neste trabalho possa atender os requisitos mínimos de qualidade de
serviço, levando-se em consideração os aspectos apresentados neste capítulo.
36
4 Modelo Publish/Subscribe para redes sem fio
4.1 Introdução
A partir da crescente utilização das redes WANS e dos estudos que estão sendo
desenvolvidos nesta área podemos perceber um rico mercado para a criação de novas
aplicações utilizando as redes sem fio. Neste capítulo iremos apresentar algumas adaptações
realizadas em um modelo proposto por (DEQUECH, 2003) no qual foi apresentada a adaptação
de um sistema publish/subscribe para redes sem fio. Estas adaptações se referem basicamente a
alguns fatores relacionados ao tipo de dado transmitido, pois no modelo proposto
anteriormente toda a arquitetura fora baseada no envio de texto puro. Porém este trabalho
propõe-se a tratar de arquivos multimídia, especificamente sobre redes IEEE 802.11
(IEEE, 2001).
Nesta abordagem iremos dar ênfase nas implicações em se adaptar um modelo sobre
redes sem fio (802.11), considerando aspectos de qualidade de serviço em torno da transmissão
de fluxos contínuos de dados.
4.2 A Arquitetura
Para desenvolvermos o modelo proposto, o cenário de funcionamento será composto de
uma infra-estrutura de rede fixa a ser conectada a várias redes locais sem fio do tipo IEEE
802.11. Embora a comunicação entre as redes sem fios possa ser realizada através de uma
estrutura de comunicação própria, no cenário proposto ilustrado na Figura 12, é assumido que a
comunicação entre diferentes redes sem fio utiliza a rede fixa. Portanto para que esta
interligação entre redes fixas e móveis seja possível é necessária à utilização de dispositivos
específicos denominados gateway LAN/wireless.
Nas redes locais sem fio baseadas no protocolo IEEE 802.11 este gateway é representado
por um ponto de acesso sem fio (Wireless Network Access Point). Desta forma, a comunicação
de uma LAN não conectada a uma rede sem fio deverá ser roteada para a LAN que contenha o
gateway LAN/wireless da rede sem fio de destino.
37
P.A.
INTERNET
P.A.
GATEWAYWIRELESS
REDE LOCAL
ROTEADOES
Figura 12 - Cenário de integração (rede fixa / redes móveis)
Em (DEQUECH, 2003) foi apresentada uma proposta de modelo publish/subscribe para
ambientes móveis. Neste modelo a estrutura publish/subscribe foi dividida em três camadas
distintas: infra-estrutura de rede, infra-estrutura pulish/subscribe e aplicação, ilustrada na
Figura 13. Na infra-estrutura de rede estão as infra-estruturas de rede fixa e móvel
interconectadas através do ponto de acesso. O suporte ao sistema publish/subscribe é dado
através da segunda camada que é composta por dois módulos denominados MSS (Mobile
Support Station) e pelo Coordenador. Ambos estão localizados na infra-estrutura de rede fixa e
são os responsáveis em atender respectivamente as aplicações Subscribers e o Publishers.
Rede
wireless
Rede
fixa
subscriber
gateway
wireless
Aplicação
Infra-estrutura de
publish/subscribe
Infra-estrutura
de rede
publisher
MSS Coordenador
Figura 13 - Arquitetura Publish/Subscribe
38
Os módulos MSS e Coordenador estabelecem dois módulos distintos, um que vai atender
toda a estrutura de rede móvel e outro que vai atender a rede fixa. Portanto todos os pedidos de
subscrições que forem realizados serão atendidos pelo módulo MSS, assim como toda
mensagem associada a essas subscrições. Já o Coordenador vai atender a rede fixa, recebendo
as mensagens associadas aos publishers e através de um protocolo de comunicação de grupo
vai propagar cada um destes eventos recebidos a todos os coordenadores do sistema. Caso
exista algum subscriber interessado nestes eventos, o Coordenador os encaminha para o MSS
associado ao subscriber. Se não houver interessados as mensagens são apenas descartadas.
Para realizar a adaptação do modelo publish/subscribe proposto em (DEQUECH, 2003),
utilizando uma rede sem fio 802.11 estruturada, será necessária a particularização de algumas
funcionalidades do módulo MSS envolvendo as interfaces com os dispositivos da rede.
4.2.1 Estrutura dos Coordenadores
As funcionalidades oferecidas pelo Coordenador são obtidas através de um conjunto de
módulos que o compõem, onde cada módulo possui responsabilidades específicas. Os
principais módulos que compõe o Coordenador, cuja estrutura é ilustrada na Figura 14 são:
• O core_pub/sub: este módulo possui duas funcionalidades principais. O
gerenciamento das subscrições recebidas dos subscribers e a comparação destas
subscrições com os eventos publicados pelos publishers. Este gerenciamento está
relacionado ao cadastro e ao cancelamento de subscrições no sistema;
• A interface_MSS: é através desta interface que o Coordenador se comunica com os
MSSs cadastrados. Esta comunicação inclui o recebimento de subscrições e
mensagens de confirmação, além do envio de eventos;
• A interface_Publisher: esta interface é responsável pela integração dos
Coordenadores com os publishers que interagem com o sistema. Os eventos
recebidos por esta interface são posteriormente enviados a interface_Group;
• A interface_Group: a comunicação de grupo entre os Coordenadores que compõem
o sistema é toda de responsabilidade deste módulo. A interface_Group cadastra o
Coordenador utilizando o protocolo de membership e recebe e envia eventos de/para
os outros Coordenadores do sistema.
39
core_pub/sub interface_Publisherinterface_MSS
interface_Group
Figura 14 - Estrutura do Coordenador
4.2.2 Estrutura dos MSS
De maneira semelhante ao Coordenador, o MSS possui uma estrutura composta por
módulos que auxiliam na execução de suas responsabilidades. A estrutura do MSS é composta
por 3 módulos:
• O core_MSS: este módulo é responsável pelo gerenciamento das informações
dos subscribers que estão na área de cobertura da rede sem fio na qual o MSS
está conectado. Todas estas informações são provenientes do módulo
interface_Wireless.
• A interface_Wireless: é através desta interface que toda a integração do sistema
com a rede sem fio ocorre. Esta interface recebe informações sobre os
subscribers que fazem parte de sua área de cobertura, realiza as subscrições e
envia eventos aos subscribers.
• A interface_Coord: este módulo é responsável pela integração do MSS com o
Coordenador. Assim, a interface_Coord envia subscrições ao Coordenador e
recebe eventos a serem entregues aos subscribers.
A estrutura do MSS é ilustrada na Figura 15.
core_MSS interface_Coordinterface_Wireless
Figura 15 - Estrutura do MSS
40
4.2.3 Infra-estrutura de Comunicação
A comunicação na arquitetura do modelo publish/subscribe móvel é dividida em:
• Comunicação ponto-a-ponto: envolve a comunicação dos subscribers com os
MSSs e a comunicação dos MSSs e dos publishers com os Coordenadores.
• Comunicação de Grupo: utilizada na difusão das mensagens enviadas pelos
publishers a todos os Coordenadores do sistema.
A tecnologia associada à comunicação ponto-a-ponto dos subscribers com o MSS
depende da infra-estrutura da rede de comunicação sem fio e da sua integração com a rede fixa.
Por outro lado, a comunicação ponto-a-ponto do MSS com o Coordenador e do publisher com
o Coordenador pode ser suportada através de um mecanismo de comunicação simples, como o
sockets (SOCKETS, 2003) ou um mais elaborado como o RMI Java (WOLLRATH, 2003).
Para efeito de generalidade do modelo, nós assumimos que a comunicação entre os publishers
e os Coordenadores e a comunicação entre os Coordenadores é confiável. Já o envio de dados
entre os Coordenadores e os MSSs e os MSSs e os subscribers é não confiável. Mas toda a
comunicação entre estes componentes é confiável, pois existe a garantia de entrega. Garantia
esta suportada através do envio de mensagens de reconhecimento.
Os subscribers são componentes móveis que podem estar, potencialmente, em qualquer
uma das redes sem fio. Sendo assim, a ocorrência de uma publicação deve ser propagada a
todos os Coordenadores do sistema. Com esse propósito, os Coordenadores utilizam
mecanismos de comunicação de grupo no sentido de difundir os eventos publicados a todas as
redes locais que possuem um módulo Coordenador. Associado ao mecanismo de comunicação
de grupo, serão utilizados os serviços de membership (LIAO, 1998) que oferecem facilidades
para a inserção de novos Coordenadores ao sistema e a remoção de Coordenadores
pertencentes ao grupo.
4.2.4 Infra-estrutura de Comunicação publish/subscribe
Para que o sistema publish/subscribe comece a operar é necessário configurar a infra-
estrutura de suporte de comunicação. Esta infra-estrutura é composta pelos MSSs e
Coordenadores.
A configuração da infra-estrutura é iniciada pela execução do Coordenador que, a partir
do protocolo de membership passa a fazer parte do grupo de Coordenadores que compõem o
sistema. Uma vez ativo, o Coordenador aguarda pelo:
41
• registro dos módulos MSS;
• requisição de conexão de componentes publisher;
O registro do MSS no Coordenador é realizado durante a inicialização do MSS. Na sua
inicialização, o MSS recebe a informação do identificador do Coordenador associado à rede
fixa. Após a identificação do Coordenador, o MSS envia ao Coordenador seu identificador
através da função cad_MSS(id_MSS). O Coordenador então armazena o identificador do MSS
recebido em sua base de dados (save_MSS(id_MSS)), como mostra a Figura 16. Como
confirmação de recepção da solicitação de cadastro do MSS, o Coordenador envia ao MSS
uma mensagem denominada ack_Coord( ).
MSS Coordenador
DB-Coord
start()
GROUP
PROTOCOLjoin_Group(id_Coord)
start(id_Coord)
cad_MSS(id_MSS)
ack_Coord()
save_MSS(id_MSS)
Figura 16 - Configuração da Infra-estrutura
4.3 Ferramentas e Linguagens de Programação Utilizadas
Para realizar a adaptação do modelo proposto por (DEQUECH, 2003) foram utilizadas as
seguintes ferramentas:
4.3.1 Java
Como no protótipo inicial desenvolvido por (DEQUECH, 2003), foi dada continuidade
na utilização da tecnologia Java pelos mesmos aspectos já apresentados neste trabalho. A
tecnologia Java propicia aspectos importantíssimos para o desenvolvimento deste trabalho, tais
como: simplicidade, robustez, segurança e portabilidade.
42
Por estarmos tratando de um modelo para atender especificamente redes sem fio, a
portabilidade se torna essencial, pois a partir dela é possível desenvolver aplicações para
atender as necessidades dos dispositivos de capacidade limitada de processamento e memória.
Por outro lado, a tecnologia Java também propicia o desenvolvimento de aplicações mais
robustas que exigem, por exemplo, a utilização de servidores de aplicação.
4.3.2 JMS
Neste trabalho foi utilizado o Java Message Service (JMS) (JMS, 2003), que é uma
especificação desenvolvida pela Sun Microsystems para prover uma maneira de aplicações
Java se comunicarem através de troca de mensagens. O JMS faz parte de um leque de
produtos conhecidos por MOM (Message Oriented Middleware) que são baseados em trocas
de mensagens e compõem a edição J2EE (Java Enterprise Edition) (J2EE, 2003). Esse pacote
denominado “javax.jms” inclui interfaces que possibilitam o desenvolvimento de aplicações
que criem, recebam e enviem mensagens.
Na literatura podem-se encontrar vários trabalhos relacionados ao paradigma
publish/subscribe onde é utilizado o JMS. É o caso, por exemplo, de (VOLLSET, 2003) onde
o JMS é utilizado na implementação de uma solução para redes ad-hoc (MANETS). Neste
caso soluções conhecidas como “server-based”, ou seja, baseada em uma arquitetura
centralizada não é adequada visto que as redes ad-hoc não necessitam de um ponto de acesso
centralizado para estabelecer uma comunicação entre os clientes. Portanto, para atender a
arquitetura das redes ad-hoc é necessária a utilização de soluções chamadas de “server-less”,
onde não existe um servidor central e as informações precisam ser armazenadas de forma
distribuída.
4.3.2.1 Modelos de Mensagens JMS
O JMS possui dois modelos para as trocas de mensagens: o modelo publish/subscribe e o
modelo ponto-a-ponto. A grande diferença entre eles está justamente nas características
apresentadas no Capítulo1, ou seja, no modelo publish/subscribe a comunicação realizada é
assíncrona, anônima e de natureza multicast. Já no caso do modelo ponto-a-ponto é utilizado o
conceito de filas de mensagens, onde os clientes extraem as mensagens de forma síncrona.
Além disso, o modelo ponto-a-ponto apresenta natureza unicast, ou seja, ao contrário do
modelo publish/subscribe, uma mensagem é consumida por apenas um cliente.
43
4.3.2.2 Elementos do modelo Publish/Subscribe
A arquitetura definida pelo J2EE (J2EE, 2003) permite o desenvolvimento de aplicações
distribuídas em ambientes heterogêneos. Utilizando a arquitetura JMS de forma simples pode-
se descrever o fluxo de uma aplicação: o cliente produtor cria uma mensagem e a envia para
um destino no servidor de notificação. Este servidor poderá receber estas mensagens e
armazená-las para posterior entrega ou entregá-las automaticamente caso os clientes estejam
prontos para recebê-las.
A leitura dessas mensagens pode ser realizada de duas formas: síncrona ou assíncrona.
Na primeira forma o cliente realiza uma chamada ao método “receive” para iniciar o consumo
das mensagens armazenadas no servidor. Já no segundo caso é possível registrar um listener
associado a um tópico. Quando uma mensagem é enviada para um determinado tópico o
listener identifica esta situação e é capaz de encaminhar a mensagem automaticamente. Desta
forma é possível que os clientes consumam todas as mensagens publicadas no servidor.
Portanto, para realizar a comunicação fim a fim, várias entidades estão envolvidas, são
elas:
JMS Providers: Os providers são aplicações servidoras, desenvolvidas por
empresas especializadas, que implementam as interfaces do padrão JMS (NUMAZAKI,
2004). No provider se encontram os objetos administrativos do sistema tais como
(connection factories, connections, sessions, topics, queues, destinations). Só a partir da
criação desses objetos que possível à realização da comunicação. O provider também é
responsável por realizar a garantia ou não das entregas das mensagens. Isso porque ao
receber uma mensagem ele responde com uma confirmação (acknowledgement),
permitindo que erros possam ser tratados. O mesmo acontece quando as mensagens são
consumidas. Portanto, para atender a estas necessidades os providers possuem dois
modos de tratar as mensagens recebidas, de modo persistente e de modo não
persistente.
• No modo persistente, em caso de falha ou desconexão do cliente, as mensagens
poderão ser recuperadas, pois elas são armazenadas localmente no servidor. A
Figura 17 ilustra como as mensagens serão armazenadas, ou seja, o JMS Provider
ao receber mensagens enviadas através de um produtor de mensagens irá
armazená-las em disco. Porém uma desvantagem desse método é o consumo
maior de tempo de processamento além de requerer maior espaço do servidor.
44
JMS ProviderProdutor de Mensagem
Consumidor de Mensagens
RecebimentoEnvio
Confirmação Confirmação
Disco
Armazenar Remover
Figura 17 - Modo Persistente
• Já no modo não persistente as mensagens não são persistidas, ou seja, não serão
recuperadas em caso de falha do sistema ou desconexão do cliente, como
ilustrado na Figura 18, porém serão processadas mais rapidamente pelo sistema.
JMS Prov iderProdu to r de M ensagem
Consumido r de M ensagens
Receb im entoEnvio
Confirm ação Confirm ação
Figura 18 - Modo Não Persistente
• Clientes JMS: São programas ou componentes altamente especializados,
geralmente desenvolvidos em Java que, utilizando um JMS provider específico,
produzem e consomem mensagens. (NUMAZAKI, 2004)
• Mensagens JMS: São objetos serializáveis que, através de um conjunto de JMS
providers, trocam informações ou que executam procedimentos entre dois ou
mais clientes JMS (NUMAZAKI, 2004). As mensagens são compostas por três
partes, o cabeçalho as propriedades e o corpo. Em geral, no corpo da mensagem
elas podem assumir cinco formatos diferentes definidos pela API (Text Message,
Byte Message, Map Message, Stream Message e Message).
4.3.3 Protocolo Multicast (LRMP)
A Internet primariamente foi utilizada com aplicações distribuídas, baseadas na
arquitetura cliente-servidor, ou seja, utilizando protocolos de comunicação com conceito de
45
“um para um”. Essas aplicações utilizam primitivas de comunicações denominadas unicast.
Por outro lado existem outras aplicações onde é necessária a transmissão de dados a todos os
hosts pertencentes à mesma sub-rede, ou seja, utilizando o conceito de “um para todos”,
denominada comunicação broadcast.
Estas duas maneiras de comunicação, apesar de bastante utilizadas, apresentam
problemas. No primeiro caso os pacotes são enviados repetidamente a todos os hosts
provocando um desperdício na utilização da banda disponível, visto que o mesmo pacote é
enviado repetidamente a vários hosts.
Já no segundo caso o problema se encontra na sobrecarga da rede, visto que o pacote de
dados é enviado apenas uma vez, sem duplicações, no entanto uma cópia do pacote é
transmitida a todos os hosts da rede, sendo eles receptores ou não.
Entre estas duas comunicações existe a comunicação multicast que envia um
determinado pacote de dados a um conjunto de hosts pertencentes a um determinado grupo.
Desta maneira evita-se o problema de sobrecarga na rede, pois somente os hosts pertencentes a
este grupo receberão o pacote e sem repetições, pois o pacote é enviado apenas uma vez,
evitando-se desperdício de banda.
Dependendo do número de hosts receptores em uma aplicação é possível utilizar o
multicast “um para um” ou “muitos para muitos”, que são as formas básicas deste protocolo.
O protocolo LRMP (Light-weight Reliable Multicasting Protocol) é um protocolo
multicast confiável. Foi implementado em Java, como uma extensão dos protocolos RTP (Real
Time Protocol) e RTCP (Real Time Transport Control Protocol) e está disponível como uma
biblioteca reutilizável. O LRMP garante a entrega seqüencial e confiável dos dados (LIAO,
1998). O grande diferencial deste protocolo está no fato de suportar o envio de “muitos para
muitos”, ou seja, vários “senders” em uma mesma aplicação. Além disso, o protocolo provê
um mecanismo de recuperação de erros chamado REP (Random Expanding Probe), um
esquema de controle de congestionamento baseado em NACK´s (Negative Acknowledgements)
e em um protocolo conhecido por FEC (Forward Error Correction).
O fato do controle de congestionamento ser baseado em NACK´s reduz
significantemente o número de mensagens transportadas na rede, se comparado aos modelos
usuais que utilizam os ACK´s (Acknowledgement), ou seja, respostas positivas para a
confirmação de chegada de um pacote. Neste caso só são enviadas mensagens de não
confirmação nos casos em que há perdas de pacotes na rede.
O LRMP permite que a taxa de transmissão dos dados possa ser adaptada de acordo com
a aplicação, mas sempre dentro de um intervalo conhecido por (RMin, RMax), onde RMin
significa a taxa mínima de transmissão e RMax a taxa máxima.
46
Além da taxa de transmissão é possível adaptar o tamanho do buffer, tanto no sender
quanto no receiver. O buffer é utilizado para armazenar os últimos pacotes enviados ou
recebidos, para que seja possível a recuperação dos mesmos em caso de perda de pacotes e
portanto possui uma ligação direta com a taxa de transmissão máxima utilizada. É
recomendado que o tamanho do buffer corresponda ao valor do intervalo de dez segundos a um
minuto de transmissão de dados, utilizando a taxa máxima, ou seja, para uma taxa máxima de
64kbits/s é recomendado que o buffer utilizado esteja entre o intervalo de 80KB e 480KB.
4.4 Interação dos Componentes
Para a implementação do modelo utilizando a arquitetura publish/subscribe é necessário
que haja a interação de todos os componentes da rede através das interfaces acima descritas.
Para isso algumas operações principais são definidas: scanning, subscribe/unsubscribe, publish
e o deslocamento.
4.4.1 Scanning
Como descrito anteriormente, antes de uma estação móvel ter acesso a uma rede sem fio
ela terá que encontrar uma rede disponível. Esta tarefa denominada de scanning é realizada
através da leitura de alguns parâmetros que são enviados pelos pontos de acessos através de
quadros Beacon, representado na Figura 19 por Send_Beacon_Frames(param). Todas as redes
detectadas serão armazenadas em uma lista para que no futuro estas redes possam ser utilizadas
no caso da rede atual não possuir o serviço de subscrição. Esta tarefa está representada por
Keep_List().
A estação móvel, ao percorrer os canais das redes até então detectadas, irá receber os
parâmetros para que sejam avaliados, aqui representados por Analise_Frames(). Normalmente
a estação móvel se associa automaticamente à melhor opção, ou seja, aquela que possui o sinal
mais forte. Porém dentro do modelo proposto esta situação não seria a mais adequada, pois
caso existam vários sinais sendo detectados, de diferentes redes, o cliente poderia acabar se
associando a uma rede que não possua o sistema publish/subscribe. Portanto o modelo deverá
atender a estas duas situações, ou seja, possibilitar a detecção das redes existentes através da
análise dos sinais recebidos e após se associar à rede, deverá verificar se ela possui suporte ao
serviço publish/subscribe.
Depois de analisar os sinais recebidos a estação móvel deverá se conectar a um ponto de
acesso e para isso enviará, através de uma interface de rede sem fio, os parâmetros do ponto de
47
acesso escolhido, ilustrado por Joining(param). Ao estabelecer a comunicação com o ponto de
acesso escolhido, haverá a sincronização da estação móvel com o resto da rede para que sejam
respeitados os intervalos de tempo de comunicação entre os dispositivos. Mesmo estabelecendo
a comunicação e havendo esta troca de informação entre o ponto de acesso e a estação móvel,
ainda não existe acesso à rede propriamente dita. Para que isso aconteça é necessário que a
estação móvel realize o processo de autenticação.
Como descrito anteriormente, este processo poderá ocorrer de duas maneiras, porém para
que o modelo suporte o mínimo de segurança desejável estaremos utilizando o processo
conhecido por Shared Key Authentication. Para realizar uma requisição de autenticação o
dispositivo móvel deve enviar um frame ao ponto de acesso informando o algoritmo de
autenticação utilizado (Open Authentication ou Shared Key) e um número de seqüência. Esta
requisição é representada por Request_Authentication(authent, sequence). Ao receber a
requisição o ponto de acesso poderá negar o pedido de autenticação, finalizando o processo.
Dispositivo Móvel
Send_Beacon_Frames( param )
Analise_Frames()
Joining( param )
Request_Authentication(authent, sequence)
Response_Authentication(authent, sequence, status, challenge)
Response_Chalenge(authent, sequence, challenge)
Decrypt_Challenge(authent, sequence, satus)
3Ponto de Acesso2
Ponto de Acesso1
Ponto de Acesso
Send_Beacon_Frames( param )
Send_Beacon_Frames( param )
Keep_List()
Figura 19 - Scanning
Caso a requisição seja aceita, o ponto de acesso deverá informar, além do algoritmo de
autenticação e do número de seqüência, um código de status para representar a aceitação da
requisição e também o desafio que deverá ser respondido pelo dispositivo móvel, como mostra
48
a Figura 19 por Response_Authentication(authent, sequence, status, challenge). Depois de ter
o desafio respondido pelo dispositivo móvel, o ponto de acesso deverá decifrar o desafio e
verificar a integridade da chave WEP. Caso isto ocorra, o ponto de acesso deverá responder
com o código de status, Decrypt_Challenge(authent, sequence, satus), para identificar que o
dispositivo foi autenticado com sucesso.
Terminado o processo de autenticação, o dispositivo móvel deverá logo em seguida
executar o processo de associação para realmente ter acesso à rede. Este processo nada mais é
do que relacionar o dispositivo móvel ao ponto de acesso da rede correspondente através de um
identificador unívoco conhecido por Association ID (AID). Através deste identificador o ponto
de acesso consegue identificar qualquer frame e encaminhá-lo à estação móvel correspondente.
Portanto a estação móvel realiza uma requisição de autenticação ao ponto de acesso,
representado na Figura 20 através das mensagens Association_Request(). Caso esta requisição
seja aceita, o ponto de acesso enviará um identificador para a estação móvel através de
ID:Association_Response(). Quando esta tarefa acontece, todos os pacotes que forem
endereçados a esta determinada estação móvel serão encaminhados através do ponto de acesso
associado. Na arquitetura publish/subscribe, os subscribers irão tanto se cadastrar no serviço
quanto receber as mensagens a eles associadas através desse ponto de acesso.
Dispositivo Móvel Ponto de Acesso
Association_Request()
ID:Association_Response()
Request_Service()
Figura 20- Processo de Associação
Depois de autenticada a estação móvel tem acesso à rede e portanto para estabelecer
qualquer comunicação, deverá possuir um endereço IP. Este endereço poderá ser configurado
manualmente em cada estação, porém isso demandaria um grande esforço. A maioria dos
pontos de acessos atualmente comercializados já possui um servidor DHCP (Dynamic Host
49
Configuration Protocol) embutido, o que facilita em muito a obtenção de endereços lógicos
para os dispositivos móveis.
No modelo proposto estaremos utilizando um único servidor DHCP localizado na rede
fixa, visto que a inserção de vários servidores DHCP, habilitados no próprio ponto de acesso,
poderia causar problemas de duplicação de endereços na rede, pois cada servidor armazenaria
uma base de endereços independente.
Depois de obter um endereço IP e ter acesso a rede propriamente dita é necessário
verificar a existência do serviço publish/subscribe. Esta verificação é ilustrada na Figura 20 por
Request_Service(). Caso o serviço não esteja presente na rede em que o dispositivo móvel
esteja conectado, então deverá se desconectar da rede atual e tentar se conectar em outra rede a
qual tenha recebido sinal e tenha seu identificador armazenado na lista. Assim o processo será
reiniciado até que se encontre uma rede que possua o serviço disponível.
4.4.2 Subscribe
Os subscribers nada mais são do que as interfaces de comunicação entre os usuários
finais e o sistema publish/subscribe. É através deles que os usuários móveis terão acesso aos
eventos que expressaram algum interesse. Mas para que isso aconteça é necessário que o
subscriber seja cadastrado no sistema, ou seja, o subscriber vai se comunicar com o MSS para
que o MSS possa comunicar ao Coordenador que um novo usuário será cadastrado e estará sob
sua responsabilidade. De acordo com o modelo proposto, um Coordenador poderá ter vários
MSS sob sua responsabilidade, porém um MSS deverá estar cadastrado em um único
Coordenador. A representação para a criação da subscrição neste modelo está representada por
Create_Sub(subscription), como ilustrado na Figura 21.
Logo depois de criada, a subscrição deverá ser enviada ao MSS através de
Subs_MSS(subscription,id_Sub) utilizando a infra-estrutura da rede sem fio. O MSS ao recebê-
la deverá repassá-la ao Coordenador através da chamada Subs_Coord(subscription, id_Sub,
id_MSS) para que este reconheça uma nova subscrição e a armazene através da chamada
Save_Subs(subscription, id_Sub, id_MSS, id_Coord).
Essa troca de informação entre o subscriber até chegar ao Coordenador deverá ser
confirmada, pois o subscriber precisa ter o conhecimento do MSS e do Coordenador
responsável pela sua subscrição. Isso porque se o usuário desejar o encerramento de sua
participação no sistema em qualquer instante, deverá fornecer o MSS e o Coordenador ao qual
estava atrelado. Portanto o Coordenador envia AKC_Coord(id_MSS,id_Sub,id_Coord) ao MSS
que ao receber a confirmação irá encaminhá-la ao subscriber através de
50
ACK_MSS(id_MSS,id_Sub,id_Coord). O Subscriber ao receber a confirmação deverá
armazená-la na sua base de dados, aqui representada por Save(id_MSS,id_Sub,id_Coord) para
então finalizar o processo de subscrição.
SubscriberMSS CoordenadorBD_Subscriber
BD_Coordenador
Create_Sub(subscription)
Subs_MSS( subscription, id_Sub), Subs_Coord(subscription, id_Sub,id_MSS)
Save_Subs(subscription, id_Sub,id_MSS, id_Coord)
ACK_Coord(id_MSS, id_Sub, id_Coord)
ACK_MSS( id_MSS,id_Sub, id_Coord)
Save(id_MSS, id_Sub, id_Coord)
Figura 21 - Processo de Subscrição
4.4.3 Publish
Para que um publisher possa publicar suas mensagens é necessário uma requisição de
conexão com um dos coordenadores do sistema. Ao atender a uma requisição o coordenador
passará a ser responsável por receber os eventos publicados e portando deverá realizar a
autenticação deste publisher por questões de segurança. Para realizar esta operação é
necessário que o coordenador verifique em sua base se o publisher esta cadastrado no sistema.
Esta verificação, representada por Request_Validate(id_publisher) na Figura 22, é realizada
para que então o coordenador retorne ao publisher um token. Este token nada mais é que uma
maneira de disponibilizar o serviço de publicação durante um certo período de tempo, ou seja,
este token estará associado a um timestamp. Desta maneira impossibilita-se a tentativa de
publicações indevidas no sistema.
Depois de autenticado o publisher poderá enviar seus eventos ao Coordenador ao qual se
conectou, através de Publish(event). Exatamente neste ponto foi realizada a primeira adaptação
no modelo, pois como se trata do envio de um arquivo de vídeo e o mesmo será enviado
posteriormente a todos os coordenadores do sistema via protocolo multicast, houve a
51
necessidade de realizar a leitura do arquivo e enviá-lo em pequenas porções. O tamanho
máximo da MTU no protocolo multicast é de 1400 bytes e por este motivo o arquivo foi
dividido em pequenas porções de 1Kb.
Como vários publishers podem estar publicando arquivos ao mesmo tempo, uma segunda
adaptação foi realizada. Em cada pacote transmitido foi enviado, um identificador da sessão, e
o endereço de origem e destino que serão usados para compor os arquivos LOG do sistema.
Portanto existe uma perda, em termos de utilização de banda, visto que a mesma informação é
enviada várias vezes através da rede. Além dos pacotes de dados propriamente ditos são
enviadas, no primeiro pacote, informações apenas de controle. Essas informações como: o
nome do tópico a ser publicado, o nome e tamanho do arquivo que será publicado, são
necessárias para posterior recepção.
O coordenador ao receber esta mensagem deverá enviá-la a todos os coordenadores da
rede, através de um protocolo de grupo, aqui representado por Send(event).
Publisher Coordenador BD_Coordenador
Request_Connection(id_publisher)
Publish(event)
Response_Connection(token)
PROTOCOLO DE GRUPO
Send(event)
Receive(event)
Response_Validate(token)
Request_Validate(id_publisher)
Figura 22 - Processo de Publicação de Eventos
Ao receber um evento através da função Receive(event), o Coordenador deve pesquisar
se existe alguma subscrição sob sua responsabilidade que expresse interesse em receber este
evento. Se não houver interessados no evento, este simplesmente será descartado. Caso exista
52
algum, é necessário obter seu identificador e em qual MSS os subscribers estão cadastrados,
para que as mensagens sejam roteadas corretamente. Essa busca é representada na Figura 23
por Get_Subs(subscription) e logo após a obtenção dos identificadores deve-se armazenar este
evento no buffer local do Coordenador, representado por Update(event, id_Sub, time).
Na implementação do modelo este passo não foi realizado, visto que estamos utilizando o
modo de operação não persistente no servidor de aplicação. Isso implica que as mensagens não
são armazenadas no servidor e só são entregues para os subscribers que estiverem “on-line” no
momento da publicação. Portanto se não houver outras mensagens neste buffer a serem
entregues, a mensagem deve ser enviada ao MSS através de send_MSS(event, id_Sub, id_MSS).
Caso existam outros arquivos armazenados no buffer, deve-se pesquisar qual é a arquivo mais
antigo para que se possa manter a ordem cronológica. Após receber o arquivo o MSS deverá
verificar se o subscriber, ao qual o arquivo é endereçado, ainda está sob sua responsabilidade.
Essa verificação será realizada por Request_MSS(id_Sub) e Response_MSS(id_Sub). Caso o
subscriber não esteja sob a responsabilidade desse MSS, então o evento é descartado pelo
MSS, mas continuará armazenado no buffer do Coordenador.
Se o subscriber estiver sob responsabilidade do MSS então o arquivo será enviado ao
subscriber pela função Send_Message(event, id_Sub, id_MSS) através da infra-estrutura de
rede móvel, que ficará encarregada de entregar a mensagem para o subscriber correto.
MSS Coordenador BD_CoordenadorSubscriber BD_MSS
IF event = Get_Subs(subscription)
Update(event, id_Sub, time)
Send_MSS(event, id_Sub)Request_MSS(id_Sub)
Response_MSS(id_Sub)
Send_Message(event, id_Sub, id_MSS)
Figura 23 - Envio do evento ao subscriber
53
Quando a aplicação subscriber receber o evento, deverá realizar uma comparação com os
últimos eventos recebidos para que não haja o recebimento de eventos duplicados,
representados através da função Request_Event(event) e Response_Event(event) na Figura 24.
Essa condição pode ocorrer caso a estação móvel perca a conexão antes da confirmação do
recebimento do evento. Se esta situação ocorrer o Coordenador irá reenviar o evento ao
subscriber.
Caso o evento não seja um evento duplicado, então o evento é disponibilizado ao usuário
através da aplicação subscriber Show_Event(event) e uma confirmação do recebimento do
evento é enviada ao Coordenador. A infra-estrutura de rede ficará responsável por encaminhá-
la ao MSS através de ACK_Show_MSS(event, id_Sub), que posteriormente é entregue ao
Coordenador através de ACK_Show_Coord(event, id_Sub).
Ao receber a mensagem de reconhecimento o Coordenador deverá excluir o evento
armazenado no seu buffer local, representada na Figura 24 por Del_event(event,id_Sub), para
que esta não seja entregue novamente ao subscriber. Depois de concluída a exclusão, se
existirem outras mensagens armazenadas no buffer a serem entregues ao subscriber o mesmo
procedimento deverá se repetir.
MSS Coordenador BD_CoordenadorSubscriber
BD_Subscriber
Request_Event(event)
Response_Event(event)
Show_Event(event)
ACK_Show_MSS(event, id_Sub)
ACK_Show_Coord(event, id_Sub)
Del_event(event,id_Sub)
Figura 24 - Confirmação do Recebimento
Toda esta seqüência de operações ocorre somente quando o modo de operação é do tipo
persistente no servidor de aplicação, ou seja, as mensagens são armazenadas no servidor e
também quando o subscriber estiver ativo e cadastrado no sistema. Como foi utilizado durante
a implementação deste sistema o modo não persistente, todos os passos ilustrados na Figura 24
54
foram omitidos, pois como as mensagens não são gravadas em disco, não existiu a necessidade
da confirmação de recebimento através de ACK´s.
Porém se no caso da utilização do modo persistente o dispositivo móvel que estiver
utilizando a aplicação subscriber estiver desligado ou fora da área de cobertura, todos os
eventos que forem destinados a ele não serão entregues e ficarão armazenados no buffer do
usuário. Esse buffer deverá se lido periodicamente para que seja possível a recuperação dos
arquivos ainda não entregues. A leitura do buffer é representada pela função timer(), como
ilustrado na Figura 25, que vai especificar a freqüência em que essas mensagens serão lidas.
Toda vez que um evento é enviado ao subscriber o timer() é inicializado e ao ser
expirado, o Coordenador envia uma requisição à base de dados, onde se encontra o buffer do
subscriber, através de Request_Events() verifica a existência ou não de eventos armazenados.
Em resposta a esta requisição é enviado Response_Events(), que retorna o evento a mais tempo
armazenado no buffer do subscriber juntamente com o identificador do MSS aonde este
subscriber está cadastrado. Ao receber o identificador do MSS, o Coordenador enviará o
evento ao MSS, representado por send_MSS(event, id_Sub) que tentará entregá-lo ao
subscriber, reiniciando o processo ilustrado na Figura 23.
O buffer citado deverá possuir uma capacidade de armazenamento limitada, imposta por
requisitos estabelecidos para o desenvolvimento do sistema. Ao se alcançar o tamanho máximo
do buffer as mensagens há mais tempo armazenadas serão excluídas.
MSS Coordenador
timer()
Request_Events()
Response_Events()
send_MSS(event,id_Sub)
BD_Coordenador
Figura 25 - Leitura do buffer
55
4.4.4 Deslocamento
Por este modelo se tratar de um ambiente móvel (redes 802.11), deverá ser capaz de
tratar a situação de deslocamento, ou seja, a troca de área de cobertura. Para isso a estrutura
que ficará responsável por realizar o interfaceamento entre a rede sem fio e a rede cabeada é o
MSS. Isso será possível, pois toda vez que uma estação móvel se associar a um ponto de acesso
deverá prestar um identificador unívoco a ele, o que será o suficiente para identificar cada uma
das estações móveis. Esses dados serão obtidos através de requisições realizadas ao ponto de
acesso, representada na Figura 26 por Request_Address(). O ponto de acesso wireless irá
responder por esta requisição através de Response_Address(id_Sub). Essa requisição deverá ser
realizada com uma certa periodicidade para que o MSS mantenha uma tabela sempre
atualizada, possibilitando identificar quais estações móveis estão conectadas a quais pontos de
acesso.
Subscriber MSS BD_MSS
Request_New(id_Sub[])
Response_New(id_Sub)
Ponto de Acesso Wireless
Request_Adress()
Response_Address(id_Sub)
Send_Ident(id_Sub, id_MSS)
send_Ident(id_MSS)
Figura 26 - Procedimento de Deslocamento
Depois de solicitar ao ponto de acesso quais estações estão conectadas, o MSS deverá
verificar se a estação que está conectada na rede está sob sua responsabilidade. Essa verificação
é realizada por Request_New(id_Sub()) e o retorno desta solicitação é recebida através de
Response_New(id_sub). Ao identificar os novos subscribers, o MSS deverá enviar a estes
subscribers uma mensagem contendo o seu próprio identificador, através de
Send_Indent(id_Sub,id_MSS). Ao receber esta mensagem o subscriber realizará uma
56
atualização na base de dados local do subscriber através de Update_id(id_MSS) e
posteriormente reenvia sua subscrição para que a infra-estrutura publish/subscribe tome
conhecimento dessa mudança, como ilustrado na Figura 27.
Subscriber MSS CoordenadorBD_Subscriber
update_id(id_MSS)
release_MSS(subscription, id_Sub, id_oldCoord)
release_Coord(subscription, id_Sub, id_MSS, id_oldCoord)
Figura 27 - Reenvio da Subscrição
A subscrição é enviada ao novo MSS juntamente com o identificador do subscriber e o
identificador do Coordenador que era responsável pelo subscriber antes do deslocamento,
ilustrado por release_MSS(subscription, id_Sub, id_oldCoord). Esses dados são repassados
para o Coordenador através de release_Coord(subscription, id_Sub, id_MSS, id_oldCoord).
Logo que receber a mensagem o Coordenador deverá realizar uma comparação entre o
identificador recebido e o seu próprio identificador. Caso os identificadores sejam iguais, isso
significa que o subscriber mudou apenas de MSS e não de Coordenador, devendo apenas
atualizar os dados referentes ao MSS através de update_MSS(id_Sub ,MSS_id).
57
Coordenador BD_Old_CoordenadorOld_Coordenador
Request_Buffer( id_Sub)
Response_Buffer(events[])
BD_Coordenador
If (id_Coord = id_oldCoord)update_MSS(id_Sub, id_MSS)
Elseupdate_Subscriber(subscription,id_Sub, id_MSS)
cancel_Subscription(id_Sub)
Request_Events()
response_Events(events[])
Figura 28 - Validação do Coordenador
No caso dos identificadores serem diferentes, significa que além do MSS, o subscriber
também passou a estar sob responsabilidade de outro Coordenador. Neste caso o novo
Coordenador deverá atualizar as suas informações através de update_Subscriber(subscription,
id_Sub , id_MSS), como mostra a Figura 28, e logo em seguida deverá realizar o cancelamento
da antiga subscrição no antigo coordenador, representado por cancel_Subscription(id_Sub).
Após isso o Coordenador deverá requisitar ao antigo Coordenador as mensagens, que
possam ter sido armazenadas no buffer durante o período de deslocamento. Essa ação é
representada pela mensagem Request_Events(), enviada pelo atual Coordenador.
O antigo Coordenador vai realizar uma pesquisa na sua base de dados local através da
função Request_Buffer(id_Sub), e caso encontre alguma mensagem irá responder com
Response_Buffer(events()). Neste contexto (events()) irá representar as mensagens que estavam
armazenadas na base de dados. A partir disso, o antigo Coordenador irá enviar as mensagens
ao atual Coordenador através da função response_Events(events()).
4.4.5 Unsubscribe
Caso o usuário final expresse seu interesse em cancelar o serviço, o subscriber deverá enviar
uma mensagem solicitando o cancelamento da subscrição ao Coordenador, representada na
58
Figura 29 por Unsub_MSS(subscription, id_Sub, id_MSS, id_Coord). O MSS ao receber essa
mensagem irá encaminhá-la ao Coordenador através de Unsubs_Coord(subscription, id_Sub,
id_MSS, id_Coord), que ao receber esta requisição deverá verificar a existência de mensagens
armazenadas no buffer do subscriber a ser entregue. Caso haja alguma mensagem pendente,
então o Coordenador irá excluí-la através de Delete_Buffer() e posteriormente deverá cancelar
a subscrição.
Assim quando o Publisher iniciar o envio de mensagens ao Coordenador, este deverá
realizar uma busca dos subscribers interessados no assunto determinado. Como a subscrição
foi cancelada, o Coordenador não irá encontrar nenhum registro na sua base de dados e
conseqüentemente o subscriber não mais receberá mensagens.
Subscriber MSS Coordenador BD_Coordenador
Unsubs_Coord(subscription,id_Sub, id_MSS, id_Coord)
Save_Unsub(subscription, id_Sub, id_MSS, id_Coord)
Unsub_MSS(subscription, id_Sub, id_MSS, id_Coord)
Delete_Buffer()
Figura 29 - Processo de Cancelamento da Subscrição
4.5 Conclusão
Com base no modelo proposto por (DEQUECH, 2003) foi possível apresentar as
adaptações realizadas nas estruturas de comunicação, utilizadas entre os componentes do
sistema, possibilitando a transmissão de fluxos contínuos de dados. Primeiramente foi
apresentada a arquitetura do modelo proposto, assim como a integração entre os componentes
do sistema.
59
Logo em seguida foram apresentadas as ferramentas e a linguagem de programação
utilizadas na implementação e adaptação do sistema. Dentro deste contexto é importante
ressaltar que o modo de tratamento das mensagens utilizado no servidor de aplicação (não
persistente) foi de fundamental importância no decorrer do trabalho.
A partir disso foram apresentados alguns diagramas de seqüência de tarefas, que
possibilitam um melhor entendimento do funcionamento do sistema e das integrações entre os
componentes. Estes diagramas representaram algumas funcionalidades do sistema, tais como as
operações de scanning da rede, subscrição do usuário no sistema, a publicação dos arquivos, o
encerramento de uma subscrição e um eventual deslocamento.
Depois de ter apresentado as adaptações no modelo é necessário realizar uma análise do
comportamento do sistema, avaliando os impactos que tais adaptações podem resultar. Portanto
no capítulo a seguir serão apresentados os cenários onde foram realizadas algumas simulações,
com o intuito de avaliar requisitos ligados diretamente à qualidade de serviço oferecidos por
esta nova proposta.
60
5 Modelo de Implementação
5.1 Introdução
Através do desenvolvimento do modelo proposto, foi possível realizar alguns
experimentos com intuito de analisar os resultados obtidos e investigar se o modelo proposto
atende os requisitos mínimos de qualidade de serviço necessários para transmissões de
arquivos multimídia. Como já citado no capítulo 3, existem algumas aplicações, como as de
tempo real, que exigem confiabilidade absoluta. Já as aplicações multimídia são menos rígidas
em relação à confiabilidade, pois toleram perdas ocasionais de pacotes. Porém requerem
limites rígidos em relação à uniformidade na entrega de pacotes, pois o que mais importa é a
variação no atraso, visto que um fluxo de vídeo deve ser recepcionado de forma suave e
contínua.
De acordo com a divisão realizada pela ETSI, as aplicações multimídia (áudio e vídeo
streaming) estão classificadas dentro da classe Streaming. Isso quer dizer que estas aplicações
devem respeitar os valores máximos sugeridos de 2 segundos para a variação de atraso e de até
2% de perdas de pacotes.
Para a transmissão de quadros de vídeo costuma-se ser adotado o protocolo UDP na
camada de transporte, pois fornece um serviço de transmissão sem conexão, não confiável.
Esses fatores tornam este protocolo mais rápido, permitindo alcançar taxas de transmissões
maiores, pois não usa confirmação para certificar-se que as mensagens chegaram, não ordena
as mensagens de entrada e não fornece informações para controlar a velocidade com que os
dados fluem entre as máquinas.
Pelos mesmos motivos apresentados para a utilização do protocolo UDP na camada de
transporte, acredita-se que não seria necessária a utilização de um protocolo multicast confiável
para a transmissão de fluxos de vídeo. Apesar do protocolo LRMP ser considerado um
protocolo confiável, ele propicia a não utilização dos controles de fluxo e de
congestionamento, possibilitando a sua utilização de forma não confiável (BestEffort ou melhor
esforço).
Dentro deste contexto, foram realizadas algumas simulações utilizando diferentes
cenários, nos quais foram variados os parâmetros de confiabilidade (BestEffort, Adapted
Throughput) e de controle de fluxo(LimitedLoss, LossAllowed, NoLoss) do protocolo multicast,
na tentativa de avaliar o cenário mais adequado para realizar as transmissões.
61
Em todos os cenários utilizados foi enviado um arquivo de vídeo com tamanho de
270KB, que ao ser particionado em frações de 1K e adicionando o tamanho do cabeçalho
enviado em todos os pacotes, resultou em 287 pacotes transmitidos. Logo em seguida foi
utilizado um arquivo de 1080KB, ou seja, quatro vezes maior, para analisar o impacto que o
tamanho do arquivo pode causar ao sistema.
5.2 Arquitetura do Sistema
Para realizar os experimentos no modelo proposto foi utilizada uma rede sem fio (infra-
estruturada), com quatro máquinas e um ponto de acesso. Dentre as máquinas disponíveis na
rede havia dois AMD Athlon 2400 com 512MB de memória, utilizando placas wireless D-Link
padrão PCI, um Pentium (4) 3.2GHz com 512MB de memória e um Pentium (4) 3.4GHz com
1GB de memória. As duas últimas máquinas descritas utilizaram antenas D-Link padrão
USB2.0. Tanto as máquinas que utilizaram as placas padrão PCI como as que utilizaram padrão
USB2.0 transmitiam dados no padrão IEEE 802.11g. Para facilitar a visualização do sistema
foram adotados identificadores associados a cada um dos elementos utilizados nas simulações,
como mostra a figura a seguir.
P on to d e A cesso
w ire less1 w ire less3
w ire less4
w ire less2
Figura 30 - Ambiente de Implementação
Utilizando a arquitetura proposta, foi executado, na máquina wireless4, o coordenador do
sistema, responsável por receber os arquivos dos publishers, enviá-los via protocolo multicast a
todos os coordenadores do sistema e publicá-los em seus respectivos providers. Além do
62
coordenador, foi executado o MSS e o publisher, responsáveis pelo envio dos arquivos aos
clientes móveis e pela publicação dos arquivos respectivamente.
Nas simulações realizadas apenas um coordenador e um MSS foram utilizados, porém a
arquitetura possibilita a utilização de vários coordenadores e MSS´s, criando um ambiente
distribuído.
Nas máquinas wireless1, wireless2 e wireless3 foram instalados os subscribers, que nada
mais são que os clientes sem fio, os quais receberão os arquivos publicados no sistema.
A Tabela 1 ilustra a configuração do sistema utilizado durante as simulações, detalhando
o hardware e o software utilizados em cada um dos elementos do sistema.
Wireless1 Wireless2 Wireless3 Wireless4
Hardware -AMD Athlon 2400
com 512MB de
memória e placa de
rede wireless D-Link
padrão PCI.
-AMD Athlon 2400 com
512MB de memória e
placa de rede wireless
D-Link padrão PCI.
-Pentium(4) 3.2GHz
com 512MB de
memória e antenas D-
Link padrão USB 2.0
-Pentium(4) 3.4GHz
com 512MB de
memória e antenas
D-Link padrão USB
2.0
Software -Subscriber -Subscriber -Subscriber -Coordenador
-MSS
-Publisher
Tabela 1 - Tabela de configuração do sistema
Levando em consideração esses requisitos, em todas as simulações realizadas foram
capturadas as quantidades de pacotes perdidos e as variações do atraso entre os pacotes (jitter).
A latência não foi analisada, visto que para o seu cálculo necessita-se que os relógios das
máquinas estejam sincronizados. Nos itens a seguir serão descritos e analisados os diferentes
cenários e seus respectivos resultados obtidos.
5.3 Cenários
Como descrito anteriormente, apesar do protocolo LRMP ser considerado um protocolo
confiável, ele propicia a não utilização dos controles de fluxo e de congestionamento,
possibilitando a sua utilização de forma não confiável (BestEffort ou melhor esforço).
Nos três primeiros cenários foram colhidos alguns resultados utilizando o protocolo de
forma confiável, porém variando o nível de confiabilidade, ou seja, com perdas permitidas
(LossAllowed), com perdas limitadas (LimitedLoss) e sem perdas de pacotes (NoLoss). Nesses
63
três cenários foram utilizadas taxas de transmissão mínima de 64kbits/s, taxas de transmissão
máxima de 128kbits/s e buffer de 256KB. Esses valores foram utilizados, pois como citado no
Capítulo 4, o protocolo multicast LRMP possui um mecanismo de controle de
congestionamento baseado em NACK (negative acknowledgements), ou seja, quando um
receptor percebe a ausência de um pacote, então é lançada uma requisição na rede para que o
pacote seja retransmitido. Como os pacotes recentemente enviados e recebidos são
armazenados em buffers, o pacote só poderá ser recuperado caso ainda esteja presente em um
buffer. Caso contrário os pacotes são apenas descartados e considerados como perdidos.
Como o protocolo LRMP também possui um controle de fluxo baseado na variação das
taxas de transmissões, o tamanho do buffer está diretamente ligado às taxas de transmissões
utilizadas, visto que o buffer deverá ser suficientemente grande para recuperar os pacotes
perdidos. Recomenda-se, portanto que o tamanho do buffer corresponda em torno de dez
segundos a um minuto, utilizando a taxa máxima de transmissão. Ao utilizarmos a taxa
máxima de 128kbits/s, isso significa que o tamanho do buffer deve variar entre 160KB e
960KB.
Já no quarto e último cenário, como foi utilizado o protocolo multicast de forma não
confiável, ou seja, sem a utilização de recursos de controle de fluxo e congestionamento, não
existe a necessidade da adequação de valores para tamanho de buffers ou taxas de
transmissões.
5.3.1 Cenário nº 1
No primeiro experimento o protocolo multicast foi configurado para simular um cenário
confiável, com perdas limitadas (LimitedLoss), ou seja para certos tipos de pacotes a perda é
permitida. Desta maneira o protocolo garante a utilização do controle de fluxo e
congestionamento ao enviar os pacotes e o controle da ordenação dos pacotes ao recebê-los.
É importante ressaltar que a presença de grandes diferenças na variação do atraso
(jitter), ocasionando picos tanto negativos quanto positivos, podem representar uma distorção
na apresentação da imagem em uma transmissão de vídeo. Em caso de picos positivos, poderá
ocorrer um pequeno atraso na sua transmissão. Já a presença de picos negativos pode
representar uma aceleração na apresentação de um vídeo.
Através da Figura 31 pode-se perceber que a variação do atraso (jitter), nas
transmissões envolvendo o arquivo de 270KB, ficou dentro do valor aceitável de 2 segundos
(2000 milisegundos) em todas as máquinas. Ao aumentarmos o tamanho do arquivo de
64
transmissão para 1080KB, as máquinas wireless1 e wireless2 apresentaram resultados
aceitáveis, dentro do valor de 2 segundos e, portanto apesar da presença de alguns picos, a sua
visualização não será afetada. Já na máquina wireless3 alguns picos ultrapassaram o valor
aceitável de 2 segundos.
Deve ser feita uma observação que a máquina wireless3 utilizou uma antena de
transmissão com padrão USB2.0 diferentemente das máquinas wireless1 e wireless2, que
utilizaram antenas padrão PCI. Portanto a diferença de velocidade de transmissão do
barramento poderá estar afetando o resultado das transmissões.
LimitedLoss -Wireless1
-500
0
500
1000
1500
2000
2500
3000
3500
1
23
45
67
89
111
133
155
177
199
221
243
265
287
Nº de pacotes enviados
Jitter (m
ilisegundos)
LimitedLoss -Wireless1
-500
0
500
1000
1500
2000
2500
3000
3500
1
68
135
202
269
336
403
470
537
604
671
738
805
872
939
1006
1073
1140
Nº de pacotes enviados
Jitter (m
ilisegundos)
LimitedLoss -Wireless2
-500
0
500
1000
1500
2000
2500
3000
3500
1
23
45
67
89
111
133
155
177
199
221
243
265
287
Nº de pacotes enviados
Jitter (m
ilisegundos)
LimitedLoss -Wireless2
-500
0
500
1000
1500
2000
2500
3000
3500
1
68
135
202
269
336
403
470
537
604
671
738
805
872
939
1006
1073
1140
Nº de pacotes enviados
Jitter (m
ilisegundos)
LimitedLoss -Wireless3
-500
0
500
1000
1500
2000
2500
3000
3500
1
23
45
67
89
111
133
155
177
199
221
243
265
287
Nº de pacotes enviados
Jitter (m
ilisegundos)
LimitedLoss -Wireless3
-500
0
500
1000
1500
2000
2500
3000
3500
1
89
177
265
353
441
529
617
705
793
881
969
1057
1145
Nº de pacotes enviados
Jitter (m
ilisegundos)
Figura 31 - Resultados obtidos utilizando o parâmetro de confiabilidade LimitedLoss.
Em relação à taxa de perda de pacotes, para que os resultados sejam considerados
aceitáveis, é necessário que as perdas estejam dentro do valor de 2% . A Tabela 2 mostra os
65
resultados obtidos em relação a perda de pacotes durante a transmissão dos arquivos de 270KB
e 1080KB. Ao transmitir um arquivo de 270KB não ocorreram perdas de pacotes em nenhuma
das máquinas utilizadas. Já ao aumentarmos o tamanho do arquivo transmitido para 1080KB as
taxas alcançaram valores em torno de 5%, que é considerado um valor inaceitável pra
transmissões de vídeo streaming.
Wireless1 Wireless2 Wireless3
LimitedLoss (270KB) 0% 0% 0%
LimitedLoss (1080KB) 5,64% 5,64% 5,03%
Tabela 2 - Taxa de perda de pacotes utilizando parâmetro LimitedLoss.
5.3.2 Cenário nº 2
No segundo cenário o protocolo multicast foi configurado para simular um cenário
confiável, com perdas permitidas (LossAllowed), ou seja independente do tipo de pacote
transmitido a perda é permitida. Desta maneira, o protocolo utiliza a notificação de perda de
pacotes e o controle de congestionamento ao enviar os pacotes e o controle da ordenação dos
pacotes ao recebê-los.
Através da Figura 32 pode-se perceber que a variação do atraso (jitter), na transmissões
dos arquivos de 270KB ficaram dentro do valor aceitável de 2 segundos (2000 milisegundos)
em todas as máquinas. Ao aumentarmos o tamanho do arquivo de transmissão para 1080KB, as
máquinas wireless1 e wireless2 apresentaram resultados aceitáveis, dentro do valor de 2
segundos. Já na máquina wireless3, novamente alguns picos ultrapassaram o valor aceitável de
2 segundos.
66
LossAllowed -Wireless1
-500
0
500
1000
1500
2000
2500
3000
3500
1
23
45
67
89
111
133
155
177
199
221
243
265
287
Nº de pacotes enviados
Jitter (m
ilisegundos)
LossAllowed -Wireless1
-500
0
500
1000
1500
2000
2500
3000
3500
1
68
135
202
269
336
403
470
537
604
671
738
805
872
939
1006
1073
1140
Nº de pacotes enviados
Jitter (m
ilisegundos)
LossAllowed -Wireless2
-500
0
500
1000
1500
2000
2500
3000
3500
1
23
45
67
89
111
133
155
177
199
221
243
265
287
Nº de pacotes enviados
Jitter (m
ilisegundos)
LossAllowed -Wireless2
-500
0
500
1000
1500
2000
2500
3000
3500
1
68
135
202
269
336
403
470
537
604
671
738
805
872
939
1006
1073
1140
Nº de pacotes enviados
Jitter (m
ilisegundos)
LossAllowed -Wireless3
-500
0
500
1000
1500
2000
2500
3000
3500
1
23
45
67
89
111
133
155
177
199
221
243
265
287
Nº de pacotes enviados
Jitter (m
ilisegundos)
LossAllowed -Wireless3
-500
0
500
1000
1500
2000
2500
3000
35001
89
177
265
353
441
529
617
705
793
881
969
1057
1145
Nº de pacotes enviados
Jitter (m
ilisegundos)
Figura 32 - Resultados obtidos utilizando o parâmetro de confiabilidade LossAllowed.
O principal diferencial deste cenário está no fato de que as taxas de perdas de pacotes,
nas máquinas wireless1 e wireless2, se encontraram dentro dos limites aceitáveis de 2% de
perda, como mostram os dados da Tabela 3. Em ambas máquinas as taxas de perdas de pacotes
alcançadas foram de 0,69%, já na máquina wireless3 o resultado superou o limite máximo,
atingindo o valor de 2,25%.
Wireless1 Wireless2 Wireless3
LossAllowed (270KB) 0% 0% 0%
LossAllowed (1080KB) 0,69% 0,69% 2,25%
Tabela 3 - Taxa de perda de pacotes utilizando parâmetro LossAllowed.
67
Apesar da máquina wireless3 ter ultrapassado o limite máximo aceitável para perda de
pacotes, deve-se atentar ao fato de que no cenário anterior o seu desempenho também foi
inferior se comparado às outras duas máquinas, tanto para a taxa de perda de pacotes quanto
para a taxa de variação de atraso. Esses fatos acabam por prover indícios de que a velocidade
do barramento poderá estar afetando os resultados obtidos.
5.3.3 Cenário nº 3
No terceiro cenário o protocolo multicast foi configurado para simular um cenário
confiável, sem permitir perdas de pacotes (NoLoss). Desta maneira o protocolo também utiliza
a notificação de perda de pacotes, o controle de congestionamento ao enviá-los e o controle da
ordenação dos pacotes ao recebê-los.
Através da Figura 33 pode-se perceber que a variação do atraso (jitter), nas
transmissões envolvendo o arquivo de 270KB ficou dentro do valor aceitável de 2 segundos
(2000 milisegundos) em todas as máquinas. Ao aumentarmos o tamanho do arquivo de
transmissão para 1080KB, as taxas de perdas de pacotes em todas as máquinas ultrapassaram o
limite aceitável de 2 segundos.
Novamente pode-se perceber que os resultados obtidos na máquina wireless3 destoam
se comparados aos resultados das máquinas wireless1 e wireless2. Além de apresentar maior
número de picos, os valores alcançados por eles também são superiores.
68
NoLoss -Wireless1
-500
0
500
1000
1500
2000
2500
3000
3500
1
23
45
67
89
111
133
155
177
199
221
243
265
287
Nº de pacotes enviados
Jitter (m
ilisegundos)
NoLoss -Wireless1
-500
0
500
1000
1500
2000
2500
3000
3500
1
68
135
202
269
336
403
470
537
604
671
738
805
872
939
1006
1073
1140
Nº de pacotes enviados
Jitter (m
ilisegundos)
NoLoss -Wireless2
-500
0
500
1000
1500
2000
2500
3000
3500
1
23
45
67
89
111
133
155
177
199
221
243
265
287
Nº de pacotes enviados
Jitter (m
ilisegundos)
NoLoss -Wireless2
-500
0
500
1000
1500
2000
2500
3000
3500
1
68
135
202
269
336
403
470
537
604
671
738
805
872
939
1006
1073
1140
Nº de pacotes enviados
Jitter (m
ilisegundos)
NoLoss -Wireless3
-500
0
500
1000
1500
2000
2500
3000
3500
1
23
45
67
89
111
133
155
177
199
221
243
265
287
Nº de pacotes enviados
Jitter (m
ilisegundos)
NoLoss -Wireless3
-500
0
500
1000
1500
2000
2500
3000
35001
89
177
265
353
441
529
617
705
793
881
969
1057
1145
Nº de pacotes enviados
Jitter (m
ilisegundos)
Figura 33 - Resultados obtidos utilizando o parâmetro de confiabilidade NoLoss.
Em relação à taxa de perda de pacotes, os resultados obtidos neste cenário foram os
piores, se comparados aos cenários anteriores. Através da Tabela 4 é possível verificar que as
taxas de perdas de pacotes alcançaram valores de 21% ao transmitir arquivos de 1080KB, ou
seja, bem maiores do que o limite máximo esperado.
Wireless1 Wireless2 Wireless3
NoLoss (270KB) 0% 0% 0%
NoLoss (1080KB) 21,45% 20,85% 21,44%
Tabela 4 - Taxa de perda de pacotes utilizando parâmetro NoLoss.
Neste caso fica nítido que o tamanho do buffer utilizado para se realizar a retransmissão
de pacotes perdidos não foi suficientemente grande para prover o reenvio dos mesmos.
69
5.3.4 Cenário nº 4
No quarto e último cenário proposto, o protocolo multicast foi configurado para simular
um cenário não confiável, ou seja, para trabalhar ao melhor esforço ou best effort. Neste
contexto é possível tornar o protocolo mais rápido, permitindo alcançar taxas de transmissões
maiores, pois não usa qualquer tipo de controle de fluxo ou de congestionamento.
A partir da Figura 34 é possível verificar que realmente as menores variações de atraso
foram encontradas neste cenário, durante as transmissões de arquivos de 270KB. Em seus
piores momentos, os picos alcançaram valores de 0,5 segundos, o que significa um ótimo
resultado. Porém as taxas de perdas de pacotes alcançaram valores de 13,58% como mostra a
Tabela 5.
BestEffort -Wireless1
-500
0
500
1000
1500
2000
2500
3000
3500
1
23
45
67
89
111
133
155
177
199
221
243
265
287
Nº de pacotes enviados
Jitter (m
ilisegundos)
BestEffort -Wireless1
-500
0
500
1000
1500
2000
2500
3000
3500
1
68
135
202
269
336
403
470
537
604
671
738
805
872
939
1006
1073
1140
Nº de pacotes enviados
Jitter (m
ilisegundos)
BestEffort -Wireless2
-500
0
500
1000
1500
2000
2500
3000
3500
1
23
45
67
89
111
133
155
177
199
221
243
265
287
Nº de pacotes enviados
Jitter (m
ilisegundos)
BestEffort -Wireless2
-500
0
500
1000
1500
2000
2500
3000
3500
1
68
135
202
269
336
403
470
537
604
671
738
805
872
939
1006
1073
1140
Nº de pacotes enviados
Jitter (m
ilisegundos)
BestEffort -Wireless3
-500
0
500
1000
1500
2000
2500
3000
3500
1
23
45
67
89
111
133
155
177
199
221
243
265
287
Nº de pacotes enviados
Jitter (m
ilisegundos)
BestEffort -Wireless3
-500
0
500
1000
1500
2000
2500
3000
3500
1
89
177
265
353
441
529
617
705
793
881
969
1057
1145
Nº de pacotes enviados
Jitter (m
ilisegundos)
Figura 34 - Resultados obtidos utilizando o parâmetro de confiabilidade BestEffort.
70
Ao aumentarmos o tamanho do pacote para 1080KB é possível verificar que em alguns
momentos a variação do atraso ultrapassou o limite de 2 segundos alcançando valores de 2,5
segundos. Além disso, as taxas de perda de pacotes continuaram altas, em torno de 11% o que
torna a utilização deste cenário inviável para a transmissão de fluxos contínuos.
Wireless1 Wireless2 Wireless3
BestEffort (270KB) 13,58% 13,58% 13,58%
BestEffort (1080KB) 11,38% 11,12% 11,38%
Tabela 5 - Taxa de perda de pacotes utilizando parâmetro BestEffort.
5.4 Conclusão
Neste capítulo foram apresentados quatro diferentes cenários onde foram realizados
alguns experimentos. Em cada cenário proposto foram variados os parâmetros de
confiabilidade (BestEffort, Adapted Throughput) e de controle de fluxo(LimitedLoss,
LossAllowed, NoLoss) do protocolo multicast, na tentativa de avaliar o cenário mais adequado
para realizar as transmissões. Nos três primeiros cenários foram utilizadas taxas de
transmissões adaptativas que variaram de 64kbits/s à 128kbit/s e buffers com tamanho de
256KB. Em todos os cenários foram utilizados arquivos de tamanhos diferentes (270KB e
1080KB) para avaliar o impacto do tamanho dos arquivos nas transmissões.
No cenário nº 1 foi proposta a utilização do protocolo multicast configurado para simular
um cenário confiável, porém com perdas limitadas. Apesar da variação do atraso não ter
ultrapassado o valor de 2 segundos e das taxas de perdas de pacotes terem sido nulas, na
transmissão do arquivo de 270KB, este cenário é considerado inadequado, pois ao se aumentar
o tamanho do arquivo transmitido, as taxas de perdas de pacotes ultrapassaram o valor limite
de 2% de perda.
No cenário nº 2 foi proposta a utilização do protocolo multicast configurado para simular
um cenário confiável, porém com perdas permitidas. Neste caso o cenário é considerado
adequado, visto que em todas as simulações onde foram utilizadas as placas PCI os resultados
obtidos não ultrapassaram os valores limítrofes aceitáveis.
No cenário nº 3 foi proposta a utilização do protocolo multicast configurado para simular
um cenário confiável, porém sem permitir perdas. Neste cenário verificou-se que o tamanho do
71
buffer utilizado não estava suficientemente grande para prover a recuperação dos pacotes
perdidos. A conseqüência disso foi à obtenção de taxas de perdas de pacotes dez vezes maior
que o limite estabelecido. Isso invalidou a utilização deste cenário, pois os resultados
apresentados são considerados inviáveis para a transmissão de fluxos contínuos.
Já no quarto e último cenário foi proposta a utilização do protocolo multicast configurado
para simular um cenário não confiável, ou seja, ao melhor esforço. Em todas as simulações
realizadas neste cenário, utilizando arquivos com 270KB, os resultados obtidos em relação ao
jitter foram aceitáveis, porém as taxas de perda de pacotes alcançaram valores de 13%. Ao
aumentar o tamanho do arquivo transmitido os resultados em relação ao jitter ultrapassaram os
valores limítrofes e as taxas de perdas continuaram inaceitáveis.
Portanto, apesar do cenário de melhor esforço propiciar condições para que a taxa de
transmissão alcançasse valores mais altos, verificou-se que o mesmo apresentou um péssimo
desempenho em relação à perda de pacotes. Indiferentemente ao tamanho do arquivo, o seu
desempenho não foi suficiente para atender os requisitos mínimos de qualidade de serviço das
transmissões de fluxos contínuos de dados.
Dentro dos cenários propostos e analisados, o único cenário que apresentou resultados
aceitáveis para transmissões de arquivos de vídeo foi o de número 2.
Ficou claro que este trabalho não pretende esgotar as discussões sobre o assunto, visto
que outras taxas de transmissões e diferentes tamanhos de buffer poderão ser utilizados, além
da possibilidade de se avaliar e discutir a utilização de outros parâmetros de QoS . Além disso,
outros modelos poderão ser sugeridos, com diferentes adaptações, utilizando diferentes
protocolos multicast para serem avaliados.
72
6 Conclusões Gerais
Através deste trabalho foi possível não só validar as adaptações realizadas no modelo
proposto, assim como analisar os resultados obtidos. A maior contribuição deste trabalho está
justamente nos resultados que foram obtidos e analisados a partir das simulações realizadas.
Apesar de ter obtido um valor ideal em termos de jitter e perda de pacotes, ainda não se
conseguiu avaliar o modelo em relação ao atraso total da transmissão. Para isso seria
necessário que as máquinas, as quais estavam sendo utilizadas para colher os resultados,
estivessem com relógios sincronizados.
Porém, para realizar o cálculo do atraso entre pacotes consecutivos (jitter), foi necessário
capturar o tempo em que os pacotes foram sendo recebidos. Com estes dados foi possível
calcular o tempo total desde a chegada do primeiro pacote até a chegada do último pacote.
Percebeu-se então que os tempos colhidos estavam um pouco altos, e provavelmente não
atenderiam os requisitos de atraso.
Como descrito no Capítulo3, vários fatores são descritos como complicadores em uma
transmissão de fluxo contínuo em redes sem fio, assim como a configuração das máquinas
utilizadas durante as simulações. Portanto novos cenários poderão ser propostos e analisados
detalhadamente.
6.1 Trabalhos Futuros
Como descrito no item anterior, através das simulações realizadas foi possível capturar e
analisar os dados referentes a alguns parâmetros de qualidade de serviço. O ideal seria, além de
analisar o jitter e a taxa de perda de pacotes, também colher resultados para o cálculo do atraso
total da transmissão. Portanto um dos trabalhos futuros seria justamente a utilização de
mecanismos para prover a sincronização das máquinas utilizadas e assim colher os resultados
para o cálculo do atraso total da transmissão.
Além disso, várias outras simulações poderiam ser realizadas na tentativa de se encontrar
valores ideais em relação aos requisitos de qualidade de serviço. Para isso poderiam ser
utilizados pacotes de dados com tamanhos um pouco maiores que os utilizados neste trabalho,
pois como visto no Capítulo3, o tamanho dos pacotes transmitidos tem uma ligação direta com
o desempenho do sistema.
73
Uma outra proposta seria a utilização de diferentes protocolos de comunicação de grupo,
como os protocolos semi-confiáveis (BORTOLETO, 2005) para a análise de desempenho da
aplicação.
Caso os resultados obtidos em relação ao atraso total da transmissão também não sejam
aceitáveis, vários métodos e políticas de adaptação podem ser propostos e analisados em
detalhe.
74
7 Referências
AMORIN, G. F. Análise de Desempenho de Protocolos de Roteamento com Diferenciação de Serviços em Redes de Comunicação Móvel AD-HOC. Rio de Janeiro, RJ. Originalmente apresentada como dissertação de mestrado, Instituto Militar de Engenharia, 2002. ARAÚJO, F.; RODRIGUES, L. Quality of Service in Indirect Communication Systems. In: Fourth European Research Seminar on Advances in Distributed Systems (ERSADS'01). Bertinoro – Itália. Maio, 2001. Disponível em: <http://citeseer.ist.psu.edu/442144.html>. Acesso em: 01 fev. 2006. ARBAUGH, W. An Initial Security Analysis of the IEEE 802.1X protocol. Fevereiro, 2002. Disponível em: <http://www.cs.umd.edu/~waa/wireless.html>. Acesso em: 01 fev. 2006. BARBOSA, R. S. B. G. Calculando Métricas Unidirecionais na Internet. Março, 2005. Disponível em: <http://www.cin.ufpe.br/~tg/2004-2/rsbgb.pdf>. Acesso em: 01 fev.2006. BARCELLOS, M.; ROESLER V. M&M Multicasting and Multimídia. In: XX Congresso da Sociedade Brasileira de Computação (SBC2000). Julho, 2000. Disponível em: <http://www.inf.unisinos.br/~marinho/Research/Archive/SBC-JAI2000-multicast-multimidia.pdf>. Acesso em: 01 abr. 2006. BORISOV, N.; GOLDBERG, I.; WAGNER, D. Intercepting Mobile Communications: The Insecurity of 802.11. In Proceedings of ACM MOBICOM. Janeiro, 2001. Disponível em: <http://citeseer.ist.psu.edu/borisov01intercepting.html>. Acesso em: 02 fev. 2006. BORTOLETO, C. M.; LUNG, L. C.; SIQUEIRA, F. A.; BESSANI, A. N.; FRAGA, J. S. Um Protocolo de Multicast Semi-confiável para Aplicações Multimídia Distribuídas em Redes de Larga Escala. In: XXXII Seminário Integrado de Software e Hardware – Congresso da Sociedade Brasileira de Computação. São Leopoldo – RS, Julho, 2005. Disponível em:< http://bibliotecadigital.sbc.org.br >. Acesso em: 04 maio 2006. CARRIÓN, D. S. D. AirStrike: Uma implementação de segurança para redes IEEE 802.11b. Apresentado na Primeira Semana da Eletrônica – UFRJ. Dezembro, 2003. Disponível em: <http://www.ravel.ufrj.br/>. Acesso em: 23 jan. 2006. CARVALHO N.; ARAÚJO F.; RODRIGUES L. IndiQoS: um Sistema Publicação-Subscrição com Qualidade de Serviço. Originalmente apresentada como dissertação de mestrado, Universidade de Lisboa, Portugal. Janeiro, 2005. Disponível em: <http://www.di.fc.ul.pt/tech-reports/05-1.pdf>. Acesso em: 03 mar. 2006.
CARZANIGA, A.; DI NITTO, E.; ROSENBLUM, D. S.; WOLF A. L., Issues in Supporting Event-based Architectural Styles. In 3rd International Software Architecture Workshop, Orlando, USA. Nov., 1998a.
CARZANIGA, A. Architectures for an Event Notification Service Scalable to Wide-area Networks. 115 f. Originalmente apresentada como tese de doutorado, Politecnico de Milano, Milão, 1998b.
75
CARZANIGA, A.; ROSENBLUM, D. S.; WOLF, A. L. Achieving scalability and expressiveness in an internet-scale event notification service. In: 19th ACM Symposium on Principles of Distributed Computing, New York, USA. Jul., 2000.
COMER, D.E. Interligação em Redes com TCIP/IP. 3. ed. Rio de Janeiro: Editora Campus Ltda, 1998. ISBN: 85-352-0270-6.
CONCEIÇÃO, A. F.; KON, F. Adaptação de fluxos contínuos UDP sobre redes IEEE 802.11b. In: V Workshop de Comunicação sem Fio e Computação Móvel (WCSF), São Lourenço-MG, Brasil, 2003.
CUGOLA, G.; JACOBSEN, H. A. Using Publish/Subscribe Middleware for Mobile Systems. ACM SIGMOBILE Mobile Computing and Communications Rev., 6(4): p. 25 - 33, 2002.
CUGOLA, G.; NITTO E. D.; FUGGETA A. The JEDI event-based infrastructure and its application to the development of the OPSS WFMS. In: IEEE Transactions on Software Engineering, p. 827-850. Sept., 2001.
DEQUECH, A. Adaptação de Sistemas Publish/Subscribe para Ambientes Móveis. Originalmente apresentada como dissertação de mestrado, Universidade Tecnológica Federal do Paraná, Curitiba, PR, 2003. ETSI - EUROPEAN TELECOMMUNICATIONS STANDARDS INSTITUTE. Quality of Service, concept and architectur v. 6.2.0 p.1-43. Dezembro, 2004. Disponível em: <http://www.etsi.org>. Acesso em: 01 fev. 2006.
EUGSTER, P. T.; GUERRAOUI, R.; SVENTEK, J. Type-Based Publish/Subscribe. Technical Report TR-DSC-2000-029, Swiss Federal Institute of Technology, Lausanne. Jun., 2000.
EUGSTER, P. T.; GUERRAOUI, R. The Many Faces of Publish/Subscribe. Technical Report – DSC ID: 200105. Jan., 2001.
GAST, M. S. 802.11 Wireless Networks: The Definitive Guide. 1. ed. USA: O’Reilly Associates, 2002.
GEOFFREY, C. F.; WU, W.; UYAR A. Design and Implementation of Audio/Video Collaboration System. In: Proceedings of 2002 IEEE International Conference on Image Processing, vol. 2, 2002. GRUBER, R.; KRISHNAMURTHY, B.; PANAGOS, E. The architecture of the ready event notification service. In: Proceedings of the 19th IEEE International Conference on Distributed Computing Systems Middleware Workshop, 1999.
GUPTA, A.; SAHIN O. D.; AGRAWAL, D.; ABBADI, A. E. Meghdoot: content-based publish/subscribe over p2p networks. In Proceedings of the 5th ACM/IFIP/USENIX international conference on Middleware, pages 254–273, New York, NY, USA, 2004.
HUANG, Y.; GARCIA-MOLINA, H. Publish/Subscribe in a Mobile Environment. MobiDE 2001, Second ACM International Workshop on Data Engineering for Wireless and Mobile Access, Santa Barbara, Califórnia, USA. May, 2001.
76
IEEE - INSTITUTE OF ELECTRICAL AND ELETRONICS ENGINEERS. IEEE 802.11 Standard Interpretations. Disponível em: <http://grouper.ieee.org/groups/802/11/>. Maio, 2001.
ISO - INTERNATIONAL ORGANIZATION FOR STANDARDIZATION. Quality of service basic framework – outline. ISO / IEC JTC1 / SC21 / WG1 N1145, 1994.
JMS - JAVA MESSAGE SERVICE. Java Message Service Tutorial. 2003 Disponível em: <http://java.sun.com/products/jms/tutorial/>. Acesso em: 04/02/2006. J2EE - JAVA PLATAFORM ENTERPRISE EDITION. Java(TM) 2 Platform, Enterprise Edition Specification 1.3 Final Release. 2003 Disponível em: < http://java.sun.com/j2ee/1.3/docs/index.html >. Acesso em: 23/01/2006.
LIAO, T. Light-weight Reliable Multicast Protocol. Technical Report. Outubro 1998. Disponível em: <http://ietfreport.isoc.org/idref/draft-liao-lrmp/>. Acesso em: 04/02/2006. MÜHL, G.; ULBRICH, A.; HERRMANN, K.; WEIS, T. Disseminating information to mobile clients using publish-subscribe. IEEE Internet Computing, 8(3):46–53, May, 2004. NUMAZAKI, E.; WAENY, J. C. Java Message Service Teoria e Prática. Florianópolis –SC: Visual Books Editora, 2004. 158 p., 23 cm. ISBN: 85-7502-151-6. ORVALHO, J. Extensões ao CORBA Event Service para Comunicação Confiável Multicast. Disponível em: <http://www.cisuc.uc.pt/lct/publications.php>. Acesso em: 23 jan. 2006. PASSMORE, D. Delayed Voice-over-IP. Business Communications Review. Dezembro, 1997. Disponível em: <http://www.educause.edu/ir/library/html/cnc9802/cnc9802.html>. Acesso em: 01 abr. 2006. PERKINS, C. E. IP Mobility Support, RFC 2002. Outubro, 1996. Disponível em: <ftp://ftp.rfc-editor.org/in-notes/pdfrfc/rfc2002.txt.pdf>. Acesso em: 04 fev. 2006. PERKINS, C. E. IP Mobility Support for Ipv4, RFC3220. Janeiro, 2002a. Disponível em: <ftp://ftp.rfc-editor.org/in-notes/rfc3220.txt>. Acesso em: 23 jan. 2006. PERKINS, C. E. IP Mobility Support for Ipv4, RFC3344. Agosto, 2002b. Disponível em: <ftp://ftp.rfc-editor.org/in-notes/rfc3344.txt>. PIETZUCH, P. R. A Scalable Event-Based Middleware. Technical Report, University of Tennessee, Knoxville, TN. Junho, 2004. Disponível em: <http://citeseer.ist.psu.edu/689877.html>. Acesso em: 04 mar. 2006.
SANTANA, A. A.; CARVALHO, T. C. M. B. Proposta para otimização de desempenho do protocolo TCP em redes sem fio 802.11. Apresentado no Simpósio Brasileiro de Redes de Computadores (SBRC), Gramado, RS, Maio 2004, pp. 563–566, artigo curto. SOCKETS. All about Sockets. Novembro, 2003. Disponível em: <http://java.sun.com/docs/books/tutorial/networking/sockets/index.html>. Acesso em: 23 jan. 2006.
77
SEGALL, B.; ARNOLD, D. Elvin has left the building: A publish/subscribe notification service with quenching. In: Proceedings of the 1997 Australian UNIX users Group Technical Conference, 1997, p. 243-255. SILVA, L. A.; DUARTE, O. C. M. B. RADIUS em Redes sem Fio. Setembro, 2003. Disponível em: <http://www.gta.ufrj.br/~lafs/arqs/>. Acesso em: 23 jan. 2006. TAVARES, H.; FARRAPOSO, S. Public Key Port 802.11. Setembro, 2002. Disponível em: <http://www.fccn.pt/crc2002/v2/pdfs/poster09.pdf>. Acesso em: 23 jan. 2006. VOLLSET, E.; INGHAM, D.; EZHILCHELVAN, P. JMS on Mobile Ad-hoc Networks. 2000. In: Proceedings of 8th International Conference, PWC 2003, Venice, Italy, September 23-25, 2003. WALKER, J. R. Unsafe at any key size; an analysis of the WEP encapsulation. Technical Report 036288E, IEEE 802.11 Committee, Março 2000. Disponível em: <http://www.dis.org/wl/pdf/unsafe.pdf>. Acesso em: 04 mar. 2006. WOLLRATH, A.; WALDO, J. Trail: RMI. 2003. Disponível em: <http://java.sun.com/docs/books/tutorial/rmi/index.html>. Acesso em: 23 jan. 2006. YONEKI, E.; BACON, J. Pronto Mobile Gateway with publish-subscribe paradigm over wireless network. Technical Report UCAM-CL-TR-559, Computer Laboratory, University of Cambridge. Junho, 2003. Disponível em: <http://citeseer.ist.psu.edu/yoneki03pronto.html>. Acesso em: 23 jan. 2006. ZIEBA, B.; SINDEREN, M. V.; WEGDAM, M. Quality-Constrained Routing in Publish/Subscribe Systems. In: ACM International Conference Proceeding Series; Vol. 115, Proceedings of the 3rd International workshop on Middleware for pervasive and ad-hoc Computing, Grenoble, France, 2005.