Implementação De Opensimulator Com Funcionalidade De Voz Em Ambiente Empresarial

Transcript

Implementação de OpenSimulator com funcionalidade de voz em ambiente empresarial Jean-Louis do Canto Pereira Orientadores: Leonel Caseiro Morgado Pedro Miguel Mestre Alves da Silva Dissertação submetida à UNIVERSIDADE DE TRÁS-OS-MONTES E ALTO DOURO para obtenção do grau de MESTRE em Engenharia Electrotécnica e de Computadores, de acordo com o disposto no DR – I série–A, Decreto-Lei n.º 74/2006 de 24 de Março e no Regulamento de Estudos Pós-Graduados da UTAD DR, 2.a série – Deliberação n.º 2391/2007 1 2 Implementação de OpenSimulator com funcionalidade de voz em ambiente empresarial Jean-Louis do Canto Pereira Orientadores: Leonel Caseiro Morgado Pedro Miguel Mestre Alves da Silva Dissertação submetida à UNIVERSIDADE DE TRÁS-OS-MONTES E ALTO DOURO para obtenção do grau de MESTRE em Engenharia Electrotécnica e de Computadores, de acordo com o disposto no DR – I série–A, Decreto-Lei n.º 74/2006 de 24 de Março e no Regulamento de Estudos Pós-Graduados da UTAD DR, 2.a série – Deliberação n.º 2391/2007 3 4 Orientação Científica: Leonel Caseiro Morgado Professor Auxiliar Departamento de Engenharias Escola de Ciências e Tecnologia - ECT Universidade de Trás-os-Montes e Alto Douro Pedro Miguel Mestre Alves da Silva Professor Auxiliar Departamento de Engenharias Escola de Ciências e Tecnologia - ECT Universidade de Trás-os-Montes e Alto Douro 5 6 Resumo Este trabalho teve como objectivo a implementação de um servidor de mundos virtuais (OpenSimulator), com funcionalidade de voz no contexto da rede interna de uma empresa (podendo eventualmente permitir acesso a partir do exterior se pretendido). Assim, foi necessário ter em conta vários aspectos que rodeiam a presença de uma empresa num mundo virtual, tal como, possibilitar o uso de voz entre utilizadores OpenSimulator ou automaticamente reencaminhar chamadas para outros locais que não OpenSimulator, recorrendo a tecnologias por software como o GTalk ou softphones, caso a chamada por voz não fosse atendida dentro do mundo virtual. É ainda possível aos utilizadores usarem as suas contas OpenSimulator em softphones, ou seja, efectuarem chamadas para utilizadores que se encontrem no mundo virtual. Também se teve em conta aspectos relevantes em meio empresarial tais como a realização de cópias de segurança diárias, para permitir a recuperação de todos os dados do servidor em caso de falhas de software ou hardware; ou a necessidade de agilização de procedimentos quotidianos, tendo para o efeito sido desenvolvidas ferramentas que permitem a criação e manutenção de contas de utilizadores, bem como a gestão do servidor OpenSimulator através de um website. Palavras-chave: manutenção mundo virtual, OpenSimulator, voz, softphones, Gtalk, gestão, 7 8 Abstract The goal of this work was to implement a virtual worlds server (OpenSimulator) with voice functionality in the context of the internal network of a company (allowing external access when desired). It was therefore necessary to consider several issues surrounding the presence of a company in a virtual world, such as enabling the use of voice calls between OpenSimulator users or automatically forwarding calls to places other than OpenSimulator, using software technologies such as GTalk or softphones, in case a voice call is not answered within the virtual world. It is also possible for users to use their OpenSimulator accounts on softphones and make calls to users who are in the virtual world. Other aspects that were relevant to the company‟s operations were also addressed, such as the need to perform daily backups to allow recovery of all server data in case of software or hardware failure, or the need for streamlined daily procedures. To accomplish these objectives, tools were developed that allow the creation and maintenance of user accounts and the management of the OpenSimulator server through a website. Keywords: maintenance virtual world, OpenSimulator, voice, softphones, Gtalk, management, 9 10 Agradecimentos Institucionalmente, os meus agradecimentos ao Magnifico Reitor da Universidade de Trás-osMontes e Alto Douro, Professor Doutor Armando Mascarenhas Ferreira, ao Director do Mestrado em Engenharia Electrotécnica e Computadores, Professor Doutor Salviano Filipe Silva Pinto Soares pelas facilidades concedidas e meios colocados à disposição para a realização deste trabalho. Ao Professor Doutor Leonel Caseiro Morgado e ao Professor Doutor Pedro Miguel Mestre Alves da Silva, orientadores deste trabalho, pelas suas sugestões, ideias e orientações que permitiram a sua realização. Aos meus pais que sempre me deram força e amor, valorizando os meus potenciais. Á Isabel, por ser a pessoa que é, a companheira de todas as horas, demonstrando ao longo deste percurso uma confiança de que tudo iria correr bem e uma enorme paciência mesmo quando precisava de atenção. A todas as pessoas que, directa ou indirectamente, contribuíram para a execução desta dissertação. 11 12 Índice Resumo ............................................................................................................................. 7 Abstract ............................................................................................................................. 9 Agradecimentos .............................................................................................................. 11 Índice............................................................................................................................... 13 1 - Introdução .................................................................................................................. 15 1.1 – Contextualização ................................................................................................ 16 1.2 – Motivação .......................................................................................................... 17 1.3 – Objectivos .......................................................................................................... 18 1.4 – Identificação da metodologia ............................................................................. 19 1.5- Estrutura da dissertação ....................................................................................... 20 2 - Plataformas tecnológicas para mundos virtuais......................................................... 21 2.1 - Second Life Grid e Second Life ......................................................................... 23 2.2 – Multiverse .......................................................................................................... 25 2.3 – Croquet ............................................................................................................... 27 2.4 - Project Wonderland ............................................................................................ 29 3 - OpenSimulator e tecnologias de voz ......................................................................... 31 3.1 – OpenSimulator ................................................................................................... 31 3.2 - Tecnologias de voz em mundos virtuais............................................................. 35 3.2.1 – Vivox........................................................................................................... 35 3.2.2 – jVoiceBridge ............................................................................................... 37 3.2.3 - Comunicação por voz em OpenSimulator ................................................... 38 4 – Arquitectura e modelo de integração ........................................................................ 40 4.1 - Definição da arquitectura.................................................................................... 40 4.2 - Modelo de integração ......................................................................................... 41 4.2.1 - Requisitos Operacionais .............................................................................. 41 4.2.2 - Tecnologia utilizada .................................................................................... 43 4.2.3 - Modelo esquemático .................................................................................... 44 4.2.4 - Servidor OpenSimulator com FreeSwitchVoiceModule ........................... 46 4.2.5 - Website......................................................................................................... 50 4.2.6 - Cópias de segurança de OpenSimulator ...................................................... 52 4.2.7 - Deployment do OpenSimulator ................................................................... 52 5 – Testes e resultados .................................................................................................... 54 5.1 – Funcionamento do sistema ................................................................................. 54 5.1.1 - Instalação do OpenSimulator, Freeswitch, WampServer e website ............ 54 5.1.2 - Website – Utilizador .................................................................................... 55 5.1.3 - Website - Administrador .............................................................................. 59 5.1.4 – Softphone .................................................................................................... 61 5.2 - Testes, resultados e conclusões .......................................................................... 63 5.2.1 - Teste de desempenho ao website ................................................................. 63 5.2.1.1– Metodologia adoptada ........................................................................... 63 5.2.1.2- Condições de teste ................................................................................. 65 5.2.1.3 – Conclusão sobre o desempenho do website ......................................... 65 5.3.1 - Teste de desempenho ao servidor OpenSimulator .................................... 65 5.3.1.1– Metodologia adoptada ........................................................................... 65 5.3.1.2 – Condições de teste................................................................................ 69 13 5.3.1.3 – Conclusões sobre o desempenho OpenSimulator instalado................. 70 5.4.1 - Teste do servidor de voz Freeswitch ........................................................... 71 5.4.1.1 - Metodologia adoptada .......................................................................... 71 6 - Conclusões e trabalho futuro ..................................................................................... 72 6.1 – Conclusões ......................................................................................................... 72 6.2 - Trabalho futuro ................................................................................................... 73 7 - Referências ................................................................................................................ 74 14 1 - Introdução Os mundos virtuais multi-utilizador estão a enfrentar um crescendo de utilização, com milhões de utilizadores espalhados pelo mundo inteiro (Woodcock, 2008), e centenas de produtos comerciais disponíveis (Leal, 2007), incluindo muitos mundos com fortes exigências gráficas, tridimensionais, como o conhecido Second Life mas também mundos de jogos, como o World of Warcraft (Amaral, 2008). Estes espaços têm sido explorados por várias organizações, para usos tão diversos como contacto com potenciais clientes, divulgação de marcas, comércio electrónico e colaboração entre utilizadores ou parceiros comerciais (Book, 2008). Tendo em conta este último aspecto, os mundos virtuais também podem ser vistos como locais para realizar simulações de forma cooperativa, ou até para fomentar a comunicação entre utilizadores que normalmente se encontram separados no seu dia a dia. Assim, as tecnologias de mundos virtuais podem ser usadas para criar serviços e aplicações construídos com base em espaços virtuais, seja através de acordos de desenvolvimento com empresas de alojamento de espaços, ou através de software e de bibliotecas para conectar sistemas externos com estes mundos (OpenSimulator, 2009a). No entanto, um mundo virtual pode ser criado e personalizado a partir do zero, utilizando para tal várias plataformas tecnológicas (Damasceno et al., 2005), uma estratégia que as organizações podem adoptar para obter funcionalidades especiais ou para proporcionar espaços privados aos seus empregados. Esta última abordagem é a mais adequada ao fim a que esta dissertação se destina, uma vez que se pretende o controlo sobre o mundo virtual, no que respeita a aspectos de hardware e software, dentro da rede interna de uma empresa. O desenvolvimento de espaços virtuais existentes emprega combinações de elementos “world-side” (software executado pelos servidores do mundo virtual), elementos “client side” (software executado nos computadores dos utilizadores) e ainda elementos “exo-world”, software executado noutros servidores que não os do mundo virtual (Valério et al., 2009). De uma forma geral a arquitectura “client-side”/”world-side”/”exo-world” faz com que cada cliente mantenha uma ligação com o servidor de mundo virtual durante o tempo necessário à manutenção de uma “presença” nesse mundo. Durante esse tempo, o servidor alerta o cliente quanto a alterações que decorrem no mundo: por exemplo, a nível do estado das acções e dos movimentos efectuados pelo “avatar1” do cliente. Desta forma o servidor irá desempenhar uma função de policiamento, interpretando as intenções dos clientes e estabelecendo um estado para o conteúdo do mundo virtual, 1 Designação dada a um utilizador de um mundo virtual quando representado por um boneco tridimensional. 15 replicando várias vezes as informações sobre o estado do mundo (actualização de dados) em todos os clientes ligados ao mesmo servidor (Bainbridge, 2010). Os servidores “exo-world” poderão ser variados, como servidores Hypertext Transfer Protocol (HTTP) ou outros; contactáveis pelo software “client-side” e pelo software “world-side”, facultando informações a ambos ou podendo mesmo intervir no mundo, através de técnicas diversas que posteriormente serão apresentadas no capítulo 3. 1.1 – Contextualização O uso de mundos virtuais provoca a mudança a vários níveis e objectivos, quer estratégicos, tácticos ou operacionais numa empresa: a nível estratégico surge o aparecimento da virtualização da organização, assistindo-se a nível operacional a uma mudança na forma de trabalhar onde a nível táctico “os gráficos 3D tomam um papel importante, em conjugação com a Inteligência Artificial e a Orientação a Objectos para o desenvolvimento de novos artefactos para lidar com a informação.” (Gouveia, 2000). Possibilitam a partilha de áreas de trabalho, sendo que nestas os utilizadores partilham uma área comum podendo por exemplo expressar ideias e participar na construção de produtos, potenciando desta forma a interacção colaborativa, aprendizagem, criatividade ou até treinar possíveis simulações passíveis de acontecer no dia-a-dia da empresa (ibid.). Com o objectivo de implementar uma plataforma de mundos virtuais, surgem nesta dissertação as seguintes questões:    Que plataformas para mundos virtuais existem, nas quais se possa aplicar o que foi referido anteriormente? Dessas plataformas, quais permitem a integração com sistemas informáticos externos? Que meios de comunicação existem nessas plataformas? Será possível integrá-los com outros já existentes no meio empresarial? Assim através destas questões e de motivações pessoais, que serão explicadas em maior pormenor no capítulo seguinte, foram realizadas pesquisas onde se chegou à conclusão que a plataforma ideal para desenvolver este trabalho seria o OpenSimulator. 16 1.2 – Motivação O presente trabalho resulta de parte de um estágio profissional realizado numa empresa nacional de grande dimensão, enquadrando-se numa necessidade técnica manifestada por esta. O nome da empresa não é referido, por opção da mesma; no entanto interessa perceber quais as características desta empresa e em que ambiente e condições foi realizado este trabalho. Esta empresa foca-se no processo de inovação, que ocorre ao nível dos serviços, tecnologias e operações, e no desenvolvimento de competências nas disciplinas e sectores do mercado das telecomunicações e tecnologias de informação, dividindo-se em dois sectores principais: ● Serviços - Engenharia, Testes e Consultoria, Formação e Divulgação da Inovação; ● Projectos - Desenvolvimento de Sistemas e Serviços Integração de Soluções; - Estudos e Investigação Aplicada - aquisição de conhecimento É neste último sector, nomeadamente ao nível de Estudos e Investigação Aplicada, que se posiciona o departamento onde este trabalho foi desenvolvido, organizado em três linhas de investigação: ● Plataformas e redes multiserviço ● Aplicações colaborativas e serviços Web 2.0 ● Formação e e-learning A linha de investigação onde o estágio incidiu foi a de “Aplicações colaborativas e serviços Web 2.0”, cujos objectivos são: ● ● Conceber e desenvolver aplicações colaborativas baseadas em tecnologia Web promovendo a sua introdução nos diversos mercados alvo, nomeadamente: saúde, entretenimento e média. Efectuar experimentação no domínio da Web 2.0 e da sua evolução, particularmente em contextos Internet e Internet Protocol Television (IPTV), com ênfase nas questões associadas às redes sociais, modelos de negócio, recomendação e mash-up de conteúdo, design e usabilidade; ● Dinamizar a aquisição de conhecimento em torno de conceitos e tecnologias relevantes para o futuro da Web convergente, semântica, tridimensional (3D), ubíqua e centrada nos conteúdos, incluindo metadados, agentes, sensores e novos formatos e mecanismos de interacção e interactividade; ● Criar provas de conceito e realizar demonstrações que promovam visões da Internet do futuro, antecipando ameaças e oportunidades de negócio, identificando riscos tecnológicos e lançando desafios para a criação de novos produtos e serviços da empresa. 17 Tendo em conta estes objectivos, as actividades desenvolvidas ao longo do estágio profissional dividiram-se em quatro fases, sendo uma delas relacionadas com o trabalho de que é alvo esta dissertação. O principal objectivo por parte da empresa era o uso de um mundo virtual no seu ambiente empresarial, com algum trabalho realizado na área de Voice over Internet Protocol (VoIP), sem depender de outras organizações especializadas na área para se obter a comunicação por voz. Tendo em conta este aspecto também foi decidido estrategicamente, pela empresa, ter esse mundo virtual alojado nas suas instalações, a disponibilização e execução desta plataforma atrás da firewall. Esta solução permitiu ter privacidade, confidencialidade e controlo completo dos dados e conteúdo disponibilizados, assim como projectar um sistema de encaminhamento de voz próprio. Como não é possível criar espaços virtuais num servidor próprio, privado, em muitos dos mundos virtuais já existentes, analisaram-se vários projectos de desenvolvimento, isto é, plataformas tecnológicas, que o permitissem. Esta análise é feita no capítulo seguinte, indicando as vantagens e desvantagens de cada uma. Através destas análises, conclui-se que o OpenSimulator é o que melhor satisfaz os requisitos do projecto, pelo que se tentou entender as possíveis potencialidades, complexidades e formas de utilização deste servidor num ambiente de rede empresarial. Dentro desse contexto, outra motivação existente para este trabalho, foi o facto de ao longo dos últimos dois anos ter havido acompanhamento e investigação aos mundos virtuais que têm vindo a surgir; foram elaborados alguns trabalhos académicos relacionados com o mundo virtual Second Life, (Pereira et al., 2008; Valério et al., 2009), tendo esta experiência levado a um interesse em explorar a tecnologia que pode ser considerada o “Second Life de código-fonte aberto”, ou seja, a plataforma de servidor OpenSimulator. De salientar também que o OpenSimulator é uma tecnologia que concretiza uma tentativa de criar uma “Web de Mundos Virtuais”, por vezes chamada “metaverso” (Morgado, 2009). Aspecto actual dessa tentativa é a existência de uma associação de várias organizações (IBM, Linden Lab, Sun, Open Source Applications Foundation, Intel, Forterra, Croquet Consortium, Solipsis, entre outras), denominada MMOX Charter Group, integrada na Internet Engineering Task Force, cujo objectivo é a normalização dos protocolos de comunicação com mundos virtuais (Sequeira, 2009), para permitir a interoperabilidade entre estes. Trata-se de um factor importante a ter em conta, uma vez que o desenvolvimento em protocolos interoperáveis pode acelerar o crescimento e a adopção de mundos virtuais (Santos, 2008). 18 1.3 – Objectivos Para uma melhor execução do trabalho, o objectivo maior, gestão e manutenção do servidor 3D OpenSimulator, na rede interna da Empresa, com possibilidade de comunicação por voz entre os seus utilizadores para dentro e fora deste servidor) é seccionado em cinco objectivos para que ao longo do desenvolvimento do mesmo, as metas sejam cumpridas da maneira delineada. Assim o primeiro objectivo foi instalar o servidor OpenSimulator na rede interna da empresa. O segundo objectivo foi a adaptação da interface Web responsável pela gestão dos utilizadores do servidor, expandindo-lhe as funcionalidades de gestão remota do servidor. Uma vez cumpridos estes dois objectivos, foi necessário permitir o acesso imediato aos utilizadores da empresa, de forma a que pudessem ir-se adaptando e experimentando esta nova ferramenta, informalmente. O terceiro objectivo prendeu-se com o desenvolvimento de um sistema de backup automático do servidor OpenSimulator. O quarto objectivo foi permitir a comunicação por voz entre utilizadores do servidor OpenSimulator, não só entre eles, mas também de forma interligada com sistemas externos, nomeadamente com uso de softphones e do sistema de messaging Gtalk. Por fim, o quinto objectivo foi o desenvolvimento de formas de comutação entre alternativas tecnológicas de comunicação por voz. 1.4 – Identificação da metodologia Para a concretização dos objectivos estabeleceu-se uma metodologia para o projecto que teve como metas o cumprimento dos objectivos traçados, de maneira concisa, realizando uma união entre as teorias e estudos nas etapas de revisão, e a execução técnica do trabalho. A metodologia é aqui descrita por indicação das etapas que compõem o processo que a concretiza:  1ª Etapa – Estudar as plataformas tecnológicas para mundos virtuais e a partir delas enquadrar a opção tomada pela empresa – o OpenSimulator.  2ª Etapa – Estudar as características do OpenSimulator e, a partir delas, definir as condicionantes das aplicações a desenvolver;  3ª Etapa – Estudar as tecnologias de voz em mundos virtuais e a partir delas escolher uma adequada ao OpenSimulator. 19  4ª Etapa – Elaborar um modelo de integração tecnológica para as tecnologias e condicionantes identificadas nas etapas anteriores;  5ª Etapa – Projectar e implementar o sistema, validando-o com testes; As etapas apresentadas foram realizadas em sequência, tendo contudo por vezes havido necessidade de retroceder e refinar etapas prévias, para obter informações cuja necessidade só foi detectada em etapas posteriores. 1.5- Estrutura da dissertação A presente dissertação possui uma estrutura dividida em seis capítulos, sendo o primeiro esta introdução, que teve como foco identificar as variadas formas de usar e interagir com mundos virtuais; identificar os principais aspectos a controlar no que respeita à escolha de um mundo virtual específico. Contextualizámos, identificando as razões e a importância que nos levaram a encetar este trabalho. Por fim justificámos a escolha do OpenSimulator para este trabalho. O capítulo 2, “Plataformas tecnológicas para mundos virtuais”, encontra-se dividido em 4 secções, onde apresentamos os variados tipos de mundos virtuais explicando-se quais são os mais relevantes e porquê, sendo de seguida descritos com mais detalhe nos subcapítulos seguintes. No capítulo 3, “OpenSimulator”, apresentamos o OpenSimulator de forma detalhada, a nível de características e funcionamento, sendo que falamos também das tecnologias de voz disponíveis no mercado para mundos virtuais. No capítulo 4, “Arquitectura e modelo de integração”, apresentamos o estudo e reflexão das ideias que serviram de base para a arquitectura do sistema bem como o modelo que dele resultou. No capítulo 5, “Testes e resultados”, identificamos e apresentamos os testes realizados bem como os seus resultados. Por fim, no capítulo 6, “Conclusões e Trabalho Futuro” apresentamos uma reflexão sobre o resultado do trabalho desenvolvido, com as conclusões que dele extraímos, e lançamos sugestões de trabalho de investigação e desenvolvimento que tomam como ponto de partida o conteúdo desta dissertação. 20 2 - Plataformas tecnológicas para mundos virtuais Ao longo dos tempos tem-se verificado, quer por empresas quer por pessoas, um interesse crescente por mundos virtuais multi-utilizador, sendo estes já utilizados mundialmente por milhões de utilizadores (Woodcock, 2008). David Leal (2007) afirma que nos últimos anos se tem assistido ao nascimento de numerosos mundos virtuais baseados na Internet, sendo que alguns começaram a afastar-se do seu intuito inicial de entretenimento, visando actualmente um objectivo completamente diferente: serem uma forma de ampliar as possibilidades actuais dos sistemas de colaboração em tempo real. “Uma grande parte são classificados como MMORPG2, mas há vida para além do jogo nestes universos” (Amaral, 2008, p. 12). Existem cinco grandes categorias de utilização de mundos virtuais (ibid):    mundos sociais – espaços de socialização e de construção de comunidades virtuais; educação – existem vários espaços criados para propósitos educacionais e outros aproveitados para este fim; expressão política – os mundos virtuais podem servir como fóruns de expressão política e debate, mas esta categoria tanto serve para universos específicos da área como para uma adequação a outros espaços existentes;   treino militar – os mundos virtuais são também referenciados para desenvolver acções de simulação de treino militar; jogos comerciais (MMORPG). O exemplo mais proeminente da categoria de jogos comerciais é o World of Warcraft (Corneliussen et al., 2008), um MMORPG com 11 milhões de assinantes, sendo que esta categoria de mundo virtual concentra-se na vertente do jogo, no sentido que oferece objectivos e outro tipo de suporte à jogabilidade tais como: pontos, vida, níveis, missões. Surgiram outros mundos virtuais que optaram claramente por se centrarem na vertente de socialização e conversação entre utilizadores (Pereira et al., 2008b), como são exemplos o IMVU3 ou o Twinity4. 2 Massively Multiplayer Online Role-Playing Games http://www.imvu.com/ http://www.twinity.com/en 21 3 4 Mas existem ainda mundos que “são mais do que meros ambientes de chat tridimensional: os avatares que controlam e podem interagir com objectos e outro tipo de elementos presentes no mundo, organizam eventos, associações, actividades diversas. Estas acções podem ser de natureza imersiva, ou seja, cujo significado se esgota dentro do mundo virtual, mas podem igualmente ser aumentativas, ou seja, terem impacte na vida real dos utilizadores, utilizando o mundo virtual como ferramenta de comunicação e expressão.” (Pereira et al., 2008b). É exemplo o Second Life ou o MPK205, que não são de todo jogos, mas sim contextos de colaboração nos quais as pessoas podem criar objectos virtuais, modelar (visualizar e simular) ou criar grupos de trabalho, interagindo e ampliando o campo da comunicação humana. É este tipo de características que importa para o fim a que esta dissertação se destina: a implementação de um servidor 3D com funcionalidade de voz em ambiente empresarial. No caso do Second Life este recorre à plataforma Second Life Grid, que desde que tornou público o protocolo de comunicação entre servidores Second Life Grid (código-fonte privado) e o software cliente Second Life (código-fonte aberto) promoveu o aparecimento de uma plataforma alternativa denominada OpenSimulator, já referida e descrita no capítulo 3. Nesta plataforma é possível usar a mesma tecnologia de software-cliente que o Second Life (embora nem todas as funcionalidades dos servidores Second Life Grid estejam implementadas nos servidores OpenSimulator, por enquanto). A implementação do protocolo é facilitada pela existência da biblioteca libopenmetaverse6, em código-fonte aberto, que permite iniciar sessões de clientes em servidores e aceder às várias possibilidades do protocolo a mais alto nível, de forma simplificada. Assim os mundos virtuais construídos a partir das plataformas Second Life Grid/OpenSimulator partilham muitas características comuns, por usarem o mesmo protocolo: dividem o espaço virtual em regiões de 256 x 256 metros, permitem aos utilizadores controlar o seu ponto de vista ou "câmara" de forma independente do movimento do avatar, fornecem meios de acesso e de privacidade de voz em subdivisões da área virtual. As implementações subjacentes destas plataformas são diferentes, mas são habitualmente transparentes do ponto de vista do software-cliente (por exemplo, enquanto os servidores Second Life Grid armazenam alguma informação num servidor de ficheiros o OpenSimulator utiliza uma base de dados para o mesmo efeito, sendo que esta situação é transparente para o software-cliente) (Sequeira, 2009). 5 6 http://labs.oracle.com/projects/mc/mpk20.html Anteriormente conhecida por libSecondLife é uma biblioteca Cliente/Servidor desenvolvida em .Net que permite aceder e criar mundos virtuais 3D que implementam o protocolo Second Life (OpenMetaverse, 2009). 22 Já no caso do mundo virtual MPK20 este recorre à plataforma Project Wonderland7. Tal como acontece com a plataforma Second Life Grid é possível construir através desta mundos virtuais 3D colaborativos, assim como ter avatares e animações dentro destes. Esta plataforma foi criada desde o inicio com o propósito de ser instalada em servidores de uma rede local com vista à utilização em ambientes empresariais. De entre as suas características sobressai a comunicação por voz com alta-fidelidade, áudio imersivo, expansão (possibilidade de adição de novas funcionalidades) e a possibilidade de partilha de aplicações e documentos. Existem ainda outras plataformas, como a Open Croquet, tendo em comum com a Second Life Grid e com o Project Wonderland o armazenamento de todos os dados necessários em servidores remotos (no Open Croquet adopta-se uma topologia peer-to-peer de servidores, mas cada servidor “peer” é acedido igualmente por vários clientes), servidores remotos esses que depois transmitem dados aos clientes sob pedido. Serão analisados desta forma, nos próximos capítulos, os mundos virtuais anteriormente referidos, bem como as respectivas plataformas tecnológicas que asseguram o suporte; sendo que estes foram escolhidos devido à sua repercussão social, às possibilidades de trabalho corporativo, de comunicação entre utilizadores e de possibilidade de posse da própria máquina que aloja o software do servidor. 2.1 - Second Life Grid e Second Life A empresa norte-americana Linden Lab disponibiliza a plataforma Second Life Grid® (Linden Research, 2009a), para a criação de mundos virtuais persistentes e contíguos, possibilitando a criação do conteúdo tridimensional por parte dos utilizadores. Tal como foi dito anteriormente, a solução desta plataforma consiste em dividir o espaço virtual em regiões, cada qual com 256 x 256 metros sendo que toda a informação referente é enviada através de streaming implementado sobre UDP8, tolerando assim a falhas relacionadas com perda e chegada fora de ordem de pacotes (Fitzgerald, 2007). Ao conjunto de todas as regiões organizadas numa grelha bidimensional é dado o nome de “grid”, sendo que o conjunto destas resulta num espaço contíguo - onde o conteúdo e todos os utilizadores se ligam ao mesmo mundo a partir de qualquer ponto da grid – existindo a possibilidade de estar numa 7 https://wonderland.dev.java.net/ 8 User Datagram Protocol, protocolo que permite a comunicação entre computadores diferentes. É uma comunicação sem conexão que não garante a chegada dos pacotes em ordem particular. 23 região, ver e interagir com elementos que estão noutra, se ambas forem contíguas na grid. As regiões podem conter avatares ou objectos, sendo que estes últimos podem conter vários recursos, incluindo outros objectos. Entre esses recursos constam os scripts, código de programas que se executam inteiramente dentro do mundo virtual; os scripts são desenvolvidos na linguagem Linden Scripting Language, podendo ser utilizados de várias maneiras: dar comportamentos visuais aos objectos, interagir com os avatares e para processamento lógico-computacional diversificado, incluindo comunicação com sistemas exteriores ao mundo virtual, via Internet. Cada região é auto-suficiente; gere o conteúdo local (os objectos, texturas, programas, sons e animações que se encontram nessa região), verificando as posições ocupadas pelo conteúdo assim como as posições dos avatares que por lá se encontram e lida ainda com a comunicação entre avatares na mesma região (”chat público”). O software que faz a gestão de cada região é conhecido como simulador ou sim, normalmente correndo um por CPU (Sequeira, 2009). Esta plataforma suporta o mundo virtual Second Life, lançado na sua primeira versão ainda no ano de 2003 (Linden Research, 2009b). Os seus objectivos foram: a disponibilização de uma plataforma de alojamento, produção de conteúdo virtual e a interacção virtual entre utilizadores. Há que ter em conta que este tem sido dos mundos virtuais que mais se tem destacado nos últimos anos (Linden, 2009), com claro relevo na comunicação social, no esforço de investigação científica e utilização empresarial; devido às suas características de multimédia, imersividade, interactividade e colaboratividade, tendo ainda outras características específicas tais como a sua economia, dinâmica social e modelo de preços. A nível de custos (manutenção e alojamento) e comunicação com potenciais clientes será mais simples alugar uma ou várias ilhas privadas na grid do mundo virtual Second Life, uma vez que este se apresenta como plataforma para aplicações de divulgação de informação e interacção, tendo em conta que detém uma comunidade significativa de utilizadores reais (Linden, 2009), mas há que ter em conta que na criação de objectos o upload de certos elementos (texturas, sons, animações, etc.) não é gratuito, sendo uma má opção para testar texturas ou treinar a construção que envolva muitos componentes externos. Para além disso, o Second Life tem a desvantagem de ser dependente de uma única empresa, pois encontra-se alojado em servidores situados nas instalações da empresa Linden Lab, estando estes acessíveis a todos os utilizadores de Internet; é um facto a ter em conta, quando se pretende desenvolver um serviço próprio de mundo virtual com confidencialidade de dados, como é objectivo da empresa onde decorreu o trabalho de suporte a esta dissertação. 24 Do ponto de vista técnico, esta plataforma já demonstrou a capacidade para suportar grande número de utilizadores em simultâneo, tendo mesmo atingindo um pico de 88.200 utilizadores no Second Life (Linden, 2009). As limitações conhecidas até 2008 (Sequeira, 2009) eram de 15.000 primitivas geométricas (“prims”) por região, assim como 100 avatares por região, prendendo-se essencialmente com limitações do servidor e da sua largura de banda; cada avatar requer cerca de 30 a 100 kbps de largura de banda constante para manter-se em comunicação com uma região na Second Life Grid. De referir ainda que à data em que se começou a implementar o trabalho de que é alvo esta dissertação, a plataforma Second Life Grid era restrita ao acesso público; na altura a disponibilidade desta plataforma para outros mundos que não o Second Life estava em fase alfa, a ser testada em apenas em nove organizações, entre as quais, IBM, o Naval Undersea Warfare Center (NUWC), o New Media Consortium (NMC), a Intel e a Northrop Grumman (Linden, 2009). Agora já é possível adquirir o produto na sua totalidade, através do pagamento de uma licença de 55.000 USD (Linden Research, 2009c). 2.2 – Multiverse O Multiverse Network Ink é uma rede e uma plataforma para MMORPG, mundos sociais e educacionais assim como ambientes de negócios e colaboração (figura 1). Business Collaboration Spaces Mirror Worlds Social Games Sci-Fi Shooters Fantasy MMORPGs Educational Worlds Figura 1 – Aplicações da tecnologia Multiverse (De: http://www.multiverse.net/platform/index.jsp?cid=3&scid=0) 25 Foi criado por ex-funcionários da Netscape, tendo como objectivos apresentar-se como uma plataforma para programadores independentes, oferecendo melhores condições para divulgarem as suas plataformas e criações; outro objectivo foi o de fornecer aos utilizadores uma única plataforma, possibilitando a visita a todos os mundos criados no Multiverse recorrendo para tal ao Multiverse Client. Esta plataforma é grátis para utilizações não comerciais, mas no caso de utilização comercial terá que ser acordado uma verba ou uma partilha do valor das receitas para o licenciamento (The Multiverse Network, 2009a). Quanto a sua estrutura, esta é constituída por cinco componentes tecnológicos extensíveis e adaptáveis, sendo estes : - um software cliente (Multiverse Client) para navegar no mundo virtual, - um servidor (Multiverse Servers) para que seja possível criar um mundo virtual próprio; - ferramentas de desenvolvimento para a produção de conteúdos (Multiverse Tools). - Multiverse Plug-Ins - Multiverse Infrastructure A função do servidor, a nível técnico, é a de implementação da lógica do mundo virtual bem como coordenar as conexões por parte dos clientes, verificando as posições ocupadas por estes quando se encontram imersos no mundo virtual. Este é construído em Java, podendo desta forma ser executado virtualmente em qualquer sistema operativo (testado mais extensivamente nos sistemas operativos Windows XP e Linux Fedora Core 4). É dada a possibilidade de personalizar este tipo de servidor através Java, JavaScript ou Python mediante as necessidades do programador. A comunicação entre o cliente e servidor é feita através de TCP9 ou Reliable Data Protocol (RFC908 e RFC-1151) (The Multiverse Network, 2009b). É dito pela própria Multiverse que devido a escalabilidade e equilíbrio de carga destes servidores é possível ter em simultâneo centenas a milhares de utilizadores, bem como vários mundos que podem ser divididos em fracções de tamanho desejado. De realçar que o Multiverse oferece a possibilidade de gerir os servidores de duas formas; pela própria Multiverse e por terceiros, isto é, programadores independentes. Quando os servidores são geridos pela Multiverse, a infra-estrutura consiste num servidor de login e uma base de dados de cliente. Assim, quando um cliente pretende aceder a mundos da rede Multiverse, irá efectuar primeiramente o login, através do Multiverse Client. O pedido é então direccionado ao servidor de login, que irá 9 Transmission Control Protocol 26 determinar quais os mundos a que o cliente pode aceder, tendo também em conta a idade e dados de facturação. Todas estas informações relacionadas com o cliente estão presentes numa base de dados própria, sendo apenas acessível pelo servidor mestre. O processo anteriormente discutido está ilustrado na figura seguinte. Figura 2– Login de um cliente Multiverse Quando geridos por terceiros, os servidores Proxy, World Manager, Messaging, Game database, Plug-in services irão estar alojados nos seus próprios sistemas de hardware, permitindo um controlo completo sobre a forma como o mundo virtual é gerido. Devido à arquitectura ser robusta, fiável e escalável, é possível a adição de novos servidores físicos (mais aconselhado para maior desempenho) bem como o aumento de recursos ou o poder dos servidores já existentes (menos aconselhado), sem que desta forma diminua a eficiência. A comunicação por voz oferecida aos utilizadores de tecnologia Multiverse passa pelo uso da tecnologia especificamente desenvolvida pela Vivox, não permitindo o desenvolvimento de soluções ou tecnologias próprias com outras tecnologias. 2.3 – Croquet O Croquet, desenvolvido por um consórcio de instituições académicas (Archives & Museum Informatics, 2007), é uma plataforma de desenvolvimento em código-fonte aberto; permite criar mundos virtuais colaborativos e multi-utilizador, possibilitando a integração de aplicações tridimensionais e bidimensionais (figura 3). 27 Figura 3 – Aplicações de Croquet (De: http://www.opencroquet.org/index.php/Screenshots/Videos) Esta plataforma utiliza tecnologia peer-to-peer10 que permite aliviar a carga dos servidores, existindo uma menor exigência a nível de largura de banda, que também é vantajoso para utilizadores de redes sem fios. Teoricamente a utilização desta tecnologia permite ainda obter uma maior escalabilidade, vencendo desta forma a limitação imposta de um número máximo de utilizadores em simultâneo por servidor, tal como acontece com o caso da plataforma Second Life Grid. A nível prático esta plataforma ainda não demonstrou encontrar-se preparada para um grande número de utilizadores em simultâneo, uma vez que podem ocorrer erros que obriguem ao reinício do servidor onde estes ocorrem (VanDrimmelen, 2007). Assim, o Croquet baseia-se na interligação de mundos virtuais distintos, construídos por cada utilizador, sendo executado em computadores pessoais ou servidores - ou seja, não existe um mundo virtual Croquet, mas sim vários, que poderão estar ou não interligados (VanDrimmelen, 2007) permitindo compartilhar a capacidade computacional bem como os recursos de dados entre estes. É ainda disponibilizado um Software Development Kit (SDK) - Croquet SDK - derivado do Squeak, um ambiente de desenvolvimento para a linguagem de programação SmallTalk. Este possui todas as 10 Peer-to-peer é uma arquitectura de sistemas distribuídos caracterizada pela descentralização das funções na rede, onde cada nó realiza tanto funções de servidor quanto de cliente. 28 classes necessárias ao funcionamento quer dos servidores, quer dos clientes, permitindo redefinir integralmente todos os aspectos do mundo virtual. De notar que este SDK, desde o último lançamento em 2007, passou a ser adoptado pela plataforma OpenCobalt, que contribui activamente uma vez que é parte integrante da sua solução (University et al., 2010). No entanto, ainda não tem nenhum trabalho referenciado na área de VoIP. 2.4 - Project Wonderland O Project Wonderland, desenvolvido pela Sun Microsystems, é uma plataforma baseada em software de código-fonte aberto em Java; esta possibilita a construção de mundos virtuais 3D colaborativos, tendo como principal foco fornecer ferramentas de código aberto para a colaboração entre utilizadores e ferramentas de desenvolvimento. Estas ferramentas incluem som espacial, quadros partilhados (“shared whiteboards”), visualizadores de PDF, HTML e vídeo, apresentações de slides, streaming de vídeo e partilha de ambientes de trabalho virtuais. Esta última ferramenta consiste, por exemplo, em criar um objecto no mundo virtual e esse objecto representar uma aplicação local da máquina que o possui (Sheucher et al., 2009). Esta plataforma baseia-se na arquitectura cliente/servidor usando o servidor de jogos da Sun denominado Project Darkstar11, herdando assim as características de escalabilidade e de infraestrutura de software de persistência do servidor. Além deste servidor, o Project Wonderland depende de mais projectos de código fonte aberto, sendo estes, Java3D, Project Looking Glass e jVoiceBridge, todos estes desenvolvidos pela Sun Microsystems. O projecto Java3D é uma API (Application Programming Interface) que consiste numa hierarquia de classes Java servindo como interface para o desenvolvimento de sistemas gráficos tridimensionais (Manssour, 2003). O Project Looking Glass é construído em cima da API Java3D e trata da gestão de ambientes 3D. Por fim, o jVoiceBridge, dota o projecto Wonderland de som espacial, estéreo assim como a capacidade de fazer chamadas telefónicas através do Session Initiation Protocol (SIP) com o mundo exterior (Wright, 2008). A interface do Wonderland é flexível e eficiente, pois foi concebida para trabalhar com Firefox, GIMP, MSN, AutoCAD ou qualquer outro aplicativo que possa ser executado no ambiente gráfico X 11 Plataforma open-source middleware da Sun para jogos online multiplayer. O software de servidor Darkstar fornece e gere as comunicações, o estado e a persistência do ambiente virtual e seus respectivos objectos para todos os clientes. Foi desenvolvido como uma plataforma para MMORPG, tendo em conta a escalabilidade e desempenho da rede 29 do Linux. No caso de uma aplicação de outra plataforma, basta usar VNC12, RDP13 ou outras normas de terminais gráficos ou de texto para complementar as funcionalidades necessárias ao resultado pretendido (Louro, 2009). Devido a esta plataforma ser código-fonte aberto poderá ser expandida através da criação de novas ferramentas. Isto é conseguido através de módulos (equivalente a plugins em outros ambientes) que podem incluir gráficos, código Java, ou outros recursos. Exemplos de módulos poderão ser um microfone virtual que amplia a voz de um avatar ou um gravador de vídeo que permite capturar as interacções que acontecem aos avatares imersos no seu mundo virtual (Open Wonderland, 2010). Como exemplo da aplicação desta plataforma temos o espaço virtual da Sun Microsystems, denominado MPK20 (Figura 4), sendo que este mundo virtual foi propositadamente personalizado para promover a interacção e colaboração entre os seus trabalhadores. Figura 4 – MPK20 (De: https://lg3d.dev.java.net/wonderland/images/2007-12-Wonderland-Various/album/index.html) A ideia da empresa foi que todos os funcionários (dos quais muitos o são hoje por teletrabalho) pudessem encontrar-se, colaborar e trabalhar como o fariam num dia-a-dia normal, face-a-face, partilhando documentos, reunindo-se e comunicando-se em viva voz num ambiente similar à realidade. 12 Virtual Network Computing, protocolo que permite aceder remotamente a uma máquina podendo usar interface gráfico. O VNC está disponível em versões para Windows e Linux 13 Remote Desktop Protocol 30 3 - OpenSimulator e tecnologias de voz A tecnologia OpenSimulator, como se explicou no capítulo 1, foi a escolhida para implementação interna na rede da empresa. Além das características já expostas abreviadamente no capítulo 2, importa então descrever em maior pormenor o seu surgimento, a arquitectura, a forma de funcionamento, instalação, configuração e expansão desta tecnologia. Também serão descritas as soluções de voz criadas especificamente para mundos virtuais onde se inclui as soluções de comunicação por voz existentes para o OpenSimulator. 3.1 – OpenSimulator O projecto OpenSimulator permite o desenvolvimento de um ambiente virtual standard para que qualquer aplicação o use como uma Framework, possibilitando com facilidade a criação e personalização de um mundo virtual próprio; no entanto é considerado um produto em fase inicial (alfa), o que significa que existe um desenvolvimento contínuo através do código base, sem data de lançamento oficial. Existe um número considerável de colaboradores que trabalham nos vários componentes, quer no desenvolvimento, quer na detecção e correcção de erros. Este projecto surgiu em Janeiro de 2007 sob a licença BSD14, altura em que foi publicado o código fonte do cliente Second Life e se assistiu à estabilização da biblioteca libOpenMetaverse. Esta última é desenvolvida em paralelo com o OpenSimulator, fazendo com que este herde dela tipos de dados comuns e as várias classes de suporte (Censullo, 2009). O principal objectivo do OpenSimulator é criar um servidor 3D flexível e modular15 compatível com o viewer/cliente Second Life. Assim, para a comunicação entre o cliente e o servidor foi adoptado o protocolo de alto nível do Second Life, que se apoia nos protocolos de mais baixo nível UDP e XML-RPC, onde as componentes comunicam internamente através de XML-RPC e REST (JSON/HTTP e XML/HTTP). No entanto, o principal objectivo foi alterado centrando-se no suporte a múltiplos clientes, permitindo o acesso simultâneo ao mesmo mundo, via múltiplos protocolos. O OpenSimulator foi desenvolvido na framework Mono para fornecer portabilidade entre ambientes de implantação de destino e para juntar à framework básica as facilidades oferecidas pela framework .Net. A framework Mono foi desenvolvida pelo Projecto Mono como código-fonte aberto alternativo 14 15 Berkeley Software Distribution license, tornando o projecto código fonte aberto e comerciável. “Modular uma vez que o Opensim pode ser estendido através de módulos/plugins que permitem a construção de aplicações específicas”(OpenSimulator, 2009). 31 á framework .Net da Microsoft. O Mono suporta os sistemas operativos e arquitecturas de hardware mais comuns e implementa a maioria da framework .Net, vindo novas revisões a alargar este nível de suporte. Assim, em termos de composição oferece funcionalidade ao nível do sistema utilizando a Framework .Net/Mono – para que seja instalado na plataforma alvo dependendo actualmente de uma versão igual ou superior a 2.0.4 caso se trate da Framework Mono ou da versão igual ou superior a 3.5 caso se trate da Framework .Net (Censullo, 2009). Esta plataforma possui a capacidade de criar conteúdo em tempo real, de forma imersa no ambiente, utilizando para tal, ferramentas próprias que possibilitam a partilha de texto, imagens e vídeo. É ainda possível a interacção entre os utilizadores através de comunicação por texto, por voz, criação e partilha de objectos 3D (OpenSimulator, 2009a). A criação de objectos é idêntica ao que acontece no Second Life, com a variante de ser possível a criação com maiores dimensões; além disso é possível construir até 45 mil objectos, ao contrário dos 15 mil permitidos no Second Life. Todos os recursos principais do Second Life Grid estão presentes no OpenSimulator, tais como: inventário, Instant Messaging, teletransporte, landmarks, texturas, objectos, etc, sendo que se espera que seja totalmente compatível com o Second Life Grid dentro de pouco tempo. Ao nível da execução, o OpenSimulator usa ficheiros de configuração para definir os parâmetros necessários ao arranque e funcionamento deste. O ficheiro central é o OpenSim.ini, localizado no directório /bin; contem a maior parte das restrições para a configuração do sistema, das quais se incluem parâmetros da grid, parâmetros dos módulos e parâmetros físicos, entre outros. Este ficheiro é suportado por outros ficheiros de configuração das regiões (baseado em XML), de serviços de rede (grid ou local), arquivo de configuração, e de vários ficheiros de configuração da cache. No que respeita ao núcleo, este, é definido por entidades, funções e serviços que fornecem a base para um simulador de cena física; este simulador é referido como uma região e contém a maior parte da arquitectura do mundo virtual – na sua essência é um simulador de física, motor de script local e um gestor de utilizadores. Ao nível da região, os módulos das regiões definem entidades, manipulam colecções, oferecem pontos de extensão e fornecem comunicações. O carregador do módulo de região comum carrega todas as assemblies que implementam a IRegionModule - interface da região do módulo comum num directório base. Criticamente, os módulos da região são passados uma referência para lidar com a cena principal do simulador. Ao manipular essa funcionalidade. 32 referência, os módulos podem estender Os simuladores de região são estendidos e interagem com outros simuladores e clientes através de entidades e serviços de comunicações; juntos, esses serviços são conhecidos como os serviços da grid, que incluem cinco servidores - UserServer, GridServer, AssetServer, InventoryServer e MessagingServer - sendo o conjunto destes denominado UGAIM16. Estes servidores incluem um servidor básico HTTP, que permite o tratamento de pedidos e respostas. Assim, qualquer um destes servidores é iniciado em primeiro lugar como um servidor HTTP base, sendo de seguida conectado uma consola. Cada um destes servidores executa uma função especifica, que será descrita de seguida: - UserServer (Servidor dos utilizadores): este servidor é responsável pela autenticação dos utilizadores do OpenSimulator na grid. O processo consiste em criar um identificador de sessão para cada utilizador; este identificador pode ser usado para autenticar pedidos para outros servidores do mesmo tipo, que se encontrem ligados a mesma grid, associando o identificador de sessão com um UUID17 (pode envolver uma autenticação criptográfica, autenticação por OpenID ou ainda através da conta de autenticação do utilizador - nome e respectiva senha). Além disso, o UserServer também provê informações sobre os utilizadores conforme as regiões, serviços ou módulos necessitam (Arthur, 2009). A configuração é gravada em /bin/config-include/UserServer_Config.xml através da recuperação de configurações anteriores ou através da interacção com a linha de comandos. Cada um dos módulos do núcleo são, então inicializados e os manipuladores registados. - GridServer (Servidor de grid): este servidor é responsável pela autenticação das regiões na grid, sendo que a cada uma destas regiões é atribuído um UUID específico e coordenadas X e Y – únicas – pois a grid é organizada de forma bidimensional. Também é responsável pelos os pedidos de informação, manipulação de desconexões e mensagens inter-região. A configuração é gravada em /bin/config-include/GridServer_Config.xml - AssetServer (Servidor de activos): este servidor é essencialmente uma base de dados WFRM18, sendo que quando é dada a entrada de um activo é-lhe imediatamente atribuído um UUID especifico permanecendo na base de dados para sempre (este facto poderá vir a ser alterado num futuro próximo onde os activos que não são usados, serão detectados e recolhidos). Os sons, texturas, imagens, notecards e scripts são adicionados ao inventario sob a forma de objectos serializados sendo imutáveis, isto é, sempre que ocorrer uma alteração nestes não serão modificados novamente 16 User Grid Asset Inventory Messaging, baseado no projecto original da rede Linden Lab Universally Unique Identifier Write Few Read Many 33 17 18 permanecendo para sempre na base de dados. A configuração é gravada em /bin/configinclude/AssetServer_Config.xml O plugin do núcleo com o servidor é o provedor de armazenamento (que implementa a interface IAssetDataPlugin). Este provedor de armazenamento é indicado na configuração principal OpenSim.ini. - InventoryServer (Servidor de inventário): Tem a função de interligar os UUIDs relacionados, isto é, o utilizador possui um UUID que é utilizado para obter a raiz do seu respectivo inventário, sendo que este possui várias pastas que contêm as respectivas ligações UUIDs deste. As pastas que não possuem ligações a UUIDs possuem um tipo e um nome descritivo para o activo. O servidor de inventário também mantém informações sobre permissão de acesso a itens armazenados. A configuração é gravada em /bin/config-include/InventoryServer_Config.xml - MessagingServer: responsável por possibilitar a comunicação interna, por texto entre utilizadores da plataforma, quer estes estejam in-world ou off-world. A comunicação é conseguida através de chat geral ou mensagens directas, mantendo o controlo de quem as deve ler. No caso das mensagens através de chat geral, estas só são visíveis mediante as distâncias entre utilizadores, já o caso da troca de mensagens directas entre utilizadores funcionam da mesma forma que o Short Message Service (SMS), mantendo-as marcadas por ler até serem entregues com sucesso ao respectivo utilizador. O servidor de mensagens contém uma colecção de módulos para armazenar informações do utilizador e encaminhar mensagens e comunicação às partes interessadas. Existem módulos para os protocolos de instant messaging mais usados, incluindo o IRC19. Neste momento o servidor de mensagens encontra-se em processo de migração / refatoração para o núcleo de outros servidores da grid. Como tal, o servidor de mensagens não é crítico para execução OpenSimulator. A forma como os serviços UGAIM são executados pode ser feita em dois modos distintos: em standalone (forma independente20) ou em gridmode (integrado numa grelha de servidores) (OpenSimulator, 2009b). Um sistema que funcione em modo standalone, executa todos os servidores (isto é, UGAIM) e um ou mais servidor/servidores de simulação ou de região num único processo, isto é, num único executável, OpenSim.exe. (OpenSimulator, 2009c). 19 Internet Relay Chat, protocolo de comunicação utilizado na Internet, utilizado para conversação (em grupo ou privada) e troca de arquivos entre utilizadores. 20 Também conhecido por “sandbox mode” 34 Quando um servidor OpenSimulator está a funcionar em gridmode, os vários aspectos da simulação são separados entre múltiplos processos, que podem ser executados em diferentes máquinas tendo desta forma o potencial de ser escalonável - a estrutura é dividida no mínimo em cinco servidores UGAIM (uma única instancia de cada servidor UGAIM) que servem um ou mais servidores de região (OpenSimulator, 2009c). Neste momento os servidores da grid estão numa fase de reconcepção (OpenSimulator, 2009c), para transição de uma nova versão, onde serviços e conectores são executados num “server shell” (Basic Universal Server Technology, B.U.S.T.), consistindo na fusão do AssetServer e InventoryServer num só servidor (OpenSimulator, 2009d). 3.2 - Tecnologias de voz em mundos virtuais As pesquisas realizadas até a presente data revelaram a existência de apenas duas soluções de voz criadas especificamente para mundos virtuais, Vivox e jVoiceBridge (o que não significa que não existam mais, apenas não foram encontradas no momento da elaboração desta dissertação). A primeira solução tem como parceiros a Linden Lab (criadora do mundo virtual Second Life) e a Multiverse; a segunda solução é a adoptada pela Sun para a plataforma Project Wonderland. 3.2.1 – Vivox A Vivox é uma empresa sedeada em Boston nos EUA especializada em integrar serviços de voz (recorrendo a tecnologia VoIP) em sistemas digitais (Pimentel, 2009). Como exemplo desses sistemas digitais temos os jogos on-line (CCP Games, Icarus Studios, Sony Online Entertainment), os mundos virtuais como Second Life e EVE Online e outras comunidades on-line como por exemplo a rede social Facebook. Neste momento esta empresa abrange mais de 15 de milhões de utilizadores espalhados por todo o mundo - mais precisamente em 180 países (The Multiverse Network, 2009c) - fornecendo ainda serviços de vídeo, mensagens instantâneas (IM) e presença. Feita a apresentação da empresa Vivox iremos descrever em maior pormenor a tecnologia de voz desenvolvida especificamente para o Second Life. Esta tecnologia funciona de acordo com a proximidade dos avatares21: quanto mais perto estes estiverem um do outro, mais alto e perceptível será o som22; além do chat por aproximação, podem- 21 22 Através da tecnologia áudio posicional 3D da companhia DiamondWare. Este comportamento é parametrizável pelo utilizador, que pode optar por usar o ponto de vista da câmara ou do avatar. 35 se efectuar conversas privadas entre dois utilizadores ou grupos23. O recurso de voz é controlado pelos proprietários das ilhas, que poderão habilitá-lo ou desabilitá-lo. Para que tudo isto seja possível é usada tecnologia baseada em RTP (Real-time Transport Protocol, usando a biblioteca oRTP), SIP (Session Initiation Protocol, usando a biblioteca amsip de Antisip), OpenAL, TinyXPath, OpenSSL, e libcurl para a transmissão de dados de voz (Linden Research, 2009d). Todas estas tecnologias estão contidas num daemon externo (SLVoice.exe) que é iniciado e parado pelo cliente Second Life, que também desempenha a função de intermediador entre o viewer do cliente e o Second Life, de forma a negociar a comunicação por voz entre estes. Este daemon controla as funções de configuração, controlo e display mas não controla o fluxo de voz (entre o microfone do utilizador e o servidor de voz Vivox), uma vez que este não passa pelo cliente Second Life (Linden Research, 2009e). O diagrama que se segue ilustra como o cliente Second Life se integra com o SLVoice.exe, sendo que neste tipo de integração o cliente, envia e recebe mensagens XML do SLVoice.exe através do protocolo de rede TCP. Figura 5 – Diagrama do funcionamento da API Vivox com uma aplicação cliente O objecto central do gateway SLVoice.exe é um objecto "Conector", que é o primeiro elemento que é instanciado e engloba todos os outros elementos; o cliente envia um pedido e é devolvida uma resposta, sendo que para cada par de pedido-resposta é gerado um identificador único. A resposta irá sempre incluir o pedido original, para que os aplicativos possam operar com uma quantidade mínima do estado – a aplicação pode retornar sempre o pedido original a partir da resposta. 23 Conseguido através de um daemon, que nada é mais que um software externo que é iniciado e parado pelo cliente Second Life contendo as tecnologias da Vivox e Diamondware. 36 Além de enviar os pedidos e manipular as respostas, o cliente deve ser capaz de lidar com eventos SLVoice.exe; os eventos são gerados quando ocorrem mudanças no estado do cliente local, estes eventos podem ser uma consequência directa de um pedido anterior ou do resultado das acções que ocorrem em outros lugares na rede, que efectuam uma mudança para o estado do cliente local (Linden Research, 2009e). 3.2.2 – jVoiceBridge A jVoiceBridge é uma tecnologia experimental totalmente escrita em Java patrocinada pela sua comunidade e pela Sun Microsystems Laboratories (CollabNet, 2007). Trata-se de um software misturador de áudio (funcionando como uma ponte de voz) que controla as comunicações VoIP, que pode ser usado em diferentes áreas, tais como mundos virtuais (para ambientes 3D, o Projecto Wonderland), detecção de fala, Teleconferências e chat por voz; Quando esta tecnologia é usada em mundos virtuais é adicionada a capacidade de suporte telefónico, sendo que para comunicar o utilizador tem que estar conectado ao jVoiceBridge, tal como acontece durante uma teleconferência suportando uma gama de qualidade de voz de telefone com qualidade de CD, ou seja, uma qualidade elevada com taxas de amostragem de 44,100 Hertz; assim a função do jVoiceBridge é a de mistura de áudio de telefone com o áudio imersivo in-world, fornecendo uma conexão a um PBX24 ou a uma rede telefónica externa através dos canais de comunicação SIP padrão, sendo possível o uso de softphones. A figura 6 mostra a arquitectura do jVoiceBridge utilizando os protocolos SIP e o RTP para a transmissão dos dados de voz do servidor para o cliente, neste caso um softphone (Moses, 2009). Figura 6 – Arquitectura do jVoiceBridge utilizando os protocolos SIP e o RTP 24 Private Branch Exchange, é um centro de distribuição telefónica pertencente a uma empresa que não inclua como sua actividade o fornecimento de serviços telefónicos ao público em geral. 37 Um exemplo de um mundo virtual que utiliza o jVoiceBridge é o Project Wonderland, este recorre ao protocolo SIP, utilizado no canal de comunicação para enviar os dados de sinalização, permitindo assim o funcionamento com qualquer software do telefone baseado neste protocolo; também recorre ao protocolo RTP, este utilizado para os dados relacionados com o áudio. A figura 7 mostra uma visão global das comunicações no projecto Wonderland, em particular a comunicação com o jVoiceBridge. Figura 7 – Comunicações no projecto Wonderland Devido ao áudio estéreo (reprodução de sons com distribuição espacial) e de alta fidelidade (fiel reprodução do som original) é possível obter um som que varia mediante o afastamento/proximidade entre os utilizadores in-world, uma vez que o efeito estéreo reproduz a localização de fontes sonoras, enquanto o volume indica proximidade, proporcionando desta forma um ambiente acústico imersivo (Sheucher et al., 2009). O jVoiceBridge fornece ainda um canal áudio individual ajustável para cada utilizador in-world e para cada fonte de som gravada in-world. 3.2.3 - Comunicação por voz em OpenSimulator As soluções de comunicação por voz existentes para o OpenSimulator encontradas até ao momento, não se concentram em oferecer voz entre os avatares e pessoas fora do OpenSimulator e vice-versa, concentram-se apenas entre avatares e serão estas que serão descritas ao longo deste capítulo. A única forma de aceder ao OpenSimulator até a data é recorrer a qualquer cliente baseado no protocolo cliente do Second Life; qualquer um destes clientes vem acompanhado pelo daemon SLVoice.exe – referido no capitulo 4.1. 38 Em 2008 surgiu a primeira solução de voz para o OpenSimulator, o AsteriskVoiceModule (DrScofield, 2008a); esta solução consistia em recorrer a um software PBX IP 25 denominado Asterisk. Este módulo requeria a substituição do daemon SLVoice.exe (DrScofield, 2008a), conseguida através do daemon desenvolvido pelo projecto voipforvw26, no entanto esta solução não se mostrou muito receptiva uma vez que requeria algum conhecimento a nível de Asterisk e voipforvw para configurar todo o módulo (DrScofield, 2008b), para além da obrigatoriedade de substituição em todos os clientes do deamon SLVoice.exe pelo daemon voipforvw; tendo em conta estes factores foram estudadas pela comunidade, ao longo destes meses algumas soluções (DrScofield, 2009a) que vinham ao encontro do pretendido, isto é, não ser necessário substituir o daemon tornando desta forma compatível o OpenSimulator com qualquer cliente construído a partir do código-fonte da Linden Lab. Numa primeira fase surgiu uma solução denominada por FreeswitchVoiceModule - o que fez com que o AsteriskVoiceModule fosse abandonado e retirado do código fonte do OpenSimulator (DrScofield, 2009a) - que recorre ao servidor Freeswitch, esta solução será descrita num capitulo próprio uma vez que foi a solução adoptada para dotar de voz os utilizadores do OpenSimulator implementado. Numa segunda fase surgiu outra solução, o módulo VivoxVoiceModule, este módulo funciona com a mesma tecnologia utilizada pelo Second Life permitindo assim usufruir de som espacial, de indicador de volume de som e possibilidade de conversa privada entre dois utilizadores, tudo isto sem ser necessário qualquer configuração por parte do cliente; é ainda possível a mudança de voz espacial para um “to conference call style voice channels”, ou modificar o alcance da voz. No entanto para que esta solução funcione é necessário que esta interaja com um servidor de voz Vivox, sendo que para tal é necessário obter uma licença específica (DrScolfield, 2009b). 25 sigla em inglês de Private Branch Exchange Internet Protocol 26 Voipforvw também denominado por Voip for Virtual Worlds é descrito pela equipa do projecto como segue: “Develop Open-Source VoIP stack to allow voice communication within Virtual Worlds. Specifically as a replacement for proprietary voice chat used in SecondLife.”(Geeknet, 2010). 39 4 – Arquitectura e modelo de integração Neste capítulo apresenta-se o estudo e reflexão das ideias que serviram de base para a arquitectura do sistema. 4.1 - Definição da arquitectura No sentido de atingir o objectivo desta dissertação, é necessária a elaboração de uma arquitectura que permita ao utilizador aceder ao mundo virtual OpenSimulator, que pode em alternativa usar um sofphone ou Gtalk para comunicar com outros que estejam presentes num dos quaisquer meios referidos anteriormente, sendo possível o reencaminhamento automático das chamadas de voz entre estes, tudo isto, tendo em conta a presença de colaboradores numa rede interna da empresa. Também é necessária que a arquitectura tenha em conta aspectos administrativos de instalação/manutenção de todas as ferramentas que constituem o sistema a elaborar. Para tal é necessário definir os elementos que constituem esta arquitectura e depois como interligar estes mesmos elementos, sendo eles: - Cliente (colaborador da empresa) - Servidor (sendo implementado pelo administrador) O esquema seguinte visa dar uma ideia geral da arquitectura a implementar. Figura 8 – Arquitectura geral 40 4.2 - Modelo de integração Nesta secção são descritos os requisitos necessários a implementação do trabalho desenvolvido, procedendo-se a apresentação do modelo esquemático bem como a explicação deste a nível de funcionamento. 4.2.1 - Requisitos Operacionais Aquando da definição da arquitectura do sistema surge a questão do que se deve ter em conta em relação a um ambiente empresarial, para que este oferecesse uma boa experiência virtual aos seus colaboradores e o mínimo de intervenção por parte de um administrador. Esta questão levou à definição da estrutura de dois casos genéricos de utilização: administrador e utilizador, representados graficamente nas figuras 9 e 10 respectivamente. No caso do administrador, este terá que se preocupar com: 1. Criar/manter as bases de dados necessárias ao funcionamento de todo o sistema; 2. Definir o horário em que são realizadas as cópias de segurança; 3. Proceder a instalação/manutenção normal do mundo virtual e servidor de voz, configurando apenas aspectos relacionados com a sua rede interna; 4. Instalar/Manter o website de controlo/apoio, tendo a partir deste, acesso/controlo a toda a informação relacionada com os utilizadores bem como executar algumas acções Figura 9 – Utilização do sistema por parte do administrador 41 No caso de um utilizador comum, este apenas tem que se preocupar em: 1. Aceder ao website de apoio ao utilizador. 2. Criar a sua conta de acesso ao mundo virtual, de modo a poder interagir com outros colaboradores, 3. Utilizar as ferramentas colocadas ao seu dispor (onde também se inclui o website), isto é, aceder ao mundo virtual (através de um cliente que implemente o protocolo Second Life) ou recorrer a um Sofphone. Em ambos é usada a mesma conta criada (passo 2). Em relação ao Gtalk este poderá usá-lo como o faria normalmente, sendo que as chamadas de voz que o tentem contactar serão direccionadas para o OpenSimulator ou para o Sofphone caso esteja num deste meios. Figura 10 – Utilização do sistema por parte do utilizador/colaborador Na questão da escolha do sistema operativo e hardware teve-se em conta que OpenSimulator é um software flexível, sendo possível a sua instalação na maioria das distribuições Linux, bem como em grande parte de plataformas não Linux. Quando a carga do sistema aumenta, este terá maiores dificuldades em ser executado com êxito, de forma a oferecer uma boa experiencia virtual aos seus utilizadores. Para um Mundo virtual, esta situação é desastrosa, os requisitos de desempenho são um factor crítico no processo de escolha de uma plataforma. No entanto não existe um sistema mínimo recomendado, ao nível de hardware, uma vez que existe uma serie de factores que influenciam tais como o número de regiões hospedadas por 42 máquina, número de utilizadores em simultâneo nessas regiões, numero de objectos, uso de scripts, entre outros que irão requerer um CPU27 maior e mais memória (RAM28) a medida que forem aumentando. A métrica usual para o bom desempenho é um CPU core e 1 GB de RAM por região, caso não se tenha milhares de objectos e tráfego intenso de utilizadores (Cascabel, 2009). Existem alguns exemplos, ilustrados na tabela 1, para ajudar na selecção do software e hardware, mas não são necessariamente recomendações, uma vez que são exemplos de pessoas que usam/possuem servidores OpenSimulator. Description Operating System Ubuntu Intrepid (8.10) RAM/AVG_USE_% CPU 1x quad-core 2.5GHz Xeon (L5420) 2x dual-core 2.0GHz Xeon (5130) type of regions simultaneous avs scripts/timers/Sensors Location Knifejaw Atoll & surrounding on OSGrid Knifejaw Road on OSGrid Arizona Bay I-IV / Ku 1-10 / (OKC) Sui / (OKC) Ka / Jedi / Sith / Underverse / Monopoly (all@osgrid) Pleasure Planet Welcome center & Region Pleasure Planet in OSGrid objectparts hosted Xen VPS 540MB/? 1 region + generally 1-2 9 voids few ? hosted Xen VPS Ubuntu Jaunty 360MB/? (9.04) Microsoft Windows Server 2003 Standard Edition SP2 1 void generally 1-2 none ? cari.net Core2Duo 1300mb Intel(R) Core(TM)2 Duo 16 voids 6 CPU E4400 @ Full 2-10 2.00ghz 1.99gb Regions of Ram 1500+ scripts / ?? timers / ?? sensors 20000+ Prims Dedicated Server from A+ Amazon EC2 "high-CPU medium instance" (Xen VM) Windows Server 2003 1 Meg 1x single-core 2regions 2.8GHz Celeron per server 1 region with sailing race course 6 at once with no issues Waterfalls, texture anims, window texture switchers, lots of sound loops 20000 prims per region Windows Server 2003 1.7GB 1x dual-core 2.3GHz (Intel E5345) 7 avs, 4 in boats scripted start line Castle Rock, OSGrid Tabela 1 – Exemplos de utilização OpenSimulator (De: http://opensimulator.org/wiki/Hardware_Selection_Guide) 4.2.2 - Tecnologia utilizada Todo o trabalho foi desenvolvido no sistema operativo Windows XP e testado em Windows Server 2003 e Windows XP. Para ser possível colocar o website de gestão e controlo a funcionar assim como criar e manter a as bases de dados foi necessário um servidor Web, com PHP, MySQL e interface visual de administração MySQL. Assim recorreu-se ao servidor XAMPP (versão 1.7.1 Beta5 para a plataforma Windows) que instala e configura de uma só vez o servidor: ● Apache HTTPD versão 2.2.11, servidor Web para disponibilizar o website na rede interna. 27 Central Processing Unit, ou processador é a parte de um sistema de computador que executa as instruções de um programa de computador e é o elemento primordial na execução das funções de um computador. 28 Random Access Memory, é um tipo de memória que permite a leitura e a escrita, utilizada como memória primária em sistemas electrónicos digitais. 43 ● PHP versão 5.2.9, linguagem de programação utilizada no desenvolvimento e implementação do website. ● MySQL versão 5.1.33-community, que sendo um Sistema Gerenciador de Base de Dados (SGBD) é utilizado para armazenar, controlar e manipular os dados relacionados com o website e OpenSimulator. ● phpMyAdmin versão 3.1.3.1, que sendo um interface visual de administração de base de dados MySQL, é utilizado para criar a base de dados OpenSimulator e adicionar as tabelas adicionais necessárias ao correcto funcionamento do website. Hardware A nível de hardware, o trabalho foi desenvolvido e testado em: ● Portátil A6J - Sistema Operativo: Windows XP Home Edition (SP 3) - Processador Intel® Core™2 Duo 1,66GHz. - 1GB de RAM. - NVidia™ GeForce™ Go7300 128MB ● Servidor HP PROLIANT DL160 G5 - Sistema Operativo Windows Server 2003 - Intel(R) Xeon(R) CPU 2.80GHz - 4 GB de RAM 4.2.3 - Modelo esquemático A implementação efectuada da tecnologia OpenSimulator com funcionalidades de voz em rede empresarial segue o modelo aqui apresentado, que é composto por vários elementos representados no diagrama da figura 11 onde se mostra a interligação entre estes nomeadamente: - Servidor OpenSimulator; - Servidor FreeSWITCH; - Servidor XAMPP; - Aplicação Web de apoio/controlo; - Módulo de cópias de segurança; - Software de interface (clientes que implementam o protocolo cliente Second Life (versões não superiores a 1.22.11) para aceder (instant messaging)); 44 ao OpenSimulator e clientes de voz como sofphones e Gtalk Figura 11 – Modelo esquemático do trabalho implementado O servidor OpenSimulator permite aos utilizadores aquando do uso de um cliente que implemente o protocolo Second Life a imersão no mundo virtual. A versão utilizada para este servidor foi a 0.6.7. Para que fosse possível o uso voz em OpenSimulator, recorreu-se ao servidor PBX FreeSWITCH na sua versão trunk, a partir do qual foi possível utilizar tecnologias como sofphones e Gtalk. Ao servidor Opensimulator está associada a base de dados que armazena toda a informação do simulador, cabendo à base de dados do servidor Freeswitch ficar responsável pela gestão dos dados dos utilizadores VOIP. O cliente, neste caso o colaborador de uma empresa, pode instalar e usar qualquer software que implemente o protocolo Second Life (Second Life viewer, Imprudence, Hippo Viewer) de forma a aceder ao OpenSimulator instalado. 45 Recorreu-se também a um servidor XAMPP que integra tecnologia PHP e MySQL, de forma a ter um website de controlo e criação/manutenção contas utilizador. Para tal, utilizou-se o projecto Opensimwi (Redux) procedendo-se a algumas alterações e adições de opções a este mesmo projecto. Por fim, foi elaborada uma aplicação que permite fazer uma cópia de segurança diária a base de dados associada ao servidor OpenSimulator bem como as suas regiões através dos ficheiros OAR. O backup diário é agendado através do sheduler do Windows, sendo que se executa as cópias desses dados num servidor de backup recorrendo a ferramenta ntbackup do Windows Server 2003. 4.2.4 - Servidor OpenSimulator com FreeSwitchVoiceModule A implementação de todo o projecto aqui apresentado seguiu-se numa primeira fase na instalação de um servidor OpenSimulator. Os primeiros passos consistiram em configurar o ficheiro “OpenSim.ini”, que se encontra directoria bin do software. Originalmente este ficheiro não existe, bastando apenas alterar o nome do ficheiro “Opensim.ini.example” para “Opensim.ini”. Uma vez que o OpenSimulator, pode ser executado em dois modos: standalone e grid, optou-se neste caso, por executar-se em modo grid pois tanto o website do utilizador como o website administrativo requerem este modo para uma total disponibilização da informação da grid. Um dos primeiros factos que surgiram no imediato foi que por defeito o OpenSimulator vem configurado para utilizar SQlite, o que levantava questões relacionadas com o desempenho a medida que o servidor tivesse que ir lidando a um crescendo nível de dados. Uma vez que o OpenSimulator prevê a possibilidade de usar um dos três tipos de programas para gestão da base de dados (SQlite, MySQL e NHibernate), optou-se por usar o MySQL, uma vez que o servidor FreeSwitch também permitia usar o módulo Sofia recorrendo ao MySQL. Para tal seguiu-se um dos tutoriais aconselhados no wiki OpenSimulator para plataformas Windows29. 4.2.4.1 - FreeSwitchVoiceModule Para que este módulo funcione correctamente é necessário que o servidor FreeSwitch esteja devidamente instalado e configurado. É este servidor que é descrito de seguida, dando relevância as partes utilizadas neste trabalho. No final desta descrição iremos falar do módulo em concreto a nível da sua constituição e configuração. FreeSWITCH é definido como: “an open source telephony platform designed to facilitate the creation of voice and chat driven products scaling from a soft-phone up to a soft-switch.” É escrito 29 http://opensimuser.wordpress.com/2008/07/16/opensim-mysql-install-guide/ 46 em C e licenciado sob a Mozilla Public License (MPL) 1.1. Foi projectado para tirar vantagem do maior número de bibliotecas de software existentes, podendo ser desenvolvido e executado nativamente de forma autónoma em diversos sistemas operativos tais como Windows, Mac OS X, Linux, BSD e SOLARIS bem como outros derivados de Unix (FreeSwitch, 2009a), em ambas plataformas de 32 e 64 bit. Uma das características deste projecto é a possibilidade de manter milhares de canais de dados concorrentes num PC standard. A sua implementação, por defeito, é a de um PBX ou Softswitch, onde o núcleo pode ser embebido quase em qualquer aplicação que use extensão .so ou .dll. Isto significa que, assim como o FreeSWITCH executa linguagens embebidas, ele próprio também pode ser embebido de forma a ser executado a partir de outros programas construídos através de uma variedade de linguagens como C, PHP ou Perl por exemplo (FreeSwitch, 2009b). A arquitectura foi desenhada de forma a ser extensível e modular, sendo montada para evitar deadlocks e race conditions. Trata-se assim de uma arquitectura simples, com configuração centralizada e desempenho escalonável: se uma expansão for necessária, só será necessário adicionar mais um servidor FreeSWITCH configurado de forma igual aos outros já existentes. Por padrão, as configurações são lidas a partir de arquivos XML, mas qualquer módulo pode ser o responsável por requisitar e interpretar as configurações, uma vez que as configurações podem ser pedidas remotamente não se limitando à adição e exclusão de utilizadores, mas a toda e qualquer opção configurável do software. Isso inclui o dialplan30, sendo flexível o suficiente para tomar decisões não apenas baseado em extension matching, mas também em endereços de rede, variáveis do canal, dados do utilizador tornando todo o esquema muito flexível (Fiori, 2009). O núcleo foi projectado para ser consistente, não dependente de módulos externos, contendo apenas as funcionalidades limitadas e necessárias. Este, é orientado por uma máquina de estados, que controla o estado de cada nova sessão (ou chamada) criada. Como foi dito anteriormente é possível devido a natureza modular do FreeSwitch o uso de módulos opcionais podendo adicionar virtualmente qualquer funcionalidade desejada pelo utilizador. Assim é possível expandir o sistema de uma forma simples, podendo as aplicações serem escritas em C/C++, Java, .NET, Javascript/ECMAScript, Python, Perl, PHP, Lua, além de algumas frameworks que se conectam ao “Event Socket” e exportam funções para o disparo e controle de chamadas. Em ambos os casos, a abstracção esperada é alcançada (Fiori, 2009). 30 Consiste em como as chamadas devem ser encaminhadas 47 De entre todos os módulos opcionais deste servidor, descreve-se apenas em maior pormenor os que foram utilizados para ser possível obter voz em OpenSimulator recorrendo ao servidor FreeSwitch. A nível aplicacional utilizou-se o módulo: ● mod_xml_odbc – permite que o directório dos utilizadores seja acedido através da base de dados em tempo real. ● mod_xml_curl - permite configurar o servidor Freeswitch no arranque e quando se encontra a correr a partir de um servidor Web; basicamente é solicitado quando ocorre algum pedido de autenticação ou como deverá ser direccionada uma chamada, sendo essa informação pedida a uma aplicação remota, neste caso uma aplicação adaptada por nós uma vez que se alterou o módulo original Freeswitch do OpenSimulator. A nível de codecs, o FreeSWITCH suporta os de banda larga e estreita, servindo de ligação a uma variedade de dispositivos no futuro. No entanto apenas interessa descrever o codec G711 PCMU uma vez que este é o único utilizado para a comunicação entre os clientes que implementam o Protocolo Second Life e FreeSwitch. G.711 é um padrão que foi desenvolvido para uso com codecs de áudio. Há dois algoritmos principais definidos no padrão para G.711: o algoritmo µ-law, usado na América do Norte e no Japão, e o algoritmo A-law, usado na Europa e em outros países. Este codec exige pouco processamento. Ele precisa de pelo menos 128 kbps (quilobits por segundo) para comunicação bidireccional (Microsoft, 2009). Uma vez que é possível, através do FreeSwitch, a interoperabilidade com protocolos VoIP que suportam Inter-Asterisk eXchange 2 (IAX2), Session Initiation Protocol (SIP) e Jingle interessa apenas descrever os dois últimos protocolos, uma vez que foram apenas estes que foram utilizados. O protocolo SIP é utilizado em relação aos utilizadores de OpenSimulator e de softphones sendo que o protocolo Jingle é usado para utilizadores de GTalk. A nível de SIP, o FreeSwitch suporta muitas funcionalidades avançadas SIP tais como presença/BLF/SLA assim como TCP TLS e sRTP. Também pode ser usado como uma proxy transparente com ou sem “media” no caminho de forma a agir como um SBC31 e proxy T.38 e outros protocolos “end to end” (Minessale II, 2009). O protocolo Jingle, desenhado pela Google e pela XMPP Standards Foundation, é uma extensão do Extensible Messaging and Presence Protocol (XMPP), que utiliza tecnologia peer-to-peer para a sessão de controlo (signaling) com interacções multimédia tais como comunicações VoIP ou videoconferência. Os fluxos multimédia são entregues através de RTP. 31 session border controller 48 Para se utilizar esses protocolos tem que se ter activados dois endpoints, sendo estes: ● mod_dingaling - Jabber/GoogleTalk Talk integration module ● mod_sofia - SIP module No caso da implementação do módulo FreeSwitchVoiceModule, presente nos módulos opcionais de região do servidor OpenSimulator, seguiu-se, numa primeira fase os passos indicados no wiki 32 do simulador, para que os utilizadores pudessem usar voz entre eles aquando da sua presença no mundo virtual instalado. A voz foi possível sem ser necessário alterações para os clientes Second Life ou Hippo, sendo que, só é possível usufruir deste módulo, caso os clientes em questão sejam superiores a versão 1.22, isto, no caso do SecondLife Viewer e 0.5, no caso do Hippo Viewer. Posteriormente, após estudo do código-fonte deste mesmo módulo verificou-se que este era constituído por 3 classes: - FreeSwitchVoiceModule; - FreeSwitchDirectory; - FreeSwitchDialplan; A classe FreeSwitchVoiceModule implementa a interface IRegion, o que permite ao Opensimulator, aquando do seu início, procurar por esta, uma vez que procura todas as classes que implementam essa mesma interface (presentes no directório Bin em formato .dll). Desta forma a classe é adquirida e executada como parte integrante do OpenSimulator (Dzikowski, 2009). Através da alteração das duas classes (FreeSwitchDirectory e FreeSwitchDialplan), foi possível desenvolver uma aplicação cujo objectivo foi oferecer aos utilizadores a possibilidade de usar voz em qualquer região assim como usar outros meios, tais como, sofphone ou Gtalk de forma a comunicarem com utilizadores in-world ou juntarem-se a conferencias de regiões especificas ou até utilizarem como forma normal de comunicação, isto, independentemente onde quer que se encontrem, sendo a chamada reencaminhada para qualquer um destes meios referidos. A aplicação de voz desenvolvida foi dividida em três partes: 1. Comunicação normal de voz entre utilizadores OpenSimulator e conferencia em regiões, conseguido através do módulo Freeswitch desenvolvido pela comunidade, conseguido através do módulo Xml_Curl. 2. Comunicação a partir de um sofphone, sendo que para utilizar basta usar os dados da conta Opensimulator (nome e password), conseguido também através do módulo Xml_Curl. 3. Comunicação a partir de um contacto Gmail, conseguido a partir do módulo Dingaling. 32 http://opensimulator.org/wiki/Freeswitch_Module 49 4.2.5 - Website Para que fosse possível interagir com o servidor OpenSimulator instalado, alterou-se alguns aspectos originais do projecto Opensimwi (Redux)33 a nível administrativo, nomeadamente possibilidade de executar comandos remotos administrativos essenciais para o controlo do servidor em questão bem como o acesso ao conteúdo dos registos. Decidiu-se manter o aspecto gráfico original deste projecto uma vez que o nosso objectivo principal era apenas adoptar esta plataforma dotando-a com novas funcionalidades/opções. Assim, em relação ao website do administrador criaram-se várias opções que lhe permite executar alguns comandos da consola remotamente sem ser assim necessário ter que aceder a maquina onde se encontra o servidor OpenSimulator. Todos os comandos remotos implementados estão descritos na tabela que a seguir se apresenta. Nome Descrição Parametros region_name, region_id (optional), region_master_first, region_master_last, region_master_uuid (optional), region_master_password, listen_ip, listen_port (integer), external_address, region_x (integer), region_y (integer), persist (optional) region_name shutdown (optional, expects 'delayed'), milliseconds Permite criar no simulador uma nova região tendo em admin_create_region conta vários parâmetros que se encontram na coluna do lado direito. Permite eliminar uma admin_delete_region determinada ilha indicando como parâmetro admin_shutdown Encerra o servidor OpenSimulator. Envia uma mensagem para todas as pessoas que se encontram nas ilhas do servidor OpenSimulator Reinicia uma região especifica Executa o comando Load XML Executa o comando XML admin_broadcast message admin_restart regionid filename, region_uuid (or region_name), xml_version filename, region_uuid (or region_name), admin_load_xml admin_save_xml 33 Projecto codificado em PHP que implementa uma interface Web, concebido para funcionar com servidores OpenSimulator a funcionarem em modo grid. Este interface recorre a um Content Management System (CMS) onde permite a criação/manutenção de contas para os utilizadores que pretendam aceder a grid bem como permitir a gestão destes mesmos por parte do proprietário dessa mesma grid. 50 admin_load_oar Carrega um arquivo do tipo OAR para uma região específica. Guarda os conteúdos de uma determinada região num ficheiro do tipo OAR. reset da password de um determinado utilizador filename, region_uuid (or region_name) admin_save_oar filename, region_uuid (or region_name) admin_update_user firstname, lastname Tabela 2 – Comandos administrativos implementados Por exemplo, a opção “Reset Password User” (Figura 12) faz uso do comando admin_update_user, no qual é possível fazer o reset da password de um determinado utilizador, sendo apenas necessário indicar o seu respectivo FirstName e LastName. Figura 12 – Reset da password do utilizador Todos estes comandos são possíveis de executar numa página Web graças a classe PHP RemoteAdmin. Esta classe implementa pedidos XML-RPC compatíveis com o plugin OpenSimulator RemoteAdmin, sendo que este deverá ser activado através do ficheiro de configuração OpenSim.ini. No entanto teve que se proceder a algumas alterações na classe PHP RemoteAdmin uma vez que não retornava os resultados de sucesso ou insucesso na execução dos comandos referidos anteriormente. No caso do website para o utilizador também foram efectuados algumas alterações em relação ao projecto inicial para permitir a criação e recuperação de conta recorrendo ao serviço de email da 51 empresa. Outra alteração prendeu-se com o facto de ao ser criada uma conta para aceder ao servidor OpenSimulator instalado, o avatar fosse pré-definido no seu primeiro login de forma a não aparecer uma nuvem, evitando assim confusão ao utilizador. 4.2.6 - Cópias de segurança de OpenSimulator Para que todos os dados fossem salvaguardados no caso de ocorrerem tanto avarias de hardware como corrupção de ficheiros essenciais ao bom funcionamento do servidor OpenSimulator instalado procedeu-se a várias formas de fazer cópias de segurança dos mais variados itens que envolvem todo este trabalho, sendo estes: - Cópia de segurança de regiões OpenSimulator usando OAR34. - Cópia de segurança de toda a base de dados do servidor OpenSimulator. Desenvolveu-se assim uma ferramenta em C#, mais precisamente um daemon, que quando executado efectua um backup a base de dados OpenSimulator e salva ficheiros OAR, respectivos às regiões que fazem parte do servidor OpenSimulator. Para que este faça cópias diárias terá que se recorrer ao Windows Sheduler no qual se deve programar para executar este deamon a uma determinada hora. No caso de copiar todos estes dados de um servidor para um servidor de backup basta recorrer a ferramenta ntbackup, do Windows Server 2003. 4.2.7 - Deployment do OpenSimulator Uma vez que poderia vir a ser necessário efectuar o deployment do nosso servidor OpenSimulator para outra máquina dentro da empresa utilizou-se o Setup Project do Visual Studio, de forma a permitir uma instalação prática e eficiente para o nosso servidor. Usou-se o 'Setup Project' do Visual Studio por ser uma boa solução para uma aplicação Windows, visto que o instalador irá descobrir quais as dependências da aplicação e as incluirá automaticamente. Após a criação de um Setup Project, o resultado é um arquivo *.msi, o qual instalará o(s) ficheiro(s) da aplicação, e adicionará um atalho ao menu de programas. 34 OpenSim Archive, consiste num arquivo que permite salvar todos os dados necessários para posterior restauração integral de informações de terreno, texturas, formas e tamanhos de objectos e inventários de uma região específica. Também poderá servir como um mecanismo de transporte de regiões inteiras de um servidor OpenSim para outro servidor OpenSim (Sequeira, 2009). 52 53 5 – Testes e resultados Neste capítulo é mostrado todo o funcionamento do sistema, sendo apresentado as conclusões com base nos testes efectuados ao sistema desenvolvido. 5.1 – Funcionamento do sistema Neste subcapítulo é mostrado todo o funcionamento do sistema, desde a fase inicial de instalação do servidor OpenSimulator, WampServer, website e Freeswitch até ao registo por parte de um utilizador para começar a usar o OpenSimulator, softphone ou website bem como o acesso do administrador ao website de administração, depois de ter efectuado toda a instalação do sistema desenvolvido. Todo este software é disponibilizado no DVD que acompanha esta dissertação. 5.1.1 - Instalação do OpenSimulator, Freeswitch, WampServer e website Para a instalação do nosso servidor OpenSimulator bastará executar o *.msi criado para o efeito. Após o término, irá ver-se uma confirmação de que a aplicação foi instalada com sucesso; na máquina em que se instalou, irá verificar-se no menu Programas os atalhos criados, como mostrado na Figura 13. O atalho “MyOpenSimAdminSite” direcciona para o website do administrador e o atalho “MyOpenSimUserSite” direcciona para o website do utilizador; por fim o atalho “MyOpenSim.Folder” direcciona para a pasta que contém todos os elementos necessários para que o OpenSimulator seja executado sem problemas. 54 Figura 13 – Menu de programas após a instalação Para a instalação do Freeswicth no sistema alvo, bastará descompactar a versão modificada para uma pasta a escolha do administrador do sistema. No caso do WampServer é apenas necessário executar *.msi que lhe é associado, sendo de seguida apenas necessário descompactar a pasta do website em \wamp\www 5.1.2 - Website – Utilizador A figura 14 ilustra o que um utilizador ao digitar o endereço URL – http://localhost/myopensimulator - do website encontra. É dada a possibilidade a um novo utilizador de criar a sua conta ou caso já esteja registado efectuar o seu login como qualquer utilizador normal. Nesta mesma página existem outras opções tais como ver o estado da grid, a lista de regiões e o mapa visual destas. Figura 14 – Página de apresentação do website de utilizador 55 Seleccionando a opção “Create Account”, o utilizador será direccionado para uma página própria, criada para o efeito (Figura 15). Figura 15 – Criar conta de utilizador Logo que o utilizador tenha criado sua conta com sucesso (Figura 16), irá receber um email com o respectivo link de forma a activar definidamente a sua conta de acesso ao serviço. Figura 16 – Exemplo de notificação por email da criação de conta OpenSimulator 56 Após clicar no link que é indicado no email este irá ser direccionado para o website (Figura 17) onde irá estar uma mensagem do sucesso na activação da conta. A partir deste momento o utilizador poderá aceder imediatamente ao website e ao servidor OpenSimulator instalado. Figura 17 – Confirmação de conta activa Quando o utilizador efectuar o seu primeiro login no OpenSimulator, irá aparecer com um avatar predefinido por nós, vestido de formas e texturas como se mostra na figura seguinte. Figura 18 – Avatar de utilizador no primeiro login em OpenSimulator instalado 57 Para recuperar os dados da conta bastará ao utilizador clicar na opção „Forgot my Password‟, bastando indicar o email associado a sua conta. De seguida irá receber um email no qual terá que clicar no link indicado (Figura 19). Figura 19 – Recuperação de dados através de email Ao clicar nesse link irá receber de seguida outro email com a password definitiva (Figura 20). Figura 20 – Confirmação final 58 Bastará depois aceder ao website e fazer o login com a password indicada, podendo alterar para outra ao gosto do utilizador se assim pretendido; para isso o utilizador deverá clicar na opção „Change Account‟. 5.1.3 - Website - Administrador Por definição do projecto Opensimwi (Redux), quando se acede pela primeira vez a página do administrador, este terá que entrar com uma conta predefinida por estes (fornecida em conjunto com o projecto), sendo que, uma vez feito o login, o administrador terá ao seu dispor uma série de opções (Figura 21). Figura 21 – Página de apresentação do website de administrador Na menu deste website existem várias opções (Figura 22), que permitem ao administrador executar alguns comandos remotos ao servidor OpenSimulator instalado ou consultar alguns registos deste. Ainda terá ao dispor a possibilidade de configurar alguns aspectos como colocar informação visível aos utilizadores do website próprio ou como as contas deverão ser criadas. Figura 22 – Painel de Controlo 59 Assim as opções existentes são:   “Home” – permite ir para a pagina inicial de administração; “Admin Settings” – permite configurar como o utilizador irá criar a sua conta, tendo em conta vários aspectos tais como a região inicial onde irá aceder o utilizador no seu primeiro login, se o utilizador pode ou não criar o seu ultimo nome ou escolher apenas de uma lista predefinida, podendo esta ser editada por parte do administrador:      “Loginscreen Manager” – permite informar os utilizadores sobre qualquer tipo de informação relevante ao sistema; “Page Manager” – permite criar novas opções/páginas a serem incluídas no website do utilizador; “Change Admin Pass” – permite modificar tanto o username como a password do administrador; “Manage Users” – permite efectuar operação de manutenção sobre qualquer utilizador do nosso sistema, desde actualizar a sua informação, exclui-lo ou até bloqueá-lo “Create Account” - permite criar uma conta para um utilizador que não possa por exemplo aceder a respectiva página presente no website destinada para o efeito. Desta forma o administrador poderá criar a sua conta a pedido;     “List Regions” - lista as regiões que constituem a grid do nosso servidor OpenSimulator; “GridServer Log” - demonstra toda a informação contida no registo respectivo ao GridServer; “GridUser Log” - demonstra toda a informação contida no registo respectivo ao GridUser; “OpenSim.Server Log” - demonstra toda a informação contida no registo respectivo ao OpenSim.Server; As opções que dotam o website administrativo de controlo remoto sobre o nosso OpenSimulator foram:       “Reset User Password” (ver Figura 15) - permite alterar a password de um utilizador; “Create Region” - permite criar uma nova região na grid do nosso servidor OpenSimulator; “Delete Region” - permite eliminar uma região na grid do nosso servidor OpenSimulator; “Restart Region” - permite reiniciar uma região na grid do nosso servidor OpenSimulator; “XML/OAR” – permite salvar/carregar arquivos de uma determinada região; “BroadCast Message” – permite a difusão de uma mensagem para todos os utilizadores que se encontram inworld no servidor OpenSimulator; 60 5.1.4 – Softphone Para que os utilizadores utilizem um softphone (Figura 23) basta fazerem a autenticação com a mesma conta criada para acederem ao OpenSimulator instalado devendo usar como password a palavra 1234. Figura 23 – Softphone com autenticação realizada Para poderem efectuar chamadas de voz a utilizadores que se encontrem imersos no OpenSimulator bastará adicioná-los como contactos normais, tendo que o seu respectivo número/contacto estar no formato “Avatar/FirstName_LastName” (Figura 24). Figura 24 – Adição de contacto a lista de contactos 61 Aquando de uma chamada através do sofphone, o utilizador imerso (Figura 25) irá receber um convite como se de um outro contacto imerso no OpenSimulator se tratasse. Figura 25 – Chamada recebida por um utilizador de softphone A partir do momento em que o convite é aceite os dois utilizadores estarão conectados podendo falar de uma forma privada (Figura 26). Figura 26 – Estabelecimento da conexão por voz entre dois utilizadores 62 5.2 - Testes, resultados e conclusões Neste subcapítulo procede-se à validação de todo o sistema através de testes e observação dos resultados concluindo por fim, se o sistema funciona correctamente e de acordo com a implementação. Assim foi utilizado um ambiente de testes dividido por três casos em particular: website, OpenSimulator e Freeswitch, sendo que para cada um deles foi elaborado metodologias distintas de forma a validar o funcionamento como um todo. 5.2.1 - Teste de desempenho ao website Para validar o funcionamento do website devem ser verificadas as seguintes condições: - É possível criar contas de acesso ao servidor OpenSimulator instalado? - É possível, através do website do administrador controlar remotamente o servidor OpenSimulator? - Quantos utilizadores simultâneos o sistema pode atender sem existir degradação do serviço? - Como saber o tempo médio de resposta para uma determinada quantidade de utilizadores? 5.3.1.1– Metodologia adoptada No caso da primeira pergunta foram criadas 50 contas de acesso manualmente verificando a possibilidade de autenticação e login no website bem como no servidor OpenSimulator instalado. Em relação a segunda pergunta foram executados os vários comandos que permitem controlar o servidor OpenSimulator através das opções presentes no website do administrador, sendo que a cada comando executado era verificado o comportamento do servidor OpenSimulator, tendo sido possível verificar o sucesso em cada um deles várias vezes. Para o teste de desempenho ao website de apoio ao utilizador/administrador, recorreu-se à ferramenta ApacheBenchmark (ab)35 para simular a carga de utilizadores. Fazendo recurso ao comando ab -n -c , em que indica o número de pedidos a fazer ao servidor e o numero de clientes a acederem em simultâneo ao website foi possível recolher informações importantes. Executou-se várias vezes este comando para o website do utilizador e do administrador variando o número de pedidos e o número de clientes em simultâneo, obtendo-se vários dados sendo o mais importante, o “Requests per second” (Pedidos por segundo). Outro dado importante é o “Percentage of the requests served within a certain time (ms)” que pode indicar indícios de 35 ApacheBench (ApacheBench, 2006): Ferramenta de benchmark desenvolvida pelo Apache Group para teste da capacidade de atendimento do servidor Web Apache. Desenvolvido na linguagem Perl, calcula o número de requisições por segundo que um servidor Web Apache é capaz de atender. Esta ferramenta vem em conjunto com o código fonte do Apache; 63 bottlenecks quando um pedido demora muito a ser executado, pois fornece a informação sobre o pedido mais rápido e o mais lento a ser atendido. Assim elaborou-se várias tabelas que resumem os valores obtidos desses dados para cada website em questão no qual se irão retirar as respectivas conclusões. Para o caso de 100 pedidos ao servidor e de 25 utilizadores em simultâneo obtiveram-se os seguintes dados: opensim Pedidos por segundo (pedidos/s36) Pedido mais rápido (ms37) Pedido mais lento (ms) 290,91 78 94 opensim/admin 290.91 63 109 Tabela 3 – Dados obtidos para 100 pedidos e 25 utilizadores em simultâneo Para o caso de 200 pedidos ao servidor e de 50 utilizadores em simultâneo obtiveram-se os seguintes dados: opensim opensim/admin Pedidos por segundo (pedidos/s) Pedido mais rápido (ms) Pedido mais lento (ms) 297.67 156 188 297.67 141 172 Tabela 4 – Dados obtidos para 200 pedidos e 50 utilizadores em simultâneo Para o caso de 375 pedidos ao servidor e de 350 utilizadores em simultâneo obtiveram-se os seguintes dados: opensim Pedidos por segundo (pedidos/s) Pedido mais rápido (ms) Pedido mais lento (ms) 279.07 641 797 opensim/admin 275.86 672 766 Tabela 5 – Dados obtidos para 375 pedidos e 350 utilizadores em simultâneo 36 segundos milisegundo - período que corresponde à milésima fracção de um segundo (0,001s) 64 37 5.2.1.2- Condições de teste Para as duas primeiras perguntas foram realizados testes manuais, simulando vários clientes, recorrendo ao browser Internet Explorer 5.5 e Mozzila Firefox 3.5.10 para utilização da aplicação. Para responder as restantes perguntas foi utilizado o ab executado na máquina com as seguintes características: 5.2.1.3 – Conclusão sobre o desempenho do website Após a execução dos testes descritos concluí-se que é possível criar contas de acesso sem qualquer tipo de anomalia bem como executar comandos remotos administrativos ao servidor a partir do respectivo website. Por fim conclui-se que website consegue suportar 375 pedidos com 350 utilizadores em simultâneo atendendo aproximadamente 279 pedidos por segundo, onde, tanto o pedido mais lento como o pedido mais rápido demoram menos de 1 segundo. Quando se ultrapassam estes valores (375 pedidos/ 350 utilizadores) o servidor irá rejeitar alguns pedidos. 5.3.1 - Teste de desempenho ao servidor OpenSimulator Para validar o funcionamento do servidor OpenSimulator devem ser verificadas as seguintes condições: - A memória que o nosso OpenSimulator consome ao longo do tempo é adequada a memória disponível na nossa máquina? - É possível obter-se bons desempenhos para vários utilizadores e poucos objectos? - É possível obter-se bons desempenhos para poucos utilizadores e vários objectos? - É possível obter-se bons desempenhos para vários utilizadores e vários objectos? 5.3.1.1– Metodologia adoptada Em resposta a primeira pergunta obtemos os valores dos vários servidores que constituem a grid do nosso OpenSimulator recorrendo ao utilitário Windows taskmgr; passados 4 meses obtivemos os valores que se encontram Figura 27, sendo que houveram alguns picos de utilização. 65 Figura 27 – Desempenho do servidor OpenSimulator instalado na rede interna da empresa Para a resposta as outras perguntas recorreu-se a barra de Estatísticas; ferramenta presente em todos os clientes que implementam o protocolo Second Life apresentando uma lista detalhada de informações sobre o desempenho do computador do utilizador e o Mundo Virtual a qual está ligado em tempo real. De seguida descrevem-se quais os factores a ter em conta para concluirmos sobre o desempenho do OpenSimulator instalado. Como factores básicos temos: “Frames Per Second” (FPS): O número de vezes por segundo que o computador do utilizador actualiza o que está no ecrã. Quanto maior for esse numero melhor será a desempenho do nosso OpenSimulator. Uma taxa de frames entre 15-30 frames por segundo (FPS) é tão suave como uma transmissão de TV. “Bandwidth”: A quantidade de dados transferidos entre o computador do utilizador e o Mundo Virtual. Este número oscila descontroladamente dependendo das configurações da largura da banda que utiliza, o lugar da grid onde esta se encontra, o que está a acontecer e quando carrega algumas coisas (objectos/texturas/etc) que estão no campo de visão do utilizador imerso no mundo virtual. 66 “Packet Loss” (Perda de Dados): A quantidade de dados perdidos entre as ligações do computador do utilizador e o servidor. Quando a Perda de Dados não está a zero é indicador que o sistema não está a oferecer um serviço de qualidade sendo que uma Perda de Dados acima de 10% é considerado muito mau serviço. A Perda de Dados, pode ser causada pelo servidor em inactividade (no qual determinada região pode sofrer), uma má conexão entre o utilizador e o servidor. “Ping Sim” : O tempo que leva para que as informações trasfeguem do computador do utilizador até a região onde está. Isso depende muito da conexão com rede interna; se o Ping Sim estiver alto e o Ping User estiver baixo poderá ser um indicador que o servidor está a ter problemas. Como factores relacionados com o simulador temos: “Time Dilation” - As simulações relativas a taxa de física ao tempo real. 1.0 significa que a região está a ser executada ao máximo da velocidade; 0.5 significa que a física relacionada com o servidor está a ser executada a metade da velocidade. “Sim FPS” - A taxa de frames da região. Este indicador deve estar sempre igual a taxa de física de 45.0 caso esteja tudo a ser executado dentro do normal. “Physics FPS” - A taxa de frames que a mecânica da física está a operar. Esta deve estar normal estando em, ou próximo a 45.0. Como factores relacionados com os detalhes físicos temos: “Agent Updates/Sec” - A taxa o qual os utilizadores desta região são actualizados. Normalmente 20 actualizações por segundo, este valor irá diminuir caso a região estiver com um grande número de utilizadores nela. “Main Agents” - O número de utilizadores que estão na região. ”Child Agents” - O número de utilizadores que não estão na região, mas podem ver os utilizadores da região. “Objects” - O número total de objectos na região. “Active Objects” - O número de objectos que estão a ser movidos ou alterados na região. “Active Scripts” - O número de scripts activos actualmente na região, incluindo scripts associados aos utilizadores. “Script Events” - Número de códigos Linden Scripting Language a serem executados numa segunda região. Note que este é o número de instruções actuais executadas no último segundo, não o máximo teórico de opcodes/segundo. Se sua região não está executando muito scripts, este número estará baixo mesmo se o desempenho for bom. “Packets In” – Pacotes UDP recebidos na região. “Packets Out” – Pacotes UDP enviados para região. 67 “Pending Downloads” - Número de recursos baixados para a região pendente. Se estivar maior que um, significa que podem ocorrer atrasos ao visualizar anotações ou scripts, e criação de objectos. “Pending Uploads” - Número actual de uploads de recursos de dados pendentes. Caso este número esteja diferente de zero, significa que pode ter desempenho reduzido nas tentativas de ir para outras regiões da grid. Abaixo estão as diferentes estatísticas – recorrendo ao painel de Estatísticas (Figura 28) - recolhidas por dois utilizadores. As recolhas foram feitas quando os utilizadores se encontravam numa das regiões que constituem a grid do nosso OpenSimulator, tendo sido criado uma tabela de forma a facilitar a análise dos resultados. Figura 28 – Imagens obtidas em computadores de dois utilizadores 68 Através dos resultados obtidos na Figura 28 registou-se os valores obtidos na tabela que se segue; também foram colocados os valores padrão de forma a facilitar uma rápida análise de forma a concluir sobre o desempenho do servidor OpenSimulator. Utilizador 1 Básico FPS Bandwidth Packet Loss Ping Sim Simulator Time Dilation Sim FPS Pyshics FPS Pyshics Details Agent Updates/sec Main Agents Child Agents Objects Active Objects Active Scripts Scripts Event Packet In Packet Out Pending Downloads Pending Uploads 0.0 12 0 2148 0 151 0 eps 5 pps 14 pps 0 0 4.3 13 0 2148 0 151 0 eps 5 pps 26 pps 0 0 20 1.00 57 48.8 1.00 55 47,4 1.00 45.0 45.0 15.0 29 Kbps 0.0 51 ms 11.0 3 Kbps 0.0 87 ms 0.0 15.0 a 30.0 Utilizador 2 Valores Padrão Tabela 6 – Principais valores obtidos da figura 28 5.3.1.2 – Condições de teste O teste consistiu em fazer o login de múltiplos bot38s – recorrendo ao TestClient.exe da biblioteca libopenmetaverse (Figura 29) - em conjunto com 3 utilizadores reais numa ilha com 2148 objectos 38 bot, diminutivo de robot, é um utilitário concebido para simular acções humanas, em geral numa taxa muito mais elevada do que seria possível para um editor humano sozinho 69 numa zona de 256 x 256 metros quadrados. Os clientes utilizados para acederem ao OpenSimulator instalado por parte dos utilizadores reais foram o Hippo Viewer 0.5.1 e o Second Life Viewer 1.22.11. Figura 29 – TestClient.exe 5.3.1.3 – Conclusões sobre o desempenho OpenSimulator instalado Em resposta a primeira pergunta verificamos que o servidor que consumiu mais memoria foi o da região (OpenSim.exe), não ultrapassando valores considerados críticos do sistema uma vez que este possui 4 GB de RAM disponíveis. Após a execução dos restantes testes descritos concluí-se que a região foi executada ao máximo da velocidade (Time Dilation = 1.0), e sendo esta a região mais complexa da grid será seguro concluir que todas as outras regiões da grid tenham um desempenho semelhante. Normalmente, no que respeita ao número de actualizações de utilizadores por segundo, os valores rondam 20 actualizações por segundo mas no nosso caso este valor foi menor pois a região possuiu um grande número de utilizadores. Por fim conclui-se que o sistema instalado oferece um serviço de qualidade, uma vez que em ambos os clientes não se teve nenhuma perda de pacotes (Packet Loss = 0.0). 70 5.4.1 - Teste do servidor de voz Freeswitch Para validar o funcionamento do servidor Freeswitch devem ser verificadas as seguintes condições: - Qual a qualidade de voz obtida entre os utilizadores? - A distancia dos utilizadores influencia? - Quantos utilizadores simultâneos o sistema pode atender sem degradar o serviço? - Como saber o tempo médio de resposta para uma determinada quantidade de utilizadores? 5.4.1.1 - Metodologia adoptada Sabe-se que a perda de pacotes e jitter39 influenciam na qualidade de voz recebida, no entanto não houve tempo para se estudar softwares que ajudassem na determinação rigorosa destas características bem como obter respostas rigorosas as restantes perguntas. Assim foram efectuados testes recorrendo a utilizadores reais, obtendo o seu feedback na utilização da voz implementada. Testou-se a voz, entre dois a quatro utilizadores in-world em simultâneo, no qual foi conseguido uma conversação com boa qualidade, quer privada (entre utilizadores) quer em conferência (numa região). O mesmo aconteceu com cinco utilizadores de softphone, sendo que a conferência não foi testada uma vez que a funcionalidade não foi desenvolvida para este trabalho. 39 variação estatística do atraso na entrega de dados em uma rede, ou seja, pode ser definida como a medida de variação do atraso entre os pacotes sucessivos de dados 71 6 - Conclusões e trabalho futuro Será apresentado de seguida as conclusões e trabalho futuro com base nos testes efectuados ao sistema desenvolvido. 6.1 – Conclusões O nosso objectivo principal na realização deste projecto era demonstrar que seria possível implementar um servidor OpenSimulator com funcionalidade de voz no contexto da rede interna da empresa, possibilitando a comunicação entre utilizadores do OpenSimulator ou utilizadores de softphones ou Gtalk. Esse objectivo foi parcialmente alcançado uma vez que não foi conseguido em tempo útil dotar os utilizadores de utilizarem os seus respectivos Gtalk. Independentemente do trabalho futuro que possa ser desenvolvido, acredita-se que os resultados presentes permitem concluir que o sistema demonstra a possibilidade de implementar um servidor OpenSimulator com funcionalidade de voz para utilizações de pequena e media dimensão, na rede interna da empresa. De um ponto de vista de comunicação empresarial o sistema desenvolvido poderá ser adoptado em diversas vertentes tais como potenciar a comunicação e troca de informação entre colaboradores da empresa dentro do OpenSimulator e até proceder a formações especificas da empresa dentro deste mesmo mundo virtual, promovendo desta forma uma maior interactividade. Caso se pretenda a abertura para o exterior, poderá ser uma forma de promover a sua própria marca ou até realizar novas formas de negócio interagindo de uma forma bem mais inovadora. A aplicação que aqui sugerimos, viabiliza o uso do OpenSimulator numa rede interna empresarial libertando também o administrador de algumas tarefas manuais, tais como todo o backup que rodeia o trabalho desenvolvido. Desta forma foi conseguido um sistema sério e que pretende facilitar o seu uso quer a nível de administração quer a nível de manutenção ou a nível de utilizadores, respeitando os principais interessados, empresa e utilizadores numa rede interna. 72 6.2 - Trabalho futuro Com base nos resultados e nas conclusões extraídas do decorrer deste trabalho, foi possível tecer algumas considerações sobre o trabalho que poderá ser realizado com base no actual, bem como propor melhorias ao mesmo nomeadamente: - Alargamento do sistema de forma a permitir que os utilizadores utilizem o seu Gtalk. - Os utilizadores de softphones terão que utilizar a sua password correspondente a sua conta OpenSimulator em vez de uma password estática que é igual para todos os utilizadores do sistema. - Proceder a testes de utilização intensiva do sistema, isto é, tanto o envio/recepção de grandes quantidades de chamadas de voz entre utilizadores de diferentes meios (OpenSimulator/Sofphone/Gtalk), tanto na criação de conteúdo e interactividade entre utilizadores in-world. - Permitir conferencia por voz entre vários utilizadores OpenSimulator e utilizadores de softphones e Gtalk. - Permitir que os utilizadores possam usar as suas contas de empresa recorrendo ao Lightweight Directory Access Protocol (LDAP) desta. - Elaborar um daemon que permita monitorar o UGAIM e o servidor Freeswitch de forma a garantir que estes estejam sempre a funcionar quando ocorre alguma anomalia. - Dotar o processo de instalação do servidor OpenSimulator de ser um serviço Windows. 73 7 - Referências Amaral, I. (2008). A @migração para o Ciberespaço: a Dimensão Social dos Mundos Virtuais. Observatorio (OBS*) Journal, 5 (Maio). ISSN: 1646-5954 Archives & Museum Informatics (2007). A Second Life for Your Museum: 3D Multi-User Virtual Environments and Museums acedido a 20 de Abril de 2009 em http://www.archimuse.com/mw2007/papers/urban/urban.html Arthur (2009). Estrutura do OpenSimulator. Consultado a 5 de Agosto de 2009 em http://arthursv.wordpress.com/2009/07/31/estrutura-do-opensimulator/ Bainbridge, William Sims (2010). Online Worlds: Convergence of the Real and the Virtual (HumanComputer Interaction Series) [Paperback]. Springer-Verlag London Limited 2010. Book, Betsy (2008). Consultado a 10 http://www.virtualworldsreview.com/info/whatis.shtml de Fevereiro de 2009 em Cascabel, Warin (2009). What characteristics should have my server?. Consultado a 20 de Abril de 2009 em http://osgrid.org/forums/viewtopic.php?f=9&t=1079&view=next Censullo, Tom (2009). Tutorial: Architecture of Open Simulator. Consultado a 30 de Abril de 2009 em http://vw.ddns.uark.edu/X10/content/ARCHITECTURE--Tutorial--Architecture-of-OpenSimulator--Censullo.pdf CollabNet, Inc. (2007). jVoiceBridge. https://jvoicebridge.dev.java.net/ Consultado a 22 de Fevereiro de 2009 em Corneliussen, Hilde G; Rettberg, Jill Walker (2008). Digital Culture, Play, and Identity: A World of Warcraft® Reader (World of Warcraft Reader). MIT Press. ISBN-10: 0-262-03370-4 ISBN-13:9780-262-03370-1. Damasceno, F. Et al. (2005). Implementação de Serviços de Voz em Ambientes Virtuais. Consultado a 12 de Fevereiro de 2009 em http://www.dcc.ufla.br/infocomp/artigos/v4.3/art09.pdf DrScofield (2008a). opensim & voice support: the goal is in sight…Consultado a 27 de Abril de 2009 em http://xyzzyxyzzy.net/2008/04/18/opensim-voice-support-the-goal-is-in-sight/ DrScofield (2008b). [Opensim-users] Voice in Open Sim grids. Consultado a 28 de Abril de 2009 em https://lists.berlios.de/pipermail/opensim-users/2008-December/000736.html DrScofield (2009a). i hear voices…or: why we dropped AsteriskVoice from OpenSim. Consultado a 23 de Abril de 2009 em http://xyzzyxyzzy.net/2009/04/22/i-hear-voicesor-why-we-droppedasteriskvoice-from-opensim/ DrScofield (2009b). full spatial voice for opensim. Consultado a 20 de Outubro de 2009 em http://xyzzyxyzzy.net/index.php?s=vivoxvoicemodule Dzikowski, Robert (2009). Getting Started with Region Modules. Consultado a 5 de Abril de 2009 em http://opensimulator.org/wiki/Getting_Started_with_Region_Modules Fiori, Alexandre (2009). yeah, tudo assíncrono. Consultado a 4 de Maio de 2009 em http://fiorix.wordpress.com/category/rede/telecom/ Fitzgerald, Michael. (2007); How I Did It: Philip Rosedale, CEO, Linden Lab. Interview with Philip Rosedale. Inc. Electronic Magazine. Retrieved July 27, 2009 from http://www.inc.com/magazine/20070201/hidi-rosedale.html 74 FreeSwitch (2009a). Main Page. Consultado http://wiki.freeswitch.org/wiki/Main_Page a 2 de Abril de 2009 em FreeSwitch (2009b). Embedding FreeSWITCH. Consultado a 5 de Maio de 2009 em http://wiki.freeswitch.org/wiki/Embedding_FreeSWITCH Geeknet, Inc. (2009). VoIP for Virtual Worlds. Consultado a 10 de Abril de 2010 em http://sourceforge.net/projects/voipforvw/ Gouveia, L. (2000). Ambientes Virtuais Colaborativos: a Procura de Formas Alternativas de Interacção. Revista Politécnica, 2 (Dezembro). Edições da Cooperativa de Ensino Politécnico. Porto. ISSN 0874-8799. Leal, David (2007). Mundos Virtuais On-line: Um Mini-guia. Consultado 10 de Fevereiro de 2008 em http://www.masternewmedia.org/pt/2007/04/10/mundos_virtuais_online_um_miniguia.htm LibOpenMetaverse (2009). LibOpenMetaverse. Consultado a 10 de Fevereiro de 2009 em http://www.openmetaverse.org/projects/libopenmetaverse Linden Research, Inc (2009b). History of Second Life. In Second Life Wiki. Consultado a 20 de Julho de 2009 em http://wiki.secondlife.com/wiki/History_of_Second_Life Linden Research, Inc (2009d). Voice. http://wiki.secondlife.com/wiki/Voice Consultado a 18 de Abril de 2009 em Linden Research, Inc. (2009a). Introducing the Second Life Enterprise Beta. Consultado a 1 de Maio de 2010 em http://work.secondlife.com/en-US/products/ Linden Research, Inc.(2009e). Voice/Linux Sound Settings. Consultado a 12 de Junho de 2009 em http://wiki.secondlife.com/wiki/Voice/Linux_Sound_Settings Linden, Amanda (2009). Second Life Lives Behind a Firewall. In Second Life®. Consultado a 15 de Abril de 2009 em https://blogs.secondlife.com/community/workinginworld/blog/2009/04/01/secondlife-lives-behind-a-firewall Linden, T (2009). The Second Life Economy - First Quarter 2009 in Detail. In Second Life®. Consultado a 20 de Abril de 2009 em https://blogs.secondlife.com/community/features/blog/2009/04/16/the-second-life-economy--firstquarter-2009-in-detail Louro, Donizetti (2009).Ambientes Imersivos para a educação corporativa. Consultado a 1 de Abril de 2009 em http://www.donlouro.com/don_pt/pro/index.htm Manssour, Isabel Harb (2003). Introdução a Java 3D. Consultado a 21 de Maio de 2009 em http://www.inf.pucrs.br/~manssour/Publicacoes/TutorialSib2003.pdf Microsoft, Corporation (2009). Compreendendo codecs de áudio da Unificação de Mensagens. Consultado a 31 de Julho de 2009 em http://technet.microsoft.com/pt-br/library/aa998670.aspx Minessale II, Anthony (2009). Welcome To FreeSWITCH. Consultado a 5 de Maio de 2009 em http://www.freeswitch.org/ Morgado, Leonel (2009). Interconnecting virtual worlds, Journal of Virtual Worlds Research, 3 (1), 4-7. Moses, Wanda R. (2009). Analysis of Embodied Conversational Agents in SecondLife for Speech Recognition.Consultado a 24 de Julho de 2009 em http://etd.auburn.edu/etd/bitstream/handle/10415/1891/MosesWanda.pdf?sequence=1 75 Open Wonderland, Foundation (2010). Open Wonderland FAQ. Consultado a 1 de Janeiro de 2010 em http://www.openwonderland.org/about/faq. OpenSimulator (2009a). Sobre o OpenSimulator. Consultado a 10 de Fevereiro de 2009 em http://opensimulator.org/wiki/PT OpenSimulator (2009b).OpenSim:Introduction and Definitions. Consultado a 15 de Abril de 2009 em http://opensimulator.org/wiki/OpenSim:Introduction_and_Definitions OpenSimulator (2009c). Configuration. Consultado a 16 http://opensimulator.org/wiki/Configuration#Standalone_vs._Grid OpenSimulator (2009d). LegacyServers. http://opensimulator.org/wiki/LegacyServers Consultado a 16 de de Abril Abril de de 2009 2009 em em Pereira, André; Araújo, Álvaro; Varajão, João; Morgado, Leonel (2008b). v-Inform – Sistema automático de informação dirigida para o Second Life®. Tékhne - Revista de Estudos Politécnicos, ISSN 1645-9911. Pereira, Jean; Valério, Sérgio; Serôdio, Carlos; Morgado, Leonel; Mestre, Pedro; Carvalho, Fausto (2008). Interligação entre Sistemas SMS e o Serviço de Mensagens Instantâneas do Second Life®. Conferência cef^SL 08 - Comunicação, Educação e Formação no Second Life®, Universidade de Aveiro - Portugal. Pimentel, Ana (2009). Chamadas grátis chegam às redes sociais. Consultado a 1 de Dezembro de 2009 em http://aeiou.expresso.pt/chamadas-gratis-chegam-as-redes-sociais=f562994 Santos, Henrique (31 de Janeiro de 2008). Avatares, os cyberconsumidores. Consultado a 12 de Maio de 2009 em http://casadogalo.com/avatares-os-cyberconsumidores Sequeira, Luís (2009). Mechanisms of three-dimensional content transfer between the OpenSimulator and Second Life Grid platforms. Master dissertation. Vila Real, Portugal: UTAD. Sheucher, Tina; Bailey, Philip H.; Christian, Gütl; Harward, V. Judson (2009). Collaborative Virtual 3D Environment for Internet-Accessible Physics Experiments. Consultado a 20 de Junho de 2009 em http://www.iicm.tugraz.at/home/cguetl/publications/2009/Scheucher%20at%20al.%202009%20%20iJOE.pdf The Multiverse Network, Inc (2009a). Licensing Overview and FAQ . Consultado a 30 de Março de 2009 em http://www.multiverse.net/licensing/licensing-faq.jsp?cid=4&scid=3#p3 The Multiverse Network, Inc (2009b). Consultado a 12 http://www.multiverse.net/about/pressreleases.jsp?cid=5&scid=2 de Maio de 2009 em The Multiverse Network, Inc (2009c). Partners. Consultado a 20 de Março de 2009 em http://www.multiverse.net/about/partners.jsp?cid=5&scid=5 University, Duke; others (2010). About Open Cobalt. Consultado a 23 de Agosto de 2009 em http://www.opencobalt.org/about/faqs Valério, S.; Pereira, J.; Morgado, L.; Mestre, P.; Serôdio, C.; Carvalho, F. (2009). Second Life Information Desk System using Instant Messaging and Short Messaging Service Technologies. Conferência VS-Games'09 - Games and Virtual Worlds for Serious Applications, Coventry – Reino Unido. VanDrimmelen, Jeff (30 de Julho de 2007). 7 Ways Croquet is Better than Second Life. Acedido a 19 de Abril de 2009 em http://edutechie.com/2007/07/7-ways-croquet-is-better-than-second-life/ Woodcock, Bruce (2008). Charts An Analysis of MMOG Subscription Growth Version 23.0. Consultado a 9 de Fevereiro de 2008 em http://www.mmogchart.com/Chart2.html 76 Wright, Timothy E.; Madey, Greg (2008).WonderDAC: An Implementation of Discretionary Access Controls within the Project Wonderland CVE. Consultado a 20 de Julho de 2009 em http://www.cse.nd.edu/Reports/2008/TR-2008-15.pdf 77