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

a partir de uma coleção de objetos que interagem entre si. Essas interações constituem o que chamamos de eventos. Eventos são mensagens de rede que significam mudanças no mundo virtual ou no estado dos objetos. O segundo componente é a utilização da noção de nós autônomos. A idéia de nós autônomos significa que cada nó participante do mundo virtual é responsável por manter o estado de um ou mais objetos pertencentes ao mundo virtual. O terceiro componente trata-se de um conjunto bem definido de algoritmos de modelagem preditiva chamados dead reckoning. No início do projeto SIMNET, cada mudança de estado de um objeto acarretava em envios de pacotes de atualização para todos os nós da rede. Dessa forma, movimentações constantes de objetos poderiam inundar a rede com pacotes de atualização e provocar overhead nas CPUs. Com o intuito de reduzir a quantidade de pacotes de atualizações transitando na rede, foi criado o paradigma objects and ghost. O Dead reckoning é implementado utilizando esse paradigma, onde cada objeto é controlado por um único nó e um objeto espelho chamado ghost está presente em todos os nós do mundo virtual. Todos os objetos predizem seu movimento por meio de algum algoritmo de predição. Quando há um erro de predição maior que um limiar predefinido, uma mensagem de atualização é enviada para todos os nós a partir do nó responsável pelo objeto, corrigindo assim sua posição e estado. Outro meio de atualização do objeto ghost é o envio periódico de mensagens de atualização (MILLER, 1995).

Os criadores do SIMNET não definiram o formato dos pacotes e a arquitetura de software de rede utilizada de forma clara para que outros pesquisadores pudessem utilizá-los. Colaborações foram feitas para estender e documentar o protocolo SIMNET. Essas colaborações originaram o chamado DIS (Distributed Interactive Simulation) (HOFER, 1995), padrão IEEE (Internet Engineering Task Force) 1278.

O DIS sendo uma arquitetura derivada do SIMNET, conta com os mesmos três componentes básicos citados anteriormente. O ponto central de sua arquitetura são suas PDUs (Protocol Data Units). O DIS definiu 27 diferentes PDUs, porém, somente 4 PDUs (entity state, fire, detonation, e collision) são usadas para interação entre os nós no ambiente virtual. A PDU entity state contém informações sobre mudanças de posição, orientação e velocidade, a PDU fire contém informações sobre o disparo de uma arma, a PDU detonation contém informações de explosão de uma munição ou avaria/destruição de um veículo e a PDU collision contém informação de colisão de

um veículo. Sistemas compatíveis com o DIS preocupam-se em implementar apenas essas 4 PDUs (IEEE, 1993).

3.4.2 NPSNET-IV

NPSNET-IV (CAPPS, 2000) foi desenvolvido em 1995 pelo Departamento de Ciência de Computação da Naval Post-graduate School em Monterey na Califórnia. Versões anteriores como o NPSNET-I e II foram baseadas em tecnologia ethernet para redes locais, e seu ambiente restrito a poucas estações (MACEDONIA, 1994b). O NPSNET-I e II não fizeram uso do dead reckoning, em vez disso, pacotes de atualização inundavam a rede para atualizar os nós participantes do mundo virtual. NPSNETStealth foi um aprimoramento do NPSNET-1 e desenvolvido para ser compatível com o SIMNET (MACEDONIA, 1994b).

O NPSNET-IV foi projetado para ser compatível com o DIS 2.0.3 e utilizar-se do paradigma dead reckoning. O NPSNET foi o primeiro ambiente virtual a ser capaz de utilizar grupos multicasting da Internet para cada seção do mundo virtual. O NPSNET-IV inclui avanços como o uso de IP multicast com grupos multicast dinâmicos (MACEDONIA, 1994b).

O NPSNET-IV divide seu mundo virtual em células de tamanhos fixos em formato hexagonal (MACEDONIA, 1995). Cada hexágono associa um grupo multicast próprio. Cada objeto estará localizado dentro de um hexágono e cada hexágono poderá possuir até seis outros hexágonos como vizinhos. Um objeto ao entrar em uma das células hexagonais estará assinando o grupo multicast a ela associado e o grupo multicast associado ás demais células vizinhas. Ao movimentar- se, o objeto poderá se deslocar para apenas um dos seus hexágonos vizinhos, limitando o número de hexágonos a ser tratado (máximo de sete) para cada objeto. Um movimento entre células levará o objeto a assinar até três novos grupos multicast e retirar a assinatura de até outros três. Na figura 3.1, temos a representação de um objeto fazendo uma movimentação entre células.

