Transmissão de estados em ambientes de realidade virtual distribuídos e colaborativos Tese de Mestrado em Engenharia Informática Elaborada por: Lic. Pedro Miguel da Fonseca Marques Ferreira Escola Superior de Tecnologia de Tomar Instituto Politécnico de Tomar / Sob orientação de: Prof. Doutor Fernando P.L. Boavida Fernandes Dep. Eng. Informática, FCTUC Co-orientação de: Prof. Doutor João Gilberto de Matos Orvalho Escola Superior de Educação de Coimbra DEI: ESTT:

2002STF2 Estrutura da apresentação  Realidade virtual  Transmissão de estados  Enquadramento anterior  CONCHA 2.0  STF: Status Transmission Framework  Testes à STF e resultados obtidos  Conclusões  Trabalho futuro

2002STF3 Realidade Virtual Tecnologias e protocolos  Tecnologias de visualização:  VRML  Java3D  3DML  OpenGL  DirectX / Direct3D  MPEG-4  QuickTime VR  MetaStream  Protocolos de comunicação:  TCP/IP  TCP  UDP  RTP/I  CORBA  JSDT  Protocolos específicos DVW:  VRTP  DWTP  DIS  Mu3D

2002STF4 Realidade Virtual VRML/WEB3D: Investigação  BIOTA  Formato binário comprimido  Interoperabilidade e conformância  Tecnologias para empresas e bases de dados  Simulação distribuída e interactiva  EAI  Animação humanóide  Input via teclado  Living Worlds  VRTP  Streaming VRML  Conteúdos  GeoVRML  Extensões orientadas a objectos  NLP e animações  Bibliotecas multimédia universais  Scripts VRML  Interacção multimédia / 3D  VRML - MPEG4  X3D / VRML-NG

2002STF5 Realidade Virtual Áreas de aplicação  Edição colaborativa  Visualização colaborativa  Mundos virtuais  Jogos interactivos  Telemedicina  Simulações do mundo real  Engenharia de processos de fabrico  Comércio electrónico

2002STF6 Transmissão de estados Problemas, requisitos  Tipo de média:  Interactivo distribuído:  Contínuo  Discreto  Problemas:  Transmissão e recepção  Replicação  Consistência  Particionamento  Junção tardia  Sincronização temporal  Requisitos CVE/DVW:  Requisitos técnicos  Requisitos de segurança  Partilha de dados  Baixa largura de banda e latência  Heterogeneidade da rede  Interacções distribuídas  Tolerância a falhas  Escalabilidade

2002STF7 Transmissão de estados Particionamento, sincronização  Particionamento:  Espacial:  GRID  LOD  BSP  Células e portais  Caixas limite (Bounding boxes)  Técnicas específicas para mundos virtuais multiutilizador:  Filtragem  Locales e Beacons  Aura  Sincronização temporal:  Características  Sincronização absoluta impossível  Fonte de tempo externa  Atrasos de rede  Mecanismos e algoritmos normalmente complexos  Requisitos  Concordância  Precisão  Protocolos e algoritmos  Software (NTP,SNTP)  Hardware

2002STF8 Transmissão de estados Consistência, local lag  Consistência:  Aproximações:  Pessimistas  Floor control  Locking  Optimistas  Dead reckoning  Local lag  Reparação de inconsistências de curto prazo:  Previsão e transmissão de estados  Requisição de estados  O algoritmo de timewarp  Local lag:  Redução de inconsistências de curto prazo  A execução da operação é atrasada por um determinado período de tempo T  T = Tempo de lag local (local lag)  Marca de tempo da mensagem > Tempo em que esta é emitida pelo utilizador  Problema:  Estimar o valor correcto para o lag local (T)

2002STF9 Transmissão de estados Dead reckoning  A aplicação conhece o comportamento do objecto “por defeito”, na ausência de mensagens  A aplicação prevê o estado do objecto, caso não receba mensagens sobre este  Caso uma mensagem seja recebida que altere o estado do objecto, este é corrigido  Algumas desvantagens:  Não permite verdadeira colaboração  Pode causar bastantes inconsistências de curto prazo  Necessita de largura de banda

2002STF10 Transmissão de estados Timewarp  Cada participante:  Grava o estado do mundo virtual de tempos a tempos  Regista todas as alterações efectuadas desde aí  Caso exista uma inconsistência de curto prazo, esta é corrigida:  O estado do mundo virtual é recuperado do último gravado  Todas as operações são repetidas até à operação imediatamente anterior à que causou a inconsistência  Algumas desvantagens:  Gasta bastante memória e espaço em disco  Necessita de lógica aplicacional complexa

2002STF11 Enquadramento anterior CONCHA 1.0  Sistema de gestão de conferências baseado em Java, JSDT e CORBA  Baseado em dois serviços nucleares:  Gestão de conferências  Baseado nas recomendações ITU T.124 (através do uso do JSDT)  Comunicação multiponto para as aplicações  Baseado na norma ITU T.122  Baseado numa topologia em árvore, com nós proxy e nós terminais  Utiliza canais JSDT ou CORBA

2002STF12 Enquadramento anterior ARMS  Plataforma de middleware para difusão de eventos  Compatível com o serviço de eventos CORBA padrão  Suporta comunicação multicast de eventos  Utiliza o protocolo LRMP  Suporta parametrização de QoS - Quality of Service  Possibilita comunicação com diferentes níveis de QoS por mensagem:  Não fiável  Não fiável com notificação de perdas  Não fiável com notificação de perdas e ordenação  Fiável

2002STF13 O novo sistema CONCHA 2.0  Evolui o CONCHA 1.0 nos seguintes pontos:  Arquitectura mais modular  Sistema mais extensível  Utilização de Java 2 (1.3) e a API Swing  Interface para aplicações transparente em relação ás tecnologias de comunicação  Adicionado suporte para applets  Adicionado servidor dedicado  Integração ARMS transparente para as aplicações  Suporte a JDBC mais transparente  Evolução para JSDT 2.0

2002STF14 Status Transmission Framework API para transmissão de estados  A API fornece interfaces para mecanismos de:  Transmissão de estados  Recepção de estados  Suporte a junção tardia  Particionamento do mundo virtual  Definição de chaves  Definição e classificação de estados  Sincronização temporal interna  Tratamento e sinalização de timewarps  Geração de dados estatísticos para testes

2002STF15 Status Transmission Framework Transmissão de estados  Streams de interacção:  Sequências de STFStateMessage (mensagens de estado), que inclui, entre outros:  Chave do estado  Estado propriamente dito  Marca de tempo  Prioridade  Classificação de estados:  Quanto a redundância  Redundantes  Essenciais  Quanto a volatilidade  Volátil  Não volátil  Quanto a junção tardia  Cumulativos  Independentes

2002STF16 Status Transmission Framework Transmissão de estados Lags de recepção e transmissão

2002STF17 Status Transmission Framework Sincronização temporal Sincronização temporal: Exemplo para 3 nós: 2 clientes 1 servidor Processo de votação: Exemplo para 3 nós: 2 participantes 1 candidato (iniciador)

2002STF18 Status Transmission Framework Junção tardia  Arquitectura:  Distribuída  Replicada  Tolerante a falhas  Mecanismo  Activado se necessário  Automático

2002STF19 Status Transmission Framework Junção tardia Processo de junção tardia: Exemplo para 3 nós: 2 servidores 1 cliente (Nó que se junta)

2002STF20 Status Transmission Framework Junção tardia  Identificação única de mensagens previne repetição da mesma mensagem no mesmo servidor replicado  Identificador único de mensagem de estado:  Nó de origem  Tempo de início de sessão no nó de origem  Número de sequência da mensagem no nó de origem

2002STF21 Status Transmission Framework Aplicações desenvolvidas  Aplicações exemplo com suporte a junção tardia:  Chat  Whiteboard  Aplicação de testes intensivos  Permite controlar parâmetros de:  Streams de interacção  Transmissão  Recepção  Sincronização temporal  Junção tardia

2002STF22 Status Transmission Framework Sincronização dos testes Sincronização distribuída dos testes intensivos Funciona para qualquer número de nós em teste maior do que dois Diagrama de sequência UML para três nós em teste:

2002STF23 Status Transmission Framework Testes efectuados  Testes funcionais  Aplicações exemplo  Chat  Whiteboard  Testes de desempenho  Aplicação de testes intensivos  Testes intensivos à:  Transmissão e recepção de estados  Junção tardia  Sincronização temporal

2002STF24 Testes à STF Plataforma de testes Software instalado: Windows 2000 Professional Java Software Development Kit 1.3, da Sun Microsystems e o Java Shared Data Toolkit 2.0 NTPTime Hardware: A- Tejo e B-Sado: Pentium III 733Mhz 128 MB de memória RAM C-Concha Pentium III 500Mhz 128 MB de memória RAM Rede: Ligações ethernet full-duplex a 100Mbit Computadores interligados por um switch

2002STF25 Testes à STF Pontos de recolha de dados Nº de mensagens em (B) = Nº de mensagens em (C) A: Processadas B (=C): Transmitidas D: Recebidas

2002STF26 Testes à STF Testes de transmissão  3 Streams de interacção simultâneas:  Stream 1: Estados redundantes, voláteis e independentes.  Stream 2: Estados redundantes, não voláteis e independentes.  Stream 3: Estados essenciais, não voláteis e independentes.  Prioridade de mensagens: Highest  2 séries de testes  Testes de ritmo de transmissão  Fixa tamanho do estado, varia ritmo de transmissão  Testes de tamanho do estado  Fixa ritmo de transmissão, varia tamanho do estado

2002STF27 Testes à STF Testes de transmissão  Teste de ritmo de transmissão  Tamanho do estado 22 bytes, chave 6 bytes (total 28 bytes)  Ritmo inicial 5 m/s por cada stream  Passos de 5 m/s por cada stream  Paragem a 400 m/s por cada stream = 1200 m/s total  Paragem forçada se atingido atraso superior a 1 segundo  Teste do tamanho do estado  Ritmo fixo a 200 m/s por cada stream = 600 m/s total  Tamanho inicial do estado = 22 bytes  Passos de 100 bytes  Paragem forçada se atraso superior a 1 segundo

2002STF28 Testes à STF Testes de transmissão  Cada teste individual correu durante 20 segundos  Lags de recepção e transmissão foram desactivados  Sincronização temporal interna desactivada  Mecanismo de suporte a junção tardia desactivado  Os computadores foram externamente sincronizados via NTP

2002STF29 Testes à STF Testes de transmissão

2002STF30 Testes à STF Testes de transmissão

2002STF31 Testes à STF Testes de transmissão

2002STF32 Testes à STF Testes de transmissão  Resultados sobre JSDT e sobre ARMS semelhantes  Atraso de recepção médio sempre menor que 25 ms  Atraso de recepção médio normalmente menor que 20 ms  Alvo de 400 m/s atingido sem dificuldades  Tamanho do estado não prejudica gravemente o ritmo de transmissão  Mensagens descartadas da forma prevista  Eficiente utilização dos recursos de rede

2002STF33 Testes à STF Testes de junção tardia  3 Streams de interacção simultâneas:  Stream 1: Estados redundantes, voláteis e independentes.  Stream 2: Estados redundantes, não voláteis e independentes.  Stream 3: Estados essenciais, não voláteis e independentes.  Prioridade de mensagens: Highest  2 séries de testes (tamanho do estado fixo)  Testes de ritmo de transmissão  Fixa ritmo de checkpointing, varia ritmo de transmissão  Testes do ritmo de checkpointing  Fixa ritmo de transmissão, varia ritmo de checkpointing

2002STF34 Testes à STF Testes de junção tardia  Teste de ritmo de transmissão  Ritmo inicial 5 m/s por cada stream  Passos de 5 m/s por cada stream  Paragem a 400 m/s por cada stream = 1200 m/s total  Teste do tamanho do estado  Ritmo fixo a 200 m/s por cada stream = 600 m/s total  Ritmo de checkpointing:  Inicialmente 1 segundo  Terminou em 20 segundos  Incrementos de 1 segundo

2002STF35 Testes à STF Testes de junção tardia  Tamanho do estado 22 bytes, chave 6 bytes (total 28 bytes)  Cada teste individual correu durante 20 segundos  Lags de recepção e transmissão foram desactivados  Sincronização temporal interna desactivada  Os computadores foram externamente sincronizados via NTP  Checkpointing local  Timeout de junção tardia:  2 segundos

2002STF36 Testes à STF Testes de junção tardia

2002STF37 Testes à STF Testes de junção tardia

2002STF38 Testes à STF Testes de junção tardia  Mecanismo de suporte a junção tardia possui um efeito na eficiência da STF:  Não negligenciável  Negativo  Mais negativo com o aumento do ritmo de transmissão  Menos negativo quanto maior for o ritmo de checkpointing  Os resultados são semelhantes sobre JSDT e sobre ARMS

2002STF39 Testes à STF Testes de sincronização  3 Streams de interacção simultâneas:  Stream 1: Estados redundantes, voláteis e independentes.  Stream 2: Estados redundantes, não voláteis e independentes.  Stream 3: Estados essenciais, não voláteis e independentes.  Prioridade de mensagens: Highest  3 séries de testes (tamanho do estado fixo)  Testes de ritmo de transmissão  Testes do ritmo de heart beat  Teste do mecanismo de cálculo do atraso de rede

2002STF40 Testes à STF Testes de sincronização  Tamanho do estado 22 bytes, chave 6 bytes (total 28 bytes)  Cada teste individual correu durante 5 minutos  Lags de recepção e transmissão foram desactivados  Mecanismo de suporte a junção tardia desactivado

2002STF41 Testes à STF Testes de sincronização

2002STF42 Testes à STF Testes de sincronização

2002STF43 Testes à STF Testes de sincronização

2002STF44 Testes à STF Testes de sincronização  Os resultados são semelhantes sobre JSDT e sobre ARMS  O relógio virtual mantém sincronizado, com ajustes abaixo dos 4 ms  Com um ritmo de transmissão de até 5000 m/s  Outras conclusões:  Quanto maior o intervalo de heartbeat, maiores os ajustes  Intervalo de cálculo de atraso de rede não influencia grandemente o mecanismo  Número de processos de votação baixo, servidor de tempo muda bastante raramente

2002STF45 Conclusões  A camada de middleware STF funciona adequadamente  A STF resolve os seguintes problemas de manuseamento de estados:  Transmissão e recepção mantendo consistência  Particionamento do mundo virtual  Junção tardia distribuída  Sincronização temporal  A STF encontra-se preparada para ser utilizada em aplicações reais

2002STF46 Trabalho futuro  Novos testes  Novas optimizações  Integração com novas versões do ARMS  Suporte a outros tipos de média  Maior suporte ao algoritmo de timewarp  Desenvolvimento de mais aplicações  Implementação da STF em C++  Integração Java3D / OpenGL / Direct3D  Investigação e teste: Novos algoritmos, etc.