MINISTÉRIO DA DEFESA EXÉRCITO BRASILEIRO
SECRETARIA DE CIÊNCIA E TECNOLOGIA INSTITUTO MILITAR DE ENGENHARIA
CURSO DE MESTRADO EM SISTEMAS E COMPUTAÇÃO
WELSING MOREIRA PEREIRA
EMPREGO DE PROTOCOLOS MULTICAST NA CAMADA DE APLICAÇÃO NO SUPORTE A AMBIENTES VIRTUAIS COLABORATIVOS
Rio de Janeiro 2006
Livros Grátis
http://www.livrosgratis.com.br
INSTITUTO MILITAR DE ENGENHARIA
WELSING MOREIRA PEREIRA
EMPREGO DE PROTOCOLOS MULTICAST NA CAMADA DE
APLICAÇÃO NO SUPORTE A AMBIENTES VIRTUAIS
COLABORATIVOS
Dissertação de Mestrado apresentada ao Curso de Mestrado em Sistemas e Computação do Instituto Militar de Engenharia, como requisito parcial para a obtenção do título de Mestre em Ciências em Sistemas e Computação.
Orientador: Prof. Paulo Cesar Salgado Vidal – D. Sc. Co-orientador: Prof. Jauvane C. de Oliveira – Ph.D.
Prof. Artur Ziviani – Docteur
Rio de Janeiro 2006
C2006
INSTITUTO MILITAR DE ENGENHARIA Praça General Tibúrcio, 80 – Praia Vermelha Rio de Janeiro - RJ CEP: 22290-270
Este exemplar é de propriedade do Instituto Militar de Engenharia, que poderá incluí-lo em base de dados, armazenar em computador, microfilmar ou adotar qualquer forma de arquivamento.
É permitida a menção, reprodução parcial ou integral e a transmissão entre bibliotecas deste trabalho, sem modificação de seu texto, em qualquer meio que esteja ou venha a ser fixado, para pesquisa acadêmica, comentários e citações, desde que sem finalidade comercial e que seja feita a referência bibliográfica completa.
Os conceitos expressos neste trabalho são de responsabilidade do(s) autor(es) e do(s) orientador(es).
004.62 Pereira, Welsing Moreira
P436e Emprego de Protocolos Multicast na Camada de Aplicação no Suporte a Ambientes Virtuais Colaborativos / Welsing Moreira Pereira. - Rio de Janeiro : Instituto Militar de Engenharia, 2006.
133 p. : il., tab.
Dissertação (mestrado) - Instituto Militar de Engenharia, Rio de Janeiro, 2006.
1. Protocolos Multicast. 2. Ambientes Virtuais Colaborativos. I. Título. II. Instituto Militar de Engenharia.
INSTITUTO MILITAR DE ENGENHARIA
WELSING MOREIRA PEREIRA
EMPREGO DE PROTOCOLOS MULTICAST NA CAMADA DE APLICAÇÃO NO SUPORTE A AMBIENTES VIRTUAIS COLABORATIVOS
Dissertação de Mestrado apresentada no Curso de Mestrado em Sistemas e Computação do Instituto Militar de Engenharia, como requisito parcial para a obtenção do título de Mestre em Ciências em Sistemas e Computação.
Orientador: Prof. Paulo César Salgado Vidal – D.Sc.
Co-orientador(es): Prof. Jauvane Cavalcante de Oliveira – Ph.D. Prof. Artur Ziviani – Docteur.
Aprovada em 08 de Agosto de 2006 pela seguinte Banca Examinadora:
_______________________________________________________________ Prof. Jauvane Cavalcante de Oliveira – Ph.D. do LNCC - Presidente
_______________________________________________________________ Prof Artur Ziviani – Docteur do LNCC
_______________________________________________________________ Profa. Debora Christina Muchaluat Saade - D.Sc. da UFF
_______________________________________________________________ Prof. Edison Ishikawa – D.Sc. do IME
Rio de Janeiro 2006
A minha esposa e companheira Silviane, ao meu filho Yago Welsing e a todos que me deram apoio e força durante o mestrado.
AGRADECIMENTOS
A Deus e à minha mãe Ieda, pela dádiva da vida e por me permitir chegar até aqui.
Agradeço em particular, à minha companheira, amiga e amor Silviane pela paciência, apoio e carinho.
Agradeço meu filho Yago por toda alegria e energia proporcionadas com o seu nascimento.
Ao meu sobrinho Lennon pela minha ausência em muitos momentos de sua vida, à minha família (irmão, tios, tias e primos) que soube entender e apoiar as faltas que tive durante este trabalho e à minha amiga Vera pelo suporte e apoio.
Ao Departamento de Engenharia de Sistemas do Instituto Militar de Engenharia pela excelência do ensino e oportunidade.
Aos funcionários do Instituto Militar de Engenharia, pelo apoio e pela colaboração nos momentos que mais precisei.
Ao Laboratório Nacional de Computação Científica, pelo apoio à pesquisa realizada.
À CAPES, por financiar a pesquisa no Brasil.
Ao Laboratório ACiMA por ceder os equipamentos necessários às simulações de meu trabalho.
À professora Claudia Justel pela atenção, apoio e amizade.
A todos que de alguma forma contribuíram para a concretização dessa dissertação.
Aos membros da banca examinadora, professora Debora Christina Muchaluat Saade e Edison Ishikawa, por aceitarem o convite para compor a banca e nos honrar com as suas presenças, sugestões e correções.
Aos meus orientadores professores Vidal, Jauvane e Artur por compartilhar seus conhecimentos, as suas experiências e, principalmente, pelo contínuo interesse em apoiar-me durante toda a jornada deste trabalho.
SUMÁRIO LISTA DE ILUSTRAÇÕES ... 11 LISTA DE TABELAS ... 14 LISTA DE SIGLAS... 15 1 INTRODUÇÃO ... 19 1.1 Contexto e Motivação ... 19 1.2 Objetivos... 21 1.3 Organização do Texto ... 22
2 SUPORTE DA REDE E PROTOCOLOS PARA AVCs... 24
2.1 Visão Geral... 24 2.2 Latência da Rede ... 24 2.3 Capacidade de Rede... 26 2.4 Confiabilidade da Rede ... 26 2.5 Protocolo de Rede... 28 2.5.1 Protocolo da Internet ... 28 2.6 Protocolos de Transporte ... 28 2.6.1 TCP ... 28 2.6.2 UDP ... 29 2.7 Tipos de Comunicação ... 30 2.7.1 Unicast... 30 2.7.2 Broadcast ... 31 2.7.3 Multicast ... 31
2.8 Escolha dos Protocolos de Transporte e Rede no Suporte a AVCs de grande escala ... 34
2.9 Alternativas ao IP Multicast ... 36
2.9.1 Mbone ... 36
2.9.2 Multicast na Camada de Aplicação ... 37
2.9.2.2 Tamanho do Grupo e Área de Aplicação ... 41
2.10 Resumo ... 42
3 AMBIENTE VIRTUAL COLABORATIVO ... 43
3.1 Realidade Virtual ... 43
3.2 Ambiente Virtual ... 43
3.3 Ambiente Virtual Colaborativo ... 44
3.4 Arquiteturas Para Ambientes Virtuais Colaborativos ... 45
3.4.1 SIMNET e DIS ... 45 3.4.2 NPSNET-IV ... 47 3.4.3 PARADISE ... 48 3.4.4 DIVE ... 49 3.4.5 BrickNet ... 50 3.4.6 SPLINE... 51 3.4.7 VELVET... 52 3.5 Resumo ... 54 4 TRABALHOS RELACIONADOS ... 55
4.1 Protocolo ALM Scribe no Suporte a Aplicação Simmud ... 56
4.1.1 Jogos Massivos Múltiplos jogadores Online ... 57
4.1.1.1 Estados do Jogo... 57
4.1.1.2 Suporte a Sistemas MMGs... 57
4.1.1.3 O Efeito da Latência da Rede no Desempenho do Jogador ... 58
4.1.2 Infra-estrutura Peer-to-Peer... 58
4.1.2.1 Pastry ... 59
4.1.2.2 Scribe ... 59
4.1.3 Mapeando estado do jogo em membros P2P... 60
4.1.4 Resultados experimentais ... 60
4.1.4.1 Resultados... 61
4.1.4.2 Efeito do Crescimento da População ... 63
4.1.4.3 Efeito da Densidade da População ... 63
4.1.5 Conclusão... 65
4.2 Estudo Comparativo de Protocolos ALM ... 65
4.2.1 Avaliação de Desempenho dos Protocolos ... 65
4.2.1.1 Qualidade do Caminho de Dados... 65
4.2.1.2 Overhead de Controle ... 66
4.2.1.3 Diferentes Caminhos na Sobre-camada ALM ... 66
4.2.2 Abordagens ALM... 68 4.2.2.1 Abordagem Mesh-first ... 69 4.2.2.2 Abordagem Tree-first... 70 4.2.2.3 Abordagem Implícita... 70 4.2.3 Estudo Comparativo ... 71 4.3 Outros Trabalhos... 72
5 SUPORTE ALM A AVCs DE GRANDE ESCALA ... 73
5.1 Estudo Comparativo dos Protocolos ALM ... 73
5.1.1 Introdução... 73
5.1.2 Latência ... 73
5.1.3 Gerenciamento de Grupo ... 74
5.1.4 Transmissão de Dados... 75
5.1.5 Escolha dos Protocolos ALM no Suporte a AVCs de Grande Escala... 75
5.1.6 Protocolo TBCP... 77
5.1.7 Protocolo Scribe ... 77
5.1.8 Protocolo CAN Multicast... 78
5.1.8.1 Introdução... 78
5.1.8.2 CAN ... 79
5.1.8.3 Roteamento em CAN ... 81
5.1.8.4 Construção da CAN... 82
5.1.8.4.1 Etapa 1: Encontrando Um Membro da CAN... 82
5.1.8.4.2 Etapa 2: Encontrando a Zona de Coordenadas ... 83
5.1.8.4.3 Etapa 3: Atualizando os Vizinhos ... 83 5.1.8.4.4 Etapa 4: Novo Membro Recebe sua Porção no Espaço e seu
5.1.8.5 Saída de Um Membro da CAN ... 85
5.1.8.5.1 Algoritmo de Saída ... 85
5.1.8.6 Melhorias na CAN ... 87
5.1.8.6.1 Múltiplas Dimensões no Espaço de Coordenadas. ... 87
5.1.8.6.2 Múltiplas Realidades no Espaço de Coordenadas ... 88
5.1.8.6.3 Construção da Sobre-camada CAN Baseada na Topologia da Rede Física. ... 89
5.1.9 Multicast em CAN... 91
5.1.9.1 Encaminhamento Multicast... 91
5.1.9.1.1 Inundação Direcionada Baseada na Estrutura CAN... 91
5.1.10 Ambientes Virtuais Colaborativos de grande escala ... 95
5.1.10.1 Estados do Mundo... 95
5.1.10.2 O Efeito da Latência nos AVCs de Grande Escala... 96
5.1.10.3 Arquitetura para AVCs de Grande Escala ... 96
5.1.10.3.1 Subprotocolos ISTP... 98
5.1.10.3.2 Junção de Um Membro ao Locale... 98
5.1.10.4 Implementação dos Protocolos no Simulador ... 99
5.1.10.4.1 Modelo do Mundo... 100
5.1.10.4.1.1 Máquina de Estados dos Membros no Mundo Virtual ... 100
5.1.10.4.2 Resultados Experimentais ... 102
5.1.10.4.3 Overhead para Entrada de Membros no Mundo virtual... 103
5.1.10.4.3.1 Primeira Etapa ... 103
5.1.10.4.3.2 Segunda Etapa ... 106
5.1.10.4.3.3 Terceira Etapa ... 108
5.1.10.4.3.4 Quarta e Quinta Etapas ... 110
5.1.10.4.3.5 Resumo das Etapas para a Entrada de Membros no Mundo Virtual ... 112
5.1.10.4.3.6 Custo Total para Entrada de Membros no Mundo Virtual... 113
5.1.10.4.4 Overhead para Saída de Membros no Mundo... 114
5.1.10.4.5 Overhead para Movimentação de Membros Entre Locales no Mundo... 116
5.1.10.4.6 Divulgação de Estados Entre Membros no AVC ... 117
6 CONCLUSÃO ... 121
6.1 Avaliação do Trabalho ... 121
6.2 Contribuições... 123
6.3 Trabalhos Futuros ... 123
LISTA DE ILUSTRAÇÕES
FIG. 2.1 Tráfego Unicast ... 32
FIG. 2.2 Tráfego Multicast ... 32
FIG. 2.3 Tunelamento de dados multicast... 36
FIG. 2.4 Organização hierárquica dos membros em NICE ... 38
FIG. 2.5 Topologia de controle e topologia de dados em NICE ... 39
FIG. 2.6 Visão geral da arquitetura ALMI ... 40
FIG. 3.1 Movimento de um objeto entre os hexágonos em NPSNET-IV ... 48
FIG. 3.2 Modelo cliente-servidor BrickNet ... 50
FIG. 3.3 Modelo do Mundo divido em locales e a movimentação de um participante do mundo entre locales... 52
FIG. 4.1 Distribuição da taxa de mensagens. Média do tamanho do grupo igual a 10. Sem agregação de mensagens. ... 61
FIG. 4.2 Distribuição dos saltos em mensagens unicast. Média do tamanho do grupo igual a 10. Sem agregação de mensagens. .. 62
FIG. 4.3 Distribuição dos saltos em mensagens multicast. Média do tamanho do grupo é 10. Sem agregação de mensagens... 62
FIG. 4.4 Efeito da agregação de mensagens. Com 1000 jogadores e 100 regiões... 64
FIG. 4.5 Camada de rede e camada de aplicação multicast. Nós retangulares são roteadores, e nós circulares são sistemas finais. ... 67
FIG. 5.1 Exemplo de um espaço de coordenadas de dimensão = 2
com 5 membros... 79
FIG. 5.2 Vizinhança entre membros na CAN de dimensão = 2 ... 80
FIG. 5.3 Vizinhança entre membros na CAN de dimensão = 3 ... 80
FIG. 5.4 Exemplo do caminho de roteamento em uma CAN de dimensão 2 do membro 1 ao ponto (x, y). ... 81
FIG. 5.5 Etapas da construção da CAN ... 84
FIG. 5.6 Entrega da zona a um vizinho herdeiro ... 86
FIG. 5.7 Efeito das dimensões no caminho de roteamento... 88
FIG. 5.8 Efeito das realidades no caminho de roteamento... 89
FIG. 5.9 Efeito “zig-zag” ... 90
FIG.5.10 Direção dos vizinhos D, E e B na dimensão 1 em relação ao membro A ... 92
FIG. 5.11 Inundação direcionada com origem no membro B. ... 93
FIG. 5.12 Inundação direcionada com regras para evitar duplicação de mensagens ... 94
FIG. 5.13 Modelo do mundo em SPLINE. ... 97
FIG. 5.14 Modelo do mundo. Setas indicam vizinhança entre os locales. Onde, para cada Locale Li, com i entre 1-10, tem associado o grupo CAN Multicast Gi. ... 100
FIG. 5.15 Estados dos membros no mundo virtual ... 101
FIG. 5.17 Entrada de participantes no AVC. ... 105
FIG. 5.18 Obtendo lista de membros de cada grupo CAN Multicast. ... 106
FIG. 5.19 Custo para obtenção da lista de membros ativos no grupo CAN Multicast... 107
FIG. 5.20 Envio de mensagem JOIN através do Roteamento CAN. ... 108
FIG. 5.21 Roteamento CAN, para entrada de um novo membro. ... 109
FIG. 5.22 Divulgação do novo espaço, ao novo membro e vizinhos do ocupante anterior... 111
FIG. 5.23 Atualizações do espaço de coordenadas (novo membro e vizinhos). ... 112
FIG. 5.24 Custo para entrar no mundo virtual ... 113
FIG. 5.25 Custo para sair do mundo virtual... 115
FIG. 5.26 Custo para movimento no mundo virtual ... 116
LISTA DE TABELAS
TAB. 2.1 Protocolos alternativos para AVCs de grande escala... 35
TAB. 4.1 Comparação entre Diferentes Esquemas ALM ... 71
TAB. 5.1 Protocolos ALM e suas características... 76
LISTA DE SIGLAS
ALM Application Layer Multicast
ALMI An Application Level Multicast Infrastructure AoI Area of Interest
AVC Ambiente Virtual Colaborativo CAN Content-Addressable Networks
CBT Core Based Tree
CDF Cumulative Distribution Function CPU Central Processing Unit
CRC Cyclic Redundancy Check
DARPA Defense Advanced Research Projects Agency DIS Distributed Interactive Simulation
DIVE Distributed Interactive Virtual Environment
DNS Domain Name System
DVMRP Distance Vector Multicast Routing Protocol
E/S Entrada e Saída
ESM End System Multicast
ID Identifier Distributed
IEEE Internet Engineering Task Force IGMP Internet Group Management Protocol
IP Internet Protocol
ISDN Integrated Services Digital Network ISTP Interactive Sharing Transfer Protocol
LAN Local Area Network
Mbone Multicast Backbone
MERL Mitsubishi Electric Research Laboratories MMG Massively Multi-player Game
MOSPF Multicast extensions to OSPF
MST Minimum Spanning Tree
MVP Mundo Virtual Paralelo OSPF Open Shortest Path First
P2P Peer-to-Peer
PARADISE Performance ARchietecture for Advanced Distributed Interactive Simulation Environments
PDU Protocol Data Unit
PIM Protocol Independent Multicast PSI Provedor de Serviço de Internet RDSI Rede Digital de Serviços Integrados
RP Rendezvous Point
RPF Reverse Path Forwarding
RV Realidade Virtual
SIMNET Simulator Networking
SLINE Scalable platform for Large Interactive Networked Environments TBCP Tree Building Control Protocol
TCP Transmission Control Protocol
TTL Time To Live
UDP User Datagram Protocol
VELVET An Adaptive Hybrid Architecture for VEry Large Virtual Environments
RESUMO
Ambientes Virtuais Colaborativos (AVCs) são sistemas onde um grupo de usuários podem interagir entre si e com o próprio sistema, permitindo assim usuários colaborarem. Muitas arquiteturas AVC avançadas contam fortemente com o uso do multicast na camada de rede no suporte a comunicação. No entanto, multicast na camada de rede não está prontamente disponível na Internet. Multicast na camada da aplicação (ALM – Application Layer Multicast) tem recentemente surgido como uma boa alternativa ao multicast na camada de rede. Neste trabalho, nós avaliamos diversos algoritmos ALM a partir das necessidades de rede impostas por aplicações AVC.
ABSTRACT
Collaborative Virtual Environments (CVEs) are systems where a group of users may interact with one another and with the system itself, thus allowing users to collaborate. Most advanced CVE architectures rely heavily on network-layer multicasting. Nevertheless, network-layer multicasting is still not broadly available in the Internet. Application-layer multicasting (ALM) has recently emerged as a good alternative to network-layer multicasting. In this work we evaluate the adoption of ALM algorithms in the light of network requirements imposed by CVE applications.
1 INTRODUÇÃO
Este capítulo apresenta um breve contexto e motivação para a escolha do tema apresentado, o objetivo e a organização dessa dissertação.
1.1 CONTEXTO E MOTIVAÇÃO
IP Multicast é uma técnica de roteamento que possui eficiência na entrega de pacotes a partir de uma única origem a múltiplos destinos (DEERING,1990). Essa técnica elimina a replicação de pacotes redundantes em um mesmo enlace físico na rede. Entretanto, sua implementação na rede requer suporte nos diversos roteadores espalhados geograficamente (DIOT, 2000), o que limita uma adoção abrangente de IP Multicast na Internet.
Aplicações como vídeo-conferência, ensino a distância e salas privadas de bate-papo requerem diferentes exigências no ponto de vista do projeto do IP Multicast. Essas aplicações em geral contêm um número pequeno de participantes dentro do grupo e os grupos são criados e eliminados com certa freqüência. Quando há um grande número desses pequenos grupos, a eficiência na largura de banda e a escalabilidade oferecida pelo IP multicast é reduzida pela complexidade do controle ligada à configuração e manutenção do grupo (PENDAKARIS, 2001). Há um crescimento no número de aplicações desses tipos e pesquisadores vêm procurando por soluções que não dependam de suporte multicast nos roteadores.
Tentativas anteriores de formar redes que utilizam IP Multicast, unidas através de túneis unicast pela Internet, chamadas “ilhas”, resultaram no chamado Mbone (Multicast Backbone) (ERIKSON, 1994). O Mbone utiliza-se de túneis para que os pacotes multicast atravessem as redes por meio de encapsulamento dos pacotes. Os pacotes chegam até o próximo roteador compatível que desencapsula os pacotes e os transmite ao destino final. Porém, dificuldades de configuração dos túneis bem como administração e gerenciamento dos problemas inerentes ao IP
Multicast fazem com que poucos Provedores de Serviços Internet (PSIs) disponibilizem conexões Mbone para usuários domésticos.
Multicast na camada de aplicação ou Application Layer Multicast (ALM) ou ainda End System Multicast (ESM) é uma alternativa que tem o potencial de resolver os problemas associados ao IP Multicast (BANERJEE, 2002a) (CHU, 2000) (PENDAKARIS, 2001) (CASTRO, 2002) (RATNASAMY, 2001b) (ZHUANG, 2001). Apesar de não possuir o mesmo desempenho do IP Multicast, protocolos ALM não dependem de alterações na infra-estrutura da rede. Em vez disso, implementa-se um serviço similar ao multicast a partir da colaboração entre sistemas finais através do encaminhamento de pacotes. Em ALM todos os pacotes transmitidos são pacotes unicast de forma distribuída. Os protocolos ALM são uma atraente proposta alternativa ao IP Multicast e, com a baixa difusão do IP Multicast na Internet, diversos protocolos ALM foram criados para atender as mais diversas aplicações. Yoid (FRANCIS, 1999), ALMI (PENDAKARIS, 2001), NARADA (CHU, 2000), NICE (BANERJEE, 2002a), RMX (CHAWATHE, 2000), Bayeux (ZHUANG, 2001), Scribe (CASTRO, 2002) e CAN Multicast (RATNASAMY, 2001b) são alguns dos diversos protocolos ALM existentes.
Um protocolo ALM é construído para a atender aplicações específicas. Com isso, requisitos como o atraso entre sistemas finais, a escalabilidade, a tolerância a falhas, o caminho de dados ser específico a cada origem ou ser compartilhado entre os sistemas finais devem ser considerados antes da escolha do protocolo ALM.
Em aplicações baseadas em Ambientes Virtuais Colaborativos (AVCs) de grande escala o uso de um protocolo ALM é uma solução alternativa para redução de tráfego redundante na rede gerada pela necessidade de atualização das cópias do mundo virtual entre os participantes. A utilização de comunicação multicast permite melhorias na escalabilidade do ambiente virtual, pois o modelo de comunicação permite o aumento do número de usuários no ambiente. No entanto, sua baixa difusão acarreta na exclusão de participantes cujos PSIs não ofereçam suporte ao IP Multicast. Com isso, encontrar um protocolo ALM que melhor atenda as aplicações para AVCs de grande escala se torna uma importante contribuição para aqueles que têm pretensão de disponibilizar uma aplicação para tais sistemas e que não querem esbarrar nos problemas inerentes ao IP Multicast.
Este trabalho apresenta um estudo comparativo entre alguns dos diversos protocolos ALM existentes e a seleção daqueles protocolos ALM que melhor atendem as necessidades das aplicações AVCs de grande escala.
Os protocolos TBCP (MATHY, 2001), Scribe (CASTRO, 2002) e CAN Multicast (RATNASAMY, 2001b) foram os protocolos selecionados como adequados as aplicações AVCs de grande escala por atender aos requisitos das aplicações AVCs de grande escala. Dentre eles, o protocolo CAN Multicast foi escolhido para ser implementado em um ambiente de simulação e os resultados obtidos demonstram que CAN Multicast é uma boa alternativa no suporte a diversos AVCs de grande escala, desde que propriamente utilizado.
1.2 OBJETIVOS
Multicast na camada de aplicação tornou-se uma atraente alternativa ao multicast original abrindo novos campos de pesquisas para o estudo desses protocolos. Pesquisadores buscam encontrar e desenvolver protocolos ALM que atendam aplicações específicas. Dessa forma, protocolos são construídos com características básicas diferentes, o que dá origem a diversas categorias de protocolos ALM. A categorização desses protocolos permite a seleção e implementação do protocolo ALM mais adequado de forma mais simples e mais rápida. Por exemplo, aplicações para vídeo-conferência requerem atraso mínimo na entrega de dados entre participantes, porém, em geral, são formadas por um número médio ou pequeno de participantes. Por outro lado, aplicações que oferecem envio de fluxo de áudio/vídeo (por exemplo, difusão de rádio e tv na Internet) usualmente envolvem uma única origem de distribuição de mídia para um grande número de receptores e sua métrica primária a ser considerada é a largura de banda. Isso sugere suporte de protocolos ALM diferentes.
Este trabalho estuda e classifica alguns dos diversos protocolos ALM existentes. Dentre os protocolos ALM estudados serão selecionados aqueles que mais se adequam às aplicações AVCs de grande escala.
Um dos protocolos ALM selecionado será levado a um ambiente de simulação e através da coleta de resultados da simulação, indicar em quais situações o protocolo ALM simulado é adequado para AVCs de grande escala.
O estudo dos protocolos ALM e os resultados colhidos com a implementação desses em um ambiente de simulação facilita a sua escolha para experimentação por desenvolvedores de AVCs de grande escala.
O objetivo deste trabalho é mostrar, por meio de simulação, que o protocolo ALM CAN Multicast é um protocolo que atende as necessidades dos AVCs de grande escala sendo uma boa alternativa à comunicação dada a ausência do multicast na camada de rede em muitos roteadores na Internet.
1.3 ORGANIZAÇÃO DO TEXTO
Esta dissertação está estrutura em 7 capítulos, de tal forma que:
• No capítulo 2, são apresentados os princípios básicos de computação em redes, os protocolos de comunicação, alguns tipos de comunicação e alternativas ao IP Multicast.
• No capítulo 3, são apresentados conceitos e características da realidade virtual, do ambiente virtual, do ambiente virtual colaborativo bem como algumas das diversas propostas de arquiteturas para ambientes virtuais colaborativos.
• No capítulo 4, são apresentados dois trabalhos relacionados. O primeiro envolve a implementação de um protocolo ALM em um ambiente de simulação. O segundo envolve o estudo comparativo de alguns protocolos ALM e suas categorizações.
• No capítulo 5 é apresentado um estudo comparativo dos protocolos ALM proposto por este trabalho além da implementação e resultados de simulação do protocolo CAN Multicast no suporte a AVCs de grande escala.
• No capítulo 6 são apresentadas as conclusões do trabalho, assim como as possibilidades de trabalhos futuros.
2 SUPORTE DA REDE E PROTOCOLOS PARA AVCs
2.1 VISÃO GERAL
A rede é um fator importante aos AVCs, pois através dela são trocadas informações e mensagens de dados entre múltiplos sistemas finais que interagem em um ambiente compartilhado. Sistemas de AVCs devem, portanto, levar em consideração o fator rede quando da sua implementação. Quando construído um ambiente virtual para rodar em uma única máquina, diferentes componentes da aplicação podem trocar informações instantaneamente através de chamadas de funções. Porém, se trocamos informações sobre a rede, então, essas informações trocadas não são tão instantâneas. Em vez disso, pode levar uma significativa fração de segundos para a informação ser transmitida de uma aplicação para a outra. No pior caso, a informação pode se perder pelo caminho e nunca chegar ao seu destino.
Diversas questões afetam a construção de AVCs, e princípios básicos de computação em redes, incluindo conceitos como largura de banda, latência e confiabilidade, protocolos de transporte e de rede, tipo de comunicação a ser utilizado devem ser discutidos.
2.2 LATÊNCIA DA REDE
A latência da rede, ou atraso da rede, é a quantidade de tempo requerido para transferir um bit de dados de um ponto para outro (SINGHAL, 1999). Quando uma aplicação AVC gera dados para transmissão sobre a rede, a latência da rede determina quando a aplicação do receptor recebe os dados transmitidos. Esse atraso representa um dos maiores desafios para o projeto de AVCs, pois, a latência
impacta diretamente o realismo de experiências AVCs por determinar quando as informações AVCs recebidas da rede são atualizadas.
Os principais fatores que influenciam na latência de uma rede são: atraso de propagação; atraso de transmissão; atraso de fila e atraso de processamento dos equipamentos.
O atraso de propagação corresponde ao tempo necessário para a propagação do sinal elétrico ou propagação do sinal óptico no meio utilizado (fibra, satélite, cabo coaxial, etc).
O atraso de transmissão é dado segundo a velocidade de transmissão do enlace (R) em bits/s e o comprimento do pacote (L) em bits. O atraso de transmissão é L/R. Valores de latência na rede caem em uma grande faixa. Se você está enviando dados em uma rede local, a latência é abaixo de 10 ms. Por outro lado, se você está conectado a Internet por meio de um modem através do sistema telefônico, sua latência vai ser no mínimo de 100 ms. Esses valores de latência vão se tornando maiores se o destino está cada vez mais distante da origem. Transferências transcontinentais requerem um adicional de 60-150 milissegundos, e latências intercontinentais uma faixa de 250-500 ms ou mais. (SINGHAL, 1999)
O atraso de fila é a quantidade de tempo que um pacote leva na fila enquanto espera para ser transmitido no enlace. O atraso de fila para um pacote específico dependerá da quantidade de outros pacotes que chegaram antes e que já estão na fila esperando pela transmissão no enlace. Esse atraso pode variar significativamente de pacote para pacote. Se a fila estiver vazia e não houver nenhuma transmissão de pacote em curso, então o tempo de atraso de fila do pacote será zero. Por outro lado, se o tráfego estiver pesado e houver muitos pacotes esperando para serem transmitidos, o atraso de fila será longo.
O quarto fator que contribui para a latência da rede é a contribuição do atraso referente ao processamento realizado nos equipamentos, como, por exemplo, roteadores, switches, firewalls, etc. Considerando-se que latência é um parâmetro fim-a-fim, os equipamentos finais também têm sua parcela de contribuição para o atraso. Eles tomam tempo para os dados atravessarem os sistemas operacionais dos computadores e equipamentos de rede antes de alcançar a rede; similarmente, os dados devem atravessar os equipamentos de rede e sistemas operacionais antes de serem entregues a aplicação do sistema final destino.
2.3 CAPACIDADE DE REDE
A largura de banda da rede é a taxa na qual a rede pode entregar dados ao próximo nó no caminho para o sistema final destino. A disponibilidade da largura de banda é determinada pelo tipo de meio usado para transportar os dados e ela é também limitada pelos equipamentos usados para transmitir os dados (STALLINGS, 1996). Uma linha telefônica digital pode transmitir no máximo 64 Kbps. Uma RDSI (Rede Digital de Serviços Integrados ou ISDN – Integrated Services Digital Network) faixa estreita pode suportar entre 192-2048Kbps. A Ethernet tradicional pode suportar 10 Mbps, 100 Mbps ou até 1Gbps. Um cabo de fibra óptica pode transferir em até 10 Gbps ou mais.
2.4 CONFIABILIDADE DA REDE
Confiabilidade da rede é a medida da quantidade de dados perdidos pela rede durante o percurso entre o sistema final origem e o sistema final destino. Esses dados perdidos podem ser divididos em duas categorias, “descartados” e “corrompidos”. Dados descartados significam que os dados não chegaram ao seu destino, porque eles foram previamente descartados pela rede. Dados corrompidos significam que o conteúdo dos pacotes de dados foi alterado entre a transmissão e a recepção dos dados ao destino. É comum tratar dados descartados e dados corrompidos como equivalentes, pois nos dois casos os dados não são usados pelos sistemas finais destino da mesma forma.
Os dados podem ser perdidos no percurso dentro do meio de transmissão da rede. Entretanto, a freqüência desse tipo de erro é tipicamente medida na ordem de um bit corrompido em 1010 bits transmitidos. Esse tipo de perda é mais freqüente em redes sem fio, onde os dados são enviados através de sinais de rádio, ou entre modems sem fio ou entre uma base na Terra e um satélite. Nessas situações, o meio de transmissão é menos controlável porque ele está sujeito a interferências de transmissões concorrentes, ao mau tempo e a interferências por objetos.
O projeto da rede tipicamente inclui redundâncias suficientes para detectar dados corrompidos. Por exemplo, cada transmissão usualmente inclui um checksum, como o CRC (Cyclic Redundancy Check) (SHEINWALD, 2002) que é calculado a partir do conteúdo do pacote. Os receptores tentam recalcular o checksum dos dados que eles recebem. Se o cálculo do checksum não coincide com o checksum contido no pacote, então o receptor descarta os dados corrompidos. Em certas redes, pacotes de dados podem incluir códigos corretores de erro que incluem informações extras suficientes sobre os dados tais que o receptor possa corrigir um ou mais bits errados nos dados recebidos.
Por outro lado, a causa mais comum de dados perdidos está nos roteadores de rede que transferem dados entre as linhas de transmissão. Roteadores podem processar pacotes em uma certa taxa, mas os dados podem chegar em uma taxa variável. Ocasionalmente, pacotes podem chegar mais rápido do que os roteadores podem processá-lo, e nessas situações, o roteador deve enfileirar os dados para depois processá-los. Se a quantidade de dados é muito grande, o roteador pode “transbordar” a sua capacidade de armazenamento de dados em memória e conseqüentemente o descarte de alguns dados vão ocorrer. A confiabilidade da rede pode variar amplamente. Em momentos de pico, quando as filas nos roteadores estão cheias, a perda de dados pode exceder a 50%. Em outras vezes, as perdas de dados podem ser insignificantes (SINGHAL, 1999).
Ainda assim, a confiabilidade de entrega de dados pode ser alcançada. Um mecanismo de reconhecimento na recepção dos dados pode ser empregado. Nesse mecanismo o sistema final destino envia de volta ao sistema final origem um reconhecimento cada vez que os dados forem recebidos. Os reconhecimentos podem ser feitos por meio de pacotes especiais ou podem ser incluídos (piggybacked) dentro de outros pacotes transmitidos pelo sistema destino ao sistema origem. Esses reconhecimentos notificam a origem que os dados chegaram com sucesso ao sistema final destino. Se a origem não recebe um reconhecimento em um certo período de tempo após o envio dos dados, então ele assume que os dados foram perdidos pela rede e uma nova tentativa de envio dos dados é feita. Note que, se a origem não recebeu o reconhecimento, isso não significa que os dados não foram recebidos pelo sistema final, pois o reconhecimento pode ter sido perdido pela rede.
2.5 PROTOCOLO DE REDE
2.5.1 PROTOCOLO DA INTERNET
Sistemas finais na Internet usam o IP (Internet Protocol) (POSTEL, 1981) para se comunicarem. O IP é um protocolo usado por sistemas finais e roteadores, para assegurar que os pacotes viajem de um sistema final origem a um sistema final destino. O IP esconde o fato de que o caminho de transmissão deve incluir linhas telefônicas, redes locais (LAN – Local Area Network), rede em grandes áreas (WAN – Wide Area Network), redes sem fios, enlaces com satélites. O IP inclui facilidades de segmentação e remontagem, ou seja, quebras de pacotes em pequenos fragmentos quando eles atravessam enlaces de redes que não podem suportar pacotes com tamanho grande e remontagem dos pacotes nos sistemas finais. O cabeçalho IP inclui o campo “tempo de vida” (TTL – Time-To-Live) que especifica a quantidade de saltos que um pacote pode efetuar na rede. Cada vez que um pacote executa um salto entre roteadores, o campo TTL é decrementado de uma unidade e se ele chegar a zero, o pacote é descartado. Isso é feito, para evitar que pacotes possam acidentalmente ser roteados em um loop infinito na Internet.
Aplicações quase nunca usam o protocolo IP diretamente. Em vez disso, elas usam um protocolo da camada superior como o TCP e o UDP.
2.6 PROTOCOLOS DE TRANSPORTE
2.6.1 TCP
TCP (Transmission Control Protocol) é um dos protocolos mais comuns usado na Internet. O TCP está definido em (POSTEL, 1981) (BRADEN, 1989) (JACOBSON, 1992) (MATHIS, 1996) (ALLMAN, 1999). O TCP é um protocolo da
camada de transporte e fornece multiplexação e demultiplexação à camada superior e um campo checksum no cabeçalho para detecção de erro. TCP é um protocolo confiável, porque ele dá suporte à transmissão de reconhecimento e retransmissão de dados automaticamente. A confiabilidade do TCP é ainda mais assegurada porque ele verifica a integridade dos pacotes recebidos a partir do campo checksum e também porque os dois sistemas finais empregam um procedimento de controle de fluxo para assegurar que o remetente não transmita pacotes mais rapidamente do que a rede possa transferi-los ou o sistema destino final possa processá-los. Em resumo, cada sistema final pode considerar uma conexão TCP como um fluxo bidirecional confiável de bytes. O TCP cuida automaticamente de dividir a cadeia de dados a ser enviada em pacotes na rede para transmissão, descarta pacotes duplicados e ordena os pacotes recebidos formando a cadeia de dados original para ser entregue à leitura pela aplicação no sistema final destino. O TCP também permite a um sistema final detectar a queda ou a desconexão do sistema final da outra ponta.
A confiabilidade e ordenação garantida pelo TCP são fundamentais para muitos aplicativos. Porém o custo dessas garantias é a introdução de uma certa sobrecarga. Para aplicações em tempo real, tolerante a perda de dados, sem exigência de ordenação dos dados e sensíveis a atraso, o TCP pode não ser um protocolo adequado.
2.6.2 UDP
UDP (User Datagram Protocol) definido em (POSTEL, 1980) é um protocolo da camada de transporte e assim como o TCP fornece multiplexação e demultiplexação à camada superior e um campo checksum no cabeçalho para detecção de erros na mensagem. O UDP usa o IP para transportar uma mensagem de uma máquina à outra, e como o IP, o UDP fornece a mesma conotação não-confiável da transmissão de datagrama sem conexão.
O UDP não usa confirmação para certificar-se de que as mensagens chegam, não ordena as mensagens no sistema final e não fornece informação para controlar
a velocidade com que as informações fluem entre as máquinas. Assim, as mensagens UDP podem se perder, ser duplicadas ou chegar com problemas. Mais ainda, os pacotes podem chegar mais rapidamente do que podem ser processados pelo destinatário. Podemos resumir:
O UDP fornece um serviço de transmissão sem conexão, não-confiável, usando o IP para transportar mensagens entre sistemas finais. Usa o IP para transportar mensagens, porém acrescenta a habilidade de distinguir entre múltiplos sistemas finais destinos em um certo sistema final. (COMER,1998)
Um programa aplicativo que usa UDP aceita inteira responsabilidade para lidar com o problema de confiabilidade, inclusive perda de mensagem, duplicação, retardo, transmissão defeituosa e perda de conectividade. (COMER, 1998)
O UDP é um protocolo de estrutura muito simples visando o mínimo de sobrecarga. A transmissão de mensagens utilizando o UDP requer menos interação entre transmissor e receptor se comparado ao TCP, sendo assim é muito mais rápida.
2.7 TIPOS DE COMUNICAÇÃO
2.7.1 UNICAST
Unicast é um tipo de comunicação ponto-a-ponto entre dois sistemas finais, uma origem e um destino. Na comunicação unicast se uma origem deseja enviar uma mesma mensagem a um conjunto de destinos, a quantidade de mensagens geradas pela origem será igual à quantidade de destinos, ou seja, a origem deve gerar uma mensagem cópia para cada destino.
2.7.2 BROADCAST
Broadcast é um tipo de comunicação ponto-multiponto. O broadcast minimiza o problema da grande quantidade de mensagens geradas por um sistema final-origem. No broadcast uma única mensagem é gerada e enviada a todos os demais sistemas finais em uma rede. Porém, por medida de segurança o encaminhamento de pacotes broadcast são desativados nos roteadores na Internet e isso impede sua disponibilidade em uma WAN. No entanto, sua utilização pode ser bem aproveitada por AVCs em LANs. Sistemas finais conectados a rede sem interesse em receber as mensagens broadcast, simplesmente fazem o seu descarte. Porém, se a quantidade de usuários na rede for muito grande, uma grande quantidade de tráfego poderá estar ocupando a rede desnecessariamente.
2.7.3 MULTICAST
IP-Multicast (DEERING, 1990) é uma tecnologia que permite a um sistema origem enviar mensagens para vários sistemas destino simultaneamente, de forma eficiente. Esse tipo de comunicação, conhecido também como comunicação ponto-a-multiponto ou de grupo, é mais eficiente que uma comunicação broadcast por permitir a recepção dos dados apenas por membros de um grupo previamente definido e é mais eficiente que várias comunicações unicast (ponto-a-ponto) simultâneas por fazer melhor uso do meio de comunicação, evitando redundância de mensagens na rede.
Na Internet, quando uma mesma mensagem deve ser enviada para diversos sistemas finais, são enviadas pela rede tantas cópias dessa quanto forem os sistemas finais. Isso acarreta em desperdício de recursos, principalmente se cópias da mesma mensagem trafegarem pelos mesmos enlaces, causando um congestionamento desnecessário. O cenário acima citado é baseado em unicast, cuja comunicação é a-ponto. A alternativa é, então, uma comunicação ponto-multiponto: enviar uma única cópia da mensagem pela rede, destinada ao grupo de
sistemas finais como um todo. Assim, os pacotes que compõem essa mensagem só serão duplicados quando for realmente necessário.
No exemplo de tráfego unicast da figura 2.1 os pacotes são duplicados já entre o primeiro e o segundo roteador, gerando um consumo de recursos desnecessários nesses enlaces. No exemplo de tráfego multicast da figura 2.2, os pacotes são duplicados somente quando não há mais alternativa e ocorrem nos enlaces entre o segundo e os últimos roteadores.
FIG. 2.1 Tráfego Unicast
Para que haja a correta duplicação dos pacotes nos pontos corretos, é necessária a utilização de protocolos de roteamento multicast, que criam árvores para a distribuição dos dados. As árvores podem ser com raiz compartilhada (shared tree) ou com raiz na fonte do tráfego multicast (source tree).
Em árvores com raiz compartilhada, existe uma entidade chamada de RP (Rendezvous Point), responsável por receber todo o tráfego multicast das fontes e reencaminhá-lo para os receptores. Nessa abordagem uma única árvore é criada para o grupo e cada roteador guarda apenas informações sobre o grupo, não importando qual a fonte.
Nas árvores com raiz na fonte, existe uma árvore diferente para cada fonte multicast, independente do tráfego ser destinado para o mesmo endereço ou não. Nessa abordagem cada roteador armazena informações sobre fonte e grupo.
Como exemplos podemos citar o DVMRP (Distance Vector Multicast Routing Protocol) (WAITZMAN, 1998), o PIM (Protocol Independent Multicast) Dense Mode (DEERING, 1996) (ESTRIN, 1998) e o MOSPF (Multicast Extensions to OSPF) (MOY, 1994) como protocolos de roteamento que constroem árvores de raiz na fonte para a distribuição de dados, o CBT (Core Based Tree) (BALLARDIE, 1997) e o PIM (Protocol Independent Multicast) Sparse Mode (DEERING, 1996) (ESTRIN, 1998) como protocolos de roteamento que constroem árvores de raiz compartilhada para a distribuição de dados.
Em essência, a árvore de distribuição é composta de roteadores que mantêm uma informação básica: por qual interface um pacote multicast entrou e por qual ele deve sair.
No modelo multicast, um sistema final se associa a um grupo e deixa-o usando o protocolo IGMP (Internet Group Management Protocol) (FENNER, 1997). O sistema final avisa ao roteador multicast de sua sub-rede a intenção de participar de determinado grupo (por meio de uma mensagem de adesão). O roteador passa então a encaminhar os pacotes recebidos e endereçados àquele grupo para a sub-rede da qual o sistema final faz parte. Quando o sistema final decide deixar o grupo, ele avisa ao roteador (por meio de uma mensagem de saída), que simplesmente não repassa mais o tráfego para a sub-rede correspondente.
No IGMP, o roteador não está interessado em quantos ou quais sistemas finais participam do grupo. A única informação relevante é a presença ou ausência de pelo menos um participante do grupo em uma determinada sub-rede. Assim, o roteador não mantém nenhuma informação sobre os sistemas finais participantes do grupo.
A tecnologia IP Multicast não é universal. Vários sistemas operacionais ainda não possuem suporte ao IP Multicast. Os equipamentos de roteamento de alta
capacidade utilizados no núcleo da Internet, e que não suportam Multicast, são de difícil atualização, em vista de seu custo (DIOT, 2000).
2.8 ESCOLHA DOS PROTOCOLOS DE TRANSPORTE E REDE NO SUPORTE A AVCS DE GRANDE ESCALA
A partir da tabela 2.1, podemos comparar e selecionar o protocolo de transporte e de rede que melhor atendem aos AVCs de grande escala.
Na tabela 2.1, o protocolo de transporte TCP fornece garantia de entrega de dados fim-a-fim, ordenação na entrega, detecção de erro e controle de fluxo. Porém, o TCP está limitado à comunicação ponto-a-ponto (unicast). Além disso, seu mecanismo de ordenação na entrega dos dados pode acarretar na entrega de pacotes com atraso e a sua garantia de entrega pode acarretar na introdução de tráfego excedente na rede. Por outro lado, o protocolo de transporte UDP não introduz tráfego de controle na rede (por não fazer uso de mecanismo de controle), oferece entrega de dados imediata (não há overhead com ordenação dos dados) e suporta comunicação ponto-multiponto (broadcast, multicast).
A comunicação unicast é uma comunicação ponto-a-ponto. Tal fato pode limitar a escalabilidade de qualquer sistema. Já a comunicação broadcast é uma comunicação ponto-multiponto. Porém, seu uso está limitado a LANs. Por outro lado, a comunicação multicast é ponto-multiponto, não gera tráfego desnecessário na rede (possui alta eficiência no uso da banda) e não está limitada a LANs.
AVCs de grande escala requerem interação entre seus participantes, são sensíveis ao atraso, tolerantes a perdas e podem comportar um grande número de participantes (centenas ou até milhares). Um alto volume de tráfego é gerado com mensagens de sinalização e atualização de movimentos entre os participantes. Participantes em AVCs podem estar localizados tanto em redes locais quanto em redes geograficamente distribuídas. A partir dessas características, AVCs colaborativos seriam melhor construídos se usado UDP como protocolo de transporte e multicast como forma de comunicação.
Porém, implementações de multicast na camada de rede não têm sido feita pelos PSIs (Provedores de Serviço de Internet) comerciais, e isso implica em grande parte da Internet não ser capaz de suportar multicast (DIOT, 2000). Assim, alternativas a esse protocolo vêm sendo objeto de estudo de diversos pesquisadores. Uma alternativa bem conhecida é o chamado MBone (Multicast Backbone) (ERIKSON, 1994). Outra alternativa que vem atraindo bastante interesse é o desenvolvimento do multicast na camada de aplicação, os chamados protocolos ALM (Application Layer Multicast) ou ESM (End System Multicast).
TAB. 2.1 Protocolos alternativos para AVCs de grande escala
Protocolo Qualidades Limitações
TCP • Entrega garantida dos dados • Entrega ordenada dos dados • Detecção de erro na mensagem
pelo campo checksum no cabeçalho.
• Controle de fluxo
• Só suporta comunicação ponto-a-ponto (unicast)
• Pacotes podem chegar com atraso.
• Introduz tráfego de controle na rede. (ex. pacotes de reconhecimento)
• Cabeçalho mais complexo que o UDP.
UDP • Entrega imediata dos dados (não há sinalização inicial) • Não introduz tráfego de controle
na rede.
• Simplicidade no cabeçalho • Suporta comunicação
ponto-multiponto
• Detecção de erro na mensagem pelo campo checksum no cabeçalho.
• Não há confiabilidade na entrega dos dados.
• Na há ordenação na entrega dos dados
IP/Unicast • Disponível para o TCP/UDP. • Disponível da LAN a Internet.
• Comunicação ponto-a-ponto
IP/Broadcast • Comunicação ponto-multiponto • Limitado a redes locais (LANs) • Tráfego desnecessário na rede
(usuários podem não ter interesse em receber pacotes)
IP/Multicast • Comunicação ponto-multiponto • Eficiência no uso da banda. • Somente usuários do grupo
recebem os pacotes.
• Baixa disseminação na Internet (Roteadores podem não oferecer suporte)
2.9 ALTERNATIVAS AO IP MULTICAST
2.9.1 MBONE
MBone (ERIKSON, 1994) consiste de sub-redes que oferecem suporte a multicast ligadas entre si por meios de enlaces unicast. As sub-redes são chamadas de domínio e os enlaces unicast de túneis. Um conjunto de sub-redes que se comunica e oferece suporte a multicast é também conhecido como ilha. Oferecer suporte multicast, significa entender endereços multicast (classe D) (SEMERIA, 1996), usar o protocolo de gerenciamento IGMP e, no caso de sistemas intermediários, oferecer roteamento multicast.
FIG. 2.3 Tunelamento de dados multicast
No Mbone, tráfego de dados pode ser enviado e recebido entre os domínios. Domínios comunicam-se entre si na Internet por meio de sistemas que podem não oferecer suporte IP Multicast. Nesses casos, túneis são criados entre os domínios. Os túneis permitem que o tráfego multicast passe através de partes da Internet sem a capacidade multicast, ou seja, os pacotes IP Multicast são encapsulados com IP sobre IP de modo que pareçam pacotes unicast para os roteadores intermediários. Os pontos finais dos túneis são, geralmente, estações de trabalho com um sistema operacional com suporte ao IP Multicast, que executam um programa de roteamento
multicast (e.g. mrouted). O encapsulamento é feito na entrada do túnel e é retirado na saída. No mecanismo ilustrado na figura 2.3, o sistema final A envia dados destinados a seu grupo multicast. O sistema final B recebe os dados através do roteamento multicast. Enquanto o sistema final C recebe os dados em sua ilha por meio do túnel unicast entre roteadores especiais que implementam o programa mrouted. Dados multicast são encapsulados e desencapsulados por esses roteadores. Dentro da ilha os dados sofrem roteamento multicast.
MBone é uma alternativa ao IP Multicast. Porém, dificuldades de configuração dos túneis bem como administração e gerenciamentos dos problemas inerentes ao IP Multicast, faz com que muito poucos PSIs forneçam conectividade multicasting para usuários domésticos.
2.9.2 MULTICAST NA CAMADA DE APLICAÇÃO
Multicast na Camada de Aplicação (ALM - Application Layer Multicast) é uma atraente alternativa ao multicast na camada de rede por questões de gerenciamento (configuração e controle) e por dispensar qualquer modificação na infra-estrutura básica da rede.
Em ALM, uma sobre-camada de rede é construída no topo de serviços de redes disponíveis e pacotes unicast são encaminhados entre sistemas finais através de uma aplicação. O modelo é organizado de forma que cada sistema final participante (membro) é responsável por entregar pacotes de dados a um subconjunto de participantes que estão ligados a ele por meio de alguma regra. A esse subconjunto de participantes chamamos de participantes vizinhos.
Protocolos ALM são construídos de forma a atender aplicações específicas, e características como escalabilidade, tolerância a falhas, forma de transmissão das mensagens e métricas para o desempenho devem ser levadas em consideração na construção do protocolo.
2.9.2.1 TOPOLOGIA DE CONTROLE/DADOS E GERENCIAMENTO DE GRUPO
Protocolos ALM organizam seus grupos de membros dentro de duas topologias, a topologia de controle e a topologia de dados. Na topologia de controle, mensagens de atualização de estado são trocadas ou entre membros exclusivamente ou entre membros e um dado nó central. Se essas mensagens são trocadas entre membros exclusivamente, então os próprios membros são responsáveis por identificar e tratar possíveis partições dentro do grupo, caracterizando um gerenciamento de grupo distribuído. NICE (BANERJEE, 2002a), NARADA (CHU, 2000), Scribe (CASTRO, 2002), CAN Multicast (RATNASAMY, 2001b), Bayeux (ZHANG, 2001) são exemplos de protocolos ALM que utilizam gerenciamento de grupo distribuído. Caso as trocas dessas mensagens ocorram entre membros e um nó central, dizemos que trata-se de um gerenciamento de grupo centralizado, onde o nó central é responsável por identificar e tratar possíveis partições dentro de um determinado grupo. ALMI (PENDAKARIS, 2001), CoopNET (PADMANABHAN, 2002), AMCast (SHI, 2002), RMX (CHAWATHE, 2000), HBM (ROCA, 2001) são protocolos ALM que utilizam gerenciamento de grupo centralizado. Partições em um grupo podem ocorrer devido a saída de um membro sem qualquer notificação (mensagem de sinalização) aos membros vizinhos ou a um nó central e um protocolo ALM deve implementar algum mecanismo de recuperação da partição, caso ela ocorra. A topologia de dados em geral é um subconjunto da topologia de controle e identifica o caminho de dados que uma mensagem multicast deve percorrer na sobre-camada de rede. O caminho de dados se dá por meio de uma árvore individual a cada origem ou por uma árvore compartilhada entre os membros participantes do grupo.
Em NARADA (CHU, 2000), a topologia de controle é dada pela construção de uma malha a partir de seus membros participantes. Essa malha é construída segundo métricas de interesse da aplicação. Membros dentro da malha possuem uma quantidade limitada de vizinhos. Já a topologia de dados é dada por uma árvore individual construída a cada origem de dados. Essa árvore é construída com base na malha da topologia de controle. Para isso, no NARADA, cada origem utiliza-se de um algoritmo de roteamento de vetor-distância e a árvore é construída no menor caminho reverso entre cada membro e a origem de forma semelhante ao protocolo de roteamento multicast DVMRP (WAITZMAN, 1998). O NARADA possui gerenciamento de grupo distribuído, cada membro dentro da malha é responsável pela atualização de estados em seus vizinhos.
FIG. 2.5 Topologia de controle e topologia de dados em NICE
Em NICE (BANERJEE, 2002a), membros são organizados em conjuntos dentro de um controle topológico hierárquico. A hierarquia em NICE é criada pela assinatura dos membros em diferentes níveis (camadas) ilustrada na figura 2.4. As camadas são entidades lógicas sobre uma rede física. As camadas são numeradas seqüencialmente e a camada mais baixa da hierarquia é chamada camada zero (denotada por L0). Os membros em cada camada são agrupados em clusters. Cada
cluster tem tamanho entre k e 3k -1, onde k é uma constante, e consiste de um conjunto de membros que estão próximos entre si. Em cada cluster existe um membro líder. O líder do cluster é o membro que tem em média a menor distância de todos os demais membros do cluster. Todos os membros devem entrar em um grupo da mais baixa camada, L0. Os líderes dos clusters da camada Li devem entrar em
um grupo da camada Li+1 como ilustra a figura 2.4. Na topologia de controle,
membros de cada cluster trocam, entre si, mensagens periódicas de atualização de estado. Já na topologia de dados, a partir do controle topológico hierárquico, uma árvore é estabelecida a cada origem de dados, assim como no NARADA. Na figura 2.5 temos quatro clusters de tamanho 4, onde Ai, Bi e Ci são membros da camada L0. Os membros B0, B1, B2 e C0 são membros líderes de clusters na camada L0. C0
é o membro líder na camada L1. Nas figuras 2.5(b), 2.5(c) e 2.5(d) temos A0, A7 e
C0 como origem de dados respectivamente e as setas indicam o caminho de dados a percorrer para cada origem de dados.
Em ALMI (An Application Level Multicast Infrastructure) (PENDARAKIS, 2001), a topologia de controle é dada pela comunicação entre membros participantes ou membros de sessão e um nó central denominado Controlador de Sessão ou Rendevouz Point (RP). O RP é responsável por gerar árvores de tamanho mínimo (MST – Minimum Spanning Tree) a partir dos membros participantes, onde o custo de cada enlace depende de uma métrica específica por aplicação e cada enlace entre os membros na árvore é bi-direcional. Essa MST estabelece a topologia de dados e o caminho de dados é dado pelo compartilhamento da MST entre os membros participantes. A figura 2.6 representa a estrutura ALMI.
O RP deve registrar os membros participantes e manter a MST, assegurando sua conectividade quando membros entram, deixam a sessão ou quando a rede e/ou os nós membros falham. O RP também deve manter a eficiência da MST através de cálculos periódicos e de mensagens periódicas que atualizam suas medidas a todos os membros.
ALMI aborda um gerenciamento de grupo centralizado para manter a árvore consistente e eficiente. O RP está presente somente no caminho de controle, deixando o caminho de dados livre para troca de dados entre membros da sessão.
2.9.2.2 TAMANHO DO GRUPO E ÁREA DE APLICAÇÃO
Protocolos ALM são construídos com base nas aplicações a que eles se destinam. Suas características são definidas de acordo com as necessidades das aplicações.
As aplicações para fluxo de áudio/vídeo (exemplo, difusão de rádio e tv na Intenet) em geral envolvem uma única origem para distribuição de mídia e uma grande quantidade de clientes receptores. Tanto mídias de fluxo em tempo real quanto mídias de fluxo sob demanda são exemplos dessas aplicações. NICE (BANERJEE, 2002a), ZIGZAG (TRAN, 2003), Spreadlt (DESHPANDE, 2001), CoopNet (PADMANABHAN, 2002), TAG (KWON, 2002), HMTP (ZHANG, 2002), AMCast (SHI, 2002), OMNI (BANERJEE, 2003), RITA (XU, 2003), Bayeux (ZHUANG, 2001), SplitStream (CASTRO, 2003), Bullet (KOSTIC, 2003) são protocolos construídos com base nessas aplicações. Esses protocolos têm em comum a utilização do atraso e ou a largura de banda como métricas para construção da topologia de dados e a transmissão de dados é baseada em uma única fonte com destino a múltiplos receptores.
Aplicações para áudio-conferência e ou vídeo-conferência pertencem a uma outra classe de aplicações. Em geral são constituídas a partir de pequenos e médios grupos de participantes que interagem em uma sessão de conferência. Nessas aplicações, um alto grau de interatividade é exigido e cada participante tem o potencial de enviar e receber dados, ou seja, nessas aplicações contamos com
múltiplas fontes e múltiplos destinos. Narada (CHU, 2000), ALMI (PENDAKARIS, 2001), HBM (ROCA, 2001), HostCast (LI, 2003) são protocolos construídos com base nessas aplicações.
Aplicações para simulações distribuídas de grande escala formam uma classe constituída por um grande número de participantes, onde cada participante é uma origem de dados, interagindo simultaneamente. Assim, essas aplicações exigem transmissões de dados muitos-para-muitos. Jogos massivos com múltiplos participantes e aplicações para AVC de grande escala são exemplos dessas aplicações. Nessas aplicações o atraso é considerado a principal métrica na topologia de dados. YOID (FRANCIS, 1999), TBCP (MATHY, 2001), Delaunay (LIEBEHERR, 2002), Scribe (CASTRO, 2002) e CAN Multicast (RATNASAMY, 2001b) são protocolos construídos para esses fins.
Aplicações para entrega de informações (push applications) constituem outra classe também formada por um alto número de participantes que podem estar assinando uma variedade de canais de informação. Cada canal de informação é uma origem de dados. Para essas aplicações, a métrica de maior importância é a largura de banda na construção da topologia de dados. OverCast (JANNOTTI, 2000) e RMX (CHAWATHE, 2000), são protocolos que dão suporte a essa classe de aplicação.
2.10 RESUMO
Neste capítulo consideramos a influência da rede sobre os AVCs e a importância de conceitos como largura de banda, latência e confiabilidade na construção de AVCs. Além disso, estabelecemos um estudo sobre os protocolos de transportes, o protocolo de rede e dos tipos de comunicação no suporte as aplicações AVCs de grande escala, permitindo uma escolha adequada desses aos AVCs de grande escala.
Grande parte das arquiteturas AVCs utilizam multicast na camada de rede como principal tipo de comunicação. Sua baixa difusão tornou o multicast na camada de aplicação uma atraente alternativa ao suporte a AVCs.
3 AMBIENTE VIRTUAL COLABORATIVO
3.1 REALIDADE VIRTUAL
A Realidade Virtual (RV) pode ser definida como uma técnica de interface, onde o usuário pode realizar imersão, navegação e interação em um ambiente sintético tridimensional gerado por computador (BURDEA, 1994). Com aplicação na maioria das áreas do conhecimento e com um grande investimento nas indústrias de produção de hardware, software e dispositivos de E/S (entrada e saída) especiais, a RV vem experimentando um desenvolvimento acelerado nos últimos anos e indicando perspectivas bastante promissoras para os diversos segmentos vinculados com a área.
3.2 AMBIENTE VIRTUAL
A RV está cada vez mais presente nos meios computacionais. Técnicas de RV permitem que usuários acessem espaços virtuais, visualizando, manipulando e explorando os objetos neles contidos em tempo real a partir de recursos próprios, desde a movimentação tridimensional do corpo humano ou até mesmo por meio de utilização de periféricos como mouse e teclado.
Diversas definições sobre o conceito de ambientes virtuais podem ser encontradas na literatura. (HAND, 1996) define o termo Ambiente Virtual, como sendo qualquer mundo sintético (artificial) no qual um usuário possa interagir, não importando o paradigma da interface usada. Com essa definição, muitos sistemas podem ser considerados ambientes virtuais, desde um simulador de vôo a um editor de texto. (ENCARNAÇÃO, 1995) define ambientes virtuais como sendo ambientes interativos, em tempo real, que integram modelos tridimensionais com outra
informação multimídia e permitem uma sensação de imersão em mundos virtuais e a manipulação direta dos objetos que os compõem.
3.3 AMBIENTE VIRTUAL COLABORATIVO
Um Ambiente Virtual Colaborativo (AVC) é um tipo de ambiente virtual com suporte a realização de tarefas e ações que envolvam várias pessoas (HAND, 1996).
A tecnologia de Ambientes Virtuais Colaborativos tem o objetivo de aplicar realidade virtual em um espaço (mundo virtual) formado por uma rede de usuários permitindo que esses colaborem e compartilhem objetos entre si como se estivessem fisicamente em um mesmo local. Participantes desse ambiente possuem uma representação gráfica denominada “avatar” que associa uma identificação, uma localização e um estado no mundo virtual. Os avatares podem ser representados pelas mais variadas formas (um objeto, uma parte do corpo humano, um desenho animado, etc.). Participantes, interagem entre si e com o conteúdo do mundo virtual por meio de seus avatares e sua comunicação se dá através de diferentes mídias, incluindo áudio, vídeo, movimentações gráficas e texto.
Um AVC pode ser considerado como uma extensão da tecnologia RV para suportar múltiplos participantes. Essa extensão permite um melhor suporte a um determinado conjunto de aplicações. Aplicações para ensino a distância como em (RODRIGUES, 2004), treinamento cirúrgico (ALBÉRIO, 2005), treinamento em plataforma de petróleo (CADORIN, 2005) são exemplos dessas aplicações. Contudo, nesses tipos de aplicações não existem muitos participantes no ambiente virtual ao mesmo tempo. A necessidade de suportar tempo real entre um grande número de participantes simultâneos distribuídos geograficamente é um desafio às aplicações para AVCs especialmente com respeito à escalabilidade. Um grande número de participantes ativos pode gerar um alto volume de tráfego na rede, especialmente com atualizações de movimento, podendo comprometer a escalabilidade do sistema. Servidores na rede podem ter que processar esses dados, calcular e enviar uma cópia consistente do mundo virtual por meio de várias
mensagens de atualização. Cada participante do mundo virtual deve receber essas informações e ser capaz de processar e renderizar (criar de forma automática uma imagem, segundo o modelo tridimensional que se encontra no computador) o mundo virtual compartilhado em uma qualidade satisfatória. Propostas sugerem a definição de áreas de interesses destinadas a participantes através da divisão espacial do mundo virtual para ajudar a resolver o problema da escalabilidade em ambientes virtuais (MACEDONIA, 1994a) (MACEDONIA, 1995) (BARRUS, 1996).
3.4 ARQUITETURAS PARA AMBIENTES VIRTUAIS COLABORATIVOS
Aplicações direcionadas aos ambientes virtuais devem exibir três características de grande importância, a interação, a qualidade da imagem e o comportamento (TEIXEIRA, 1995). AVCs possibilitam que usuários geograficamente distribuídos interajam entre si e suas arquiteturas mais comuns são: SIMNET (POPE, 1989) e DIS (HOFER, 1995), historicamente usadas para treinamento militar, NPSNET-IV (CAPPS, 2000), PARADISE (PARADISE, 199-?), DIVE (CARLSSON, 1993a) (CARLSSON, 1993b), SPLINE (BARRUS, 1996), BrickNet (SINGH, 1995), VELVET (OLIVEIRA, 2003), entre outras, como propostas acadêmicas.
3.4.1 SIMNET E DIS
SIMNET (Simulator Networking) é um ambiente virtual distribuído construído com objetivos militares pela DARPA (Defense Advanced Research Projects Agency), Perceptronics e Delta Graphics (POPE, 1989). Seu projeto foi iniciado em 1983 e entregue no primeiro semestre de 1990 ao exército dos EUA. SIMNET teve como principal objetivo desenvolver um AVC (Ambiente Virtual Colaborativo) relativamente de baixo custo para treinamento de pequenas unidades de combate.
Três componentes básicos fazem parte da arquitetura de rede SIMNET. O primeiro componente é a arquitetura object-event, onde o mundo virtual é modelado