A divisão do mundo virtual em partes permite a redução da carga computacional nas estações, redução das trocas de informações na rede e o aumento da escalabilidade do sistema.

Atualmente o grupo NPSNET está trabalhando em uma nova versão, o NPSNET-V, utilizando Java como plataforma para um ambiente extensível dinamicamente podendo adicionar novas capacidades em tempo de execução. Módulos físicos, gráficos ou de rede podem ser adicionados ao ambiente enquanto a aplicação está em execução, sem que seja necessário parar e iniciar a aplicação (CAPPS, 2000).

FIG. 3.1 Movimento de um objeto entre os hexágonos em NPSNET-IV

3.4.3 PARADISE

O projeto PARADISE (Performance ARchitecture for Advanced Distributed Interactive Simulation Environments) foi iniciado em 1993 por David Cheriton, Sandeep Singhal, e Hugh Holbrook (PARADISE, 199-?). O objetivo do projeto foi construir um ambiente de simulação de grande escala que possa suportar interações

PARADISE foi projetado para reduzir a utilização da banda do sistema. O sistema PARADISE utiliza IP multicast e cada objeto ativo deve assinar um diferente endereço multicast. Atualizações são feitas pelos nós para os objetos locais da mesma forma que o SIMNET e DIS. Para contribuir na redução da banda, servidores coletam informações em uma hierarquia da AoI (area of interest) de cada nó. Os servidores monitoram as posições dos objetos e notificam os nós sobre quais objetos do grupo multicast eles devem subscrever.

Diferentemente de SIMNET, PARADISE trata todos os objetos, incluindo o terreno, uniformemente como entidades de primeira classe. Cada objeto é capaz de transmitir atualizações de estado. Como melhoria ao DIS, o PARADISE diferencia entidades que contêm objetos que variam constantemente e precisam gerar atualizações freqüentes, de entidades que contêm objetos que variam pouco e raramente precisam enviar mensagens de atualização.

PARADISE suporta múltiplos e independentes fluxos por objetos, com cada fluxo permitindo dead reckoning remoto em diferentes níveis de exatidão (SINGHAL, 1995). PARADISE também se provê de técnicas para combinar informações sobre grupos de objetos, baseado em sua localização no mundo virtual e em seu tipo (SINGHAL, 1996).

3.4.4 DIVE

DIVE (Distributed Interactive Virtual Environment) foi desenvolvido no Laboratório de Sistemas Distribuídos do Instituto de Ciências e Computação da Suécia (CARLSSON, 1993a) (CARLSSON, 1993b). Sua arquitetura consiste de um conjunto de processos comunicando-se, rodando em nós distribuídos dentro de uma grande rede. Protocolos multicast são usados para a comunicação dentro dos grupos (BIRMAN, 1991). Os processos podem representar um usuário ou uma aplicação. Um processo atua no mundo virtual enviando mensagens para outros processos do mundo, além de modificar objetos e parâmetros. Um mundo virtual é implementado como um grupo de processos onde cada processo participante ativo gerencia sua própria réplica e guarda em memória uma cópia completa do banco de

dados. Não há servidor de banco de dados principal. Quando um membro une-se ao grupo, ele recebe de um outro membro uma cópia do banco de dados, no qual a consistência é garantida pelo uso de mecanismos de exclusão mútua e protocolos multicast confiáveis (HANGSAND, 1991).

3.4.5 BRICKNET

BrickNet é um trabalho de Gurminder Singh do Instituto de Sistemas e Ciência da Universidade Nacional de Cingapura (SINGH, 1995).

