Adaptação e Análise de um Sistema Publish/Subscribe para
Transcrição
Adaptação e Análise de um Sistema Publish/Subscribe para
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ósGraduaçã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 "A mente que se abre a uma nova idéia jamais voltará ao seu tamanho original”. Albert Einstein iii 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. iv 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 v 4 5 6 7 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 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 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 Conclusões Gerais................................................................................................................72 6.1 Trabalhos Futuros..........................................................................................................72 Referências...........................................................................................................................74 vi Í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 vii Í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 viii 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 ix 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 x 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. xi 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. xii 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 baseiase 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 Subscrição Publicação Subscriber Notificações Publisher Serviço de Notificação Subscriber Objetos Administrativos Publisher Subscriber 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. Serviço de Notificação Publisher Publish t i fy No Notify No t i fy Subscriber Notify() Subscriber Notify() Subscriber Notify() 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 Serviço de Notificação Publisher 2) Publisher Subscriber Notify() Publish Serviço de Notificação Notify Tempo 1) Subscriber Notify() 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). Subscriber Publisher Notify() Publish Serviço de Notificação ify Not 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 infraestrutura. 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 Quadros Beacon PA 1 PA 2 Dispositivo Móvel Encontrou: * PA 1 * PA 2 * PA 3 PA 3 PA 4 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). DIFS SIFS Probe Request DIFS SIFS ACK ACK Estação Móvel Probe Request Ponto de Acesso 1 Probe Request Ponto de Acesso 2 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 Autenticação Desautenticação Estado 2 Autenticado e Não Associando Associação ou Reassociação Desassociação Estado 3 Autenticado e Associando 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 de Autenticação no 802.11 Sem Criptografia Baseado na Identidade Sistema de Autenticação Aberto A comunicação é permitida se o SSID estiver vazio Com Criptografia Baseado na Resposta do Desafio Sistema de Autenticação Fechado A comunicação é permitida se o SSID for informado A comunicação é permitida ao provar que a chave WEP está compartilhada 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. Cliente Autenticador 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 TkA o instante de saídas de dois pacotes consecutivos i e k marcados no relógio de A e sejam T iB e TkB 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 - di 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 - TkA + εk ) – ( T iB - TiA + εi ) εk ≅ ε i Tem-se, portanto que: dvik =( TkB - TkA ) – ( T iB - TiA ) 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 temse 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 INTERNET ROTEADOES REDE LOCAL GATEWAY WIRELESS P.A. P.A. 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. subscriber publisher MSS Rede wireless Coordenador Aplicação Infra-estrutura de publish/subscribe Rede fixa Infra-estrutura de rede gateway wireless 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 interface_MSS core_pub/sub interface_Publisher 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. interface_Wireless core_MSS Figura 15 - Estrutura do MSS interface_Coord 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 infraestrutura 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() join_Group(id_Coord) GROUP PROTOCOL start(id_Coord) cad_MSS(id_MSS) save_MSS(id_MSS) ack_Coord() 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 podese 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 Produtor de Mensagem Recebimento Envio JMS Provider Consumidor de Mensagens Confirmação Confirmação Armazenar Remover Disco 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. P ro d u to r d e M ensagem E n vio C on firm aç ã o R ec eb im en to J M S P rov ider C o n s u m id o r d e M ensagens C on firm 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. 3 Ponto de Acesso 2 Ponto de Acesso 1 Ponto de Acesso Dispositivo Móvel Send_Beacon_Frames( param ) Send_Beacon_Frames( param ) Send_Beacon_Frames( param ) Keep_List() Analise_Frames() Joining( param ) Request_Authentication(authent, sequence) Response_Authentication(authent, sequence, status, challenge) Response_Chalenge(authent, sequence, challenge) Decrypt_Challenge(authent, sequence, satus) 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. BD_Subscriber Subscriber MSS Coordenador 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_MSS( id_MSS,id_Sub, id_Coord) ACK_Coord(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) Request_Validate(id_publisher) Response_Validate(token) Response_Connection(token) Publish(event) Send(event) PROTOCOLO DE GRUPO Receive(event) 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. Subscriber BD_MSS MSS Coordenador BD_Coordenador 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. BD_Subscriber Subscriber MSS Coordenador BD_Coordenador 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 BD_Coordenador timer() Request_Events() Response_Events() send_MSS(event,id_Sub) 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_Adress() Response_Address(id_Sub) Request_New(id_Sub[]) Ponto de Acesso Wireless Response_New(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 BD_Subscriber MSS Coordenador 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_Coordenador Old_Coordenador BD_Old_Coordenador If (id_Coord = id_oldCoord) update_MSS(id_Sub, id_MSS) Else update_Subscriber(subscription, id_Sub, id_MSS) cancel_Subscription(id_Sub) Request_Events() Request_Buffer( id_Sub) Response_Buffer(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 Unsub_MSS(subscription, id_Sub, id_MSS, id_Coord) Unsubs_Coord(subscription, id_Sub, id_MSS, id_Coord) Delete_Buffer() Save_Unsub(subscription, id_Sub, id_MSS, id_Coord) 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 (infraestruturada), 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. w ire le s s 4 P o n to d e A c e s s o w ire le s s 1 w ire le s s 2 w ire le s s 3 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 -AMD Athlon 2400 com -Pentium(4) 3.2GHz -Pentium(4) 3.4GHz com 512MB de 512MB de memória e com 512MB de com 512MB de memória e placa de placa de rede wireless memória e antenas D- memória e antenas rede wireless D-Link D-Link padrão PCI. Link padrão USB 2.0 D-Link padrão USB Hardware -AMD Athlon 2400 2.0 padrão PCI. Software Wireless4 -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 3500 3000 3000 500 3000 Nº de pacotes enviados 1073 1140 1140 939 1006 1006 1073 872 939 738 805 805 738 671 604 500 1145 1057 969 881 793 705 617 0 -500 529 287 265 243 221 199 177 155 133 89 0 1000 441 500 1500 353 1000 2000 265 1500 2500 89 2000 177 2500 1 Jitter (milisegundos) 3500 111 537 LimitedLoss -Wireless3 3000 67 470 Nº de pacotes enviados 3500 45 403 0 -500 LimitedLoss -Wireless3 23 671 500 336 287 265 243 221 199 177 155 133 89 111 67 45 23 0 1000 269 500 1500 202 1000 2000 135 1500 2500 1 2000 68 2500 1 872 3000 Jitter (milisegundos) 3500 3000 Nº de pacotes enviados Jitter (milisegundos) 604 LimitedLoss -Wireless2 3500 1 Jitter (milisegundos) LimitedLoss -Wireless2 -500 537 Nº de pacotes enviados Nº de pacotes enviados -500 470 0 -500 403 287 265 243 221 199 177 155 133 89 111 67 45 -500 23 0 1000 336 500 1500 269 1000 2000 202 1500 2500 135 2000 1 2500 68 Jitter (milisegundos) 3500 1 Jitter (milisegundos) LimitedLoss -Wireless1 Nº de pacotes enviados 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 3500 3000 3000 500 3000 1073 1073 1140 939 1006 1006 872 939 738 805 1140 805 738 671 604 500 1145 1057 969 881 793 705 617 0 -500 529 287 265 243 221 199 177 155 133 89 0 1000 441 500 1500 353 1000 2000 265 1500 2500 177 2000 1 2500 89 Jitter (milisegundos) 3500 111 537 LossAllowed -Wireless3 3000 67 470 Nº de pacotes enviados 3500 45 403 0 -500 LossAllowed -Wireless3 23 671 500 336 287 265 243 221 199 177 155 133 89 111 67 45 23 0 1000 269 500 1500 202 1000 2000 135 1500 2500 1 2000 68 2500 1 872 3000 Jitter (milisegundos) 3500 3000 Nº de pacotes enviados Jitter (milisegundos) 604 LossAllowed -Wireless2 3500 1 Jitter (milisegundos) LossAllowed -Wireless2 -500 537 Nº de pacotes enviados Nº de pacotes enviados -500 470 0 -500 403 287 265 243 221 199 177 155 133 89 111 67 45 -500 23 0 1000 336 500 1500 269 1000 2000 202 1500 2500 135 2000 1 2500 68 Jitter (milisegundos) 3500 1 Jitter (milisegundos) LossAllowed -Wireless1 Nº de pacotes enviados Nº de pacotes enviados 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 3500 3000 3000 500 3000 1073 1140 1140 939 1006 1006 1073 872 939 738 805 805 738 671 604 500 1145 1057 969 881 793 705 617 0 -500 529 287 265 243 221 199 177 155 133 89 0 1000 441 500 1500 353 1000 2000 265 1500 2500 177 2000 1 2500 89 Jitter (milisegundos) 3500 111 537 NoLoss -Wireless3 3000 67 470 Nº de pacotes enviados 3500 45 403 0 -500 NoLoss -Wireless3 23 671 500 336 287 265 243 221 199 177 155 133 89 111 67 45 23 0 1000 269 500 1500 202 1000 2000 135 1500 2500 1 2000 68 2500 1 872 3000 Jitter (milisegundos) 3500 3000 Nº de pacotes enviados Jitter (milisegundos) 604 NoLoss -Wireless2 3500 1 Jitter (milisegundos) NoLoss -Wireless2 -500 537 Nº de pacotes enviados Nº de pacotes enviados -500 470 0 -500 403 287 265 243 221 199 177 155 133 89 111 67 45 -500 23 0 1000 336 500 1500 269 1000 2000 202 1500 2500 135 2000 1 2500 68 Jitter (milisegundos) 3500 1 Jitter (milisegundos) NoLoss -Wireless1 Nº de pacotes enviados Nº de pacotes enviados 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 3500 3000 3000 500 3000 Nº de pacotes enviados 1073 1140 1140 939 1006 1006 1073 872 939 738 805 805 738 671 604 500 Nº de pacotes enviados Figura 34 - Resultados obtidos utilizando o parâmetro de confiabilidade BestEffort. 1145 1057 969 881 793 705 617 0 -500 529 287 265 243 221 199 177 155 133 89 0 1000 441 500 1500 353 1000 2000 265 1500 2500 177 2000 1 2500 89 Jitter (milisegundos) 3500 111 537 BestEffort -Wireless3 3000 67 470 Nº de pacotes enviados 3500 45 403 0 -500 BestEffort -Wireless3 23 671 500 336 287 265 243 221 199 177 155 133 89 111 67 45 23 0 1000 269 500 1500 202 1000 2000 135 1500 2500 1 2000 68 2500 1 872 3000 Jitter (milisegundos) 3500 3000 Nº de pacotes enviados Jitter (milisegundos) 604 BestEffort -Wireless2 3500 1 Jitter (milisegundos) BestEffort -Wireless2 -500 537 Nº de pacotes enviados Nº de pacotes enviados -500 470 0 -500 403 287 265 243 221 199 177 155 133 89 111 67 45 -500 23 0 1000 336 500 1500 269 1000 2000 202 1500 2500 135 2000 1 2500 68 Jitter (milisegundos) 3500 1 Jitter (milisegundos) BestEffort -Wireless1 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-multicastmultimidia.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çãoSubscriçã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 <http://java.sun.com/docs/books/tutorial/rmi/index.html>. Acesso em: 23 jan. 2006. em: 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.