BrickNet adere a um modelo cliente-servidor, no qual o banco de dados é particionado entre os clientes. BrickNet permite aos objetos serem compartilhados por múltiplos mundos virtuais e permite também que os usuários configurem seu próprio espaço no mundo virtual, populando-o com objetos compartilhados e privados. Mundos Virtuais não estão restritos ao compartilhamento de conjuntos idênticos de objetos. Eles não possuem replicação de banco de dados como em SIMNET, DIS e DIVE. Em vez disso, BrickNet particiona o mundo virtual entre seus vários clientes. A figura 3.2 exibe o modelo cliente-servidor em BrickNet.

Comunicações entre objetos são mediadas por servidores. Um cliente pode se conectar a um servidor para solicitar objetos de seu interesse. Esses objetos são armazenados por outros clientes conectados no mesmo servidor ou outro servidor da rede. Dependendo da disponibilidade e direito de acesso ao objeto, o servidor satisfaz a solicitação do cliente. Interações em objetos distantes são feitas por um object-request corretor em um servidor que conhece a qual cliente o objeto distante pertence.

3.4.6 SPLINE

SPLINE (Scalable platform for Large Interactive Networked Environments) foi projetado pela MERL (Mitsubishi Electric Research Laboratories) (BARRUS, 1996). Sua plataforma provê uma arquitetura conveniente para implementar ambientes interativos multi-usuários baseados em um modelo do mundo compartilhado. O modelo do mundo é um object database que contém informação sobre tudo no mundo virtual – onde se encontram os objetos, suas aparências, os sons que fazem, etc. As aplicações interagem entre si, fazendo e observando mudanças no modelo do mundo virtual.

Em SPLINE o mundo virtual é dividido em áreas chamadas locales. Locales podem variar de tamanho e de forma. Desse modo, partições NPSNET podem ser consideradas um caso particular de locales, uma vez que seu mundo virtual é dividido em hexágonos de mesmo tamanho. Para cada locale é associado um grupo multicast. Cada locale define seu próprio sistema de coordenadas. Participantes que unem-se a um dado locale, recebem informação de todos os objetos pertencentes àquele locale e de seus vizinhos imediatos.

Para comunicação, o SPLINE utiliza o protocolo ISTP (Interactive Sharing Transfer Protocol) (WATERS, 1997). Apesar de ter sido construído junto com o SPLINE eles são completamente separados. O ISTP suporta vários modos de transporte para dados em realidade virtual do mesmo modo que o SPLINE pode suportar outros protocolos de transporte.

A figura 3.3 representa um modelo do mundo virtual dividido em 10 diferentes áreas (locales). As portas indicam vizinhanças entre locales. Os objetos no locale podem movimentar-se entre locales vizinhos.

FIG. 3.3 Modelo do Mundo divido em locales e a movimentação de um participante do mundo entre locales.

3.4.7 VELVET

VELVET (An Adaptive Hybrid Architecture for VEry Large Virtual Environments) (OLIVEIRA, 2003) é uma arquitetura híbrida adaptável que permite interação entre um grande número de usuários num AVC. O VELVET também suporta pequenos grupos de usuários, porém ele mostra melhor seu potencial em grandes grupos concentrados localmente. O VELVET introduz um novo tipo de AoI, uma área de interesse adaptável que suporta heterogeneidade entre diversos tipos de participantes, permitindo que um participante de uma rede de alta velocidade possa interagir com um participante que possui conexão discada (dial-up).

Arquiteturas como SPLINE e NPSNET permitem a divisão do mundo virtual nos chamados locales. Modelos baseados em locales assumem de alguma forma que seus usuários estarão dispersos uniformemente dentro do mundo virtual. Tal dispersão uniforme leva a uma redução na quantidade de dados processados por cada estação devido à diminuição da área de visão de cada participante. Porém, considerando que em um dado sistema todos os usuários estão localizados em uma mesma área de “visão”, como por exemplo, em um museu virtual onde todos os visitantes se propõem a visitar um mesmo quadro ao mesmo tempo, a idéia de divisão do mundo virtual para redução de carga computacional entre as estações irá falhar.

Outro problema ainda não resolvido é a questão de heterogeneidade entre estações. Soluções baseadas em espaço assumem que participantes estarão trabalhando com máquinas que tenham capacidade de processamento da carga computacional similares. Porém, é razoável pensar na existência de heterogeneidade entre estações na participação de um mesmo mundo virtual, ou seja, estações conectadas em redes de alta velocidade e estações conectadas por meio de conexão discada colaborando entre si em um mesmo mundo virtual. Nesse caso, para contornar tal problema, ou todos os sistemas encontram um desempenho mínimo ou todos os sistemas limitam o seu desempenho ao sistema de menor desempenho. As duas soluções são inadequadas: a primeira pode evitar que algum usuário possa unir-se à sessão AVC e a segunda nos leva à subutilização de recursos.

Em VELVET a área de interesse de um participante “avatar” pode ser aumentada ou reduzida dinamicamente, ou seja, em locais com uma grande concentração de participantes, um participante pode reduzir a sua área de interesse e conseqüentemente sua carga computacional. Por outro lado, se em sua área de interesse atual há pouca carga computacional, essa área pode ser expandida aumentando sua visão e otimizando a utilização de seus recursos.

Para solucionar o problema de heterogeneidade, O VELVET fornece um modelo no qual cada usuário possa receber informações do mundo virtual de acordo com sua capacidade computacional, esse modelo é chamado de Mundo Virtual Paralelo (MVP). Nesse modelo cada participante define sua área de visão do mundo virtual por meio de métricas como: número de participantes, largura de banda da rede,

distância no mundo virtual, distância na rede (número de saltos), atraso, ou qualquer combinação dessas; e de anéis que definem o grau (nível) da métrica escolhida pelo participante. Por exemplo, se um dado participante escolher a métrica número de usuários, esse participante poderá selecionar também o anel que irá utilizar e a sua regulagem (escolha) permitirá ao participante enxergar uma maior ou uma menor quantidade de outros participantes.

3.5 RESUMO

Neste capítulo descrevemos as características de algumas das diversas arquiteturas para AVCs. Foram apresentadas as principais entidades que compõem um mundo virtual, além de apresentar a idéia da divisão do mundo virtual em áreas como em NPSNET-IV (CAPPS, 2000) e SPLINE (BARRUS, 1996) bem como a utilização do multicast como principal tipo de comunicação para troca de informações no mundo virtual entre participantes na maioria das arquiteturas aqui descritas.

4 TRABALHOS RELACIONADOS

IP Multicast é um eficiente mecanismo para a entrega de pacotes em aplicações de transferência de dados um-para-muitos. No IP Multicast um sistema final não precisa guardar estados de outros sistemas finais no grupo o que é muito útil para escalar aplicações com múltiplos participantes. Entretanto a implementação do multicast na camada de rede não tem sido adotada amplamente pelos PSIs comerciais, tornando grande parte da Internet incapacitada ao suporte de multicast na camada de rede mesmo após de uma década de sua criação (DEERING, 1990). Protocolos ALM não alteram a infra-estrutura da Internet. Em vez disso, funcionalidades de encaminhamento multicast são implementadas diretamente nos sistemas finais. Multicast na camada de aplicação se tornou, portanto, uma atraente alternativa ao multicast original. Pesquisadores buscam encontrar e desenvolver protocolos ALM que atendam aplicações específicas. Dessa forma, os protocolos são construídos com características básicas diferentes, dando origem a diversas categorias de protocolos ALM. A categorização desses protocolos permite aos desenvolvedores escolher e implementar o protocolo ALM mais adequado à sua aplicação de uma forma 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 formados por um número médio ou pequeno de participantes. Por outro lado, aplicações que oferecem envio de fluxo de áudio/vídeo usualmente envolve 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. O que sugere suporte de protocolos ALM diferentes a diferentes aplicações.

Neste capítulo, abordamos duas áreas de pesquisas associadas a protocolos ALM que estão diretamente relacionadas ao nosso trabalho. Na primeira área abordaremos o trabalho de KNUTSSON (2004), o qual faz uso do protocolo ALM Scribe (CASTRO, 2002) no suporte a uma aplicação específica denominada SimMud (KNUTSSON, 2004). Em uma outra área de pesquisa, abordaremos o trabalho de BANERJEE (2002b) no qual faz uma categorização de alguns dos

diversos protocolos ALM existentes e compara algumas propriedades ALM a partir dessa categorização em uma tabela (BANNERJEE, 2002b).