1 / 29

Apresentação do Projeto QoSWare

Apresentação do Projeto QoSWare. Andamento das atividades. Setembro, 2002. Roteiro . O Projeto QoSWare Objetivo Visão geral Aplicações selecionadas Atividades Atividades realizadas Atividades em andamento UFPE UFMG Próximas atividades. Projeto QoSWare.

illana-waller
Download Presentation

Apresentação do Projeto QoSWare

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Apresentação do Projeto QoSWare Andamento das atividades Setembro, 2002

  2. Roteiro • O Projeto QoSWare • Objetivo • Visão geral • Aplicações selecionadas • Atividades • Atividades realizadas • Atividades em andamento • UFPE • UFMG • Próximas atividades

  3. Projeto QoSWare • Título do projeto: QoSWare - Gerenciamento de QoS no Middleware para Aplicações em Tempo Real • OBJETIVO: Avaliar o comportamento de aplicações avançadas com suporte de Qualidade de Serviço (QoS) utilizando Serviços Diferenciados na Internet2 brasileira. • O projeto propõe a elaboração de aplicações "testbed" em tempo real baseadas no gerenciamento de QoS num "middleware". • Nosso conceito para o middleware QoSWare: “O middleware QoSWare consiste de serviços e/ou recursos localizados entre a aplicação e a infra-estrutura de rede que provêem mecanismos para a gerência e oferta de QoS para as aplicações de tempo real”

  4. Projeto QoSWareVisão geral • Equipes (UFPE) • 4 Professores • 2 Bolsistas DTI (suzana e Joseane) • 1 Aluno de Mestrado (arthur) • 2 Alunos de Doutorado (cak e vt) • 2 Alunos de Iniciação Científica (paulo e rodrigo) (UFMG) • 3 Professores • 2 Bolsistas DTI • Alunos de Mestrado • Alunos de Doutorado • Alunos de Iniciação Científica

  5. Projeto QoSWareVisão geral • Localização • Testbed UFPE • Testbed UFMG • Fases de implantação (visão UFPE) • Fase I: rede local – laboratório UFPE • Fase II: protótipo de WAN • Fase III: extensão do testbed REMAV Recife • Fase IV: interconexão testbed UFMG via RNP2 • Equipamentos • Elementos de rede • Sistemas finais • Aplicações escolhidas para avaliação do middleware: • Jogos de ação em rede • Realidade virtual distribuída e colaborativa • Jogos empresariais corporativos

  6. Jogos de ação em rede • Características • Requisitos rígidos de QoS (atraso e perda) • Tráfego baixo (informações de controle) • Sincronização entre usuários (estado do jogo) • Atraso • Sincronismo • Perda de pacotes • Colisão • Sons • Largura de Banda • Carga na rede • Carga nas máquinas • Arquiteturas • Centralizada • Distribuída (com ou sem servidor)

  7. Jogos de ação em redes • Utilização de jogo comercial • OBJETIVOS: • Levantamento dos requisitos do middleware • Familiarização com o ambiente de teste • Tempo Real • Sistema operacional: Linux ou Windows • Jogo multiusuário com a perspectiva de primeira pessoa • Utilização de um jogo de ação em redes desenvolvido no CIn/UFPE • OBJETIVOS: • Avaliação do middleware • Servir como trabalho de graduação para um aluno do CIn/UFPE • Tempo Real • Sistema operacional: Linux ou Windows • Jogo multiusuário

  8. Jogo “NetSoccer” - Objetivos • Criar um jogo que demande: • Pouco atraso (tempo real) • Sincronismo • Previsão de movimento • Jitter baixo • Jogo de Futebol Multiplayer • Jogadores distribuídos na rede • Interação entre jogadores • Tempo real • Movimentos contínuos

  9. Jogo “NetSoccer” - Características • Primeira Versão. • Dois jogadores • Disputa entre goleiros • Bola rebate nos cantos do campo • Movimento limitado à sua metade do campo • Interface simples

  10. Jogo “NetSoccer” - Arquitetura Jogador Tempo Barra Placar Campo Bola Cadastro Jogadores Gerenciador Partidas Central Middleware: Sockets Gerenciador Gráfico Gerenciador Entradas Cliente

  11. Jogos empresariais • Jogos empresariais estão sendo muito utilizados para treinamento e formação de gerentes. • Através de simulação de um ambiente real, onde as tomadas de decisões têm seus impactos registrados e realizados. • Telecomunicações X Internet • Elaboração do jogo “InterQoS” • Elaborar modelo lógico / funcionalde uma aplicação que represente o problema da interconexão e negociação de preços e QoS entre empresas de Telecomunicação, ISP (Internet Service Provider) e usuários.

  12. O Jogo “InterQoS” • Tipos de jogadores • ISP’s, operadoras de telecomunicação e usuários da Internet; • Número de jogadores • Mínimo 3 jogadores em cada categoria • Recomendado: muitos usuários (a partir de cada computador pode-se escolher participar com vários jogadores de cada categoria.) • Competição entre jogadores • Cada categoria de jogador compete entre si (os ISP’s competem com ISP’s; operadoras com operadoras e usuários com usuários)

  13. O Jogo “InterQoS” • Cada jogador começa o jogo com um montante virtual que deverá ser gasto para cumprir o objetivo do jogo. • A topologia inicial do jogo deve ser preparada pelo administrador, onde são associados provedores e aplicações aos nós do grafo e operadoras às arestas. • Haverá enlaces com garantias de QoS e enlaces sem tais características. • O usuário Internet pode se conectar em qualquer ISP.

  14. O Jogo “InterQoS” • Comunicação vertical e hierárquica. Isto é, o usuário apenas enxerga o ISP. Por sua vez, a operadora só pode negociar com o ISP. • No início do jogo os jogadores ISP’s deverão preencher sua tabela de plano de assinaturas. • Os jogadores operadoras deverão preencher a tabela de preços para os serviços de EF, AF’s e BE, por tempo de conexão em cada trecho de sua propriedade. Tais preços podem ser alterados no decorrer do jogo e devem ser visíveis pelos jogadores que têm acesso a tais informações.

  15. Realidade virtual distribuída e colaborativa • Possibilita que vários usuários geograficamente distribuídos em computadores remotos utilizem o mesmo ambiente virtual, ao mesmo tempo • Cenário típico: visualização de dados • Um mesmo conjunto de dados • Análises e modificações interativas • Interação entre os usuários auxilia na tomada de decisão • Ambientes virtuais distribuídos impõem uma série de requisitos à rede: • Largura de banda • Latência • Jitter, etc.

  16. Realidade virtual distribuída e colaborativa Estação de alto desempenho rodando ENVI/IDL Dispositivo portátil com câmara Estação de desempenho médio rodando R Middleware - Protocolo de Manipulação para Ambientes Virtuais

  17. Arquitetura Middleware(proposta) Aplicação Interface Unidade de Controle Sessões Matemático Selecionador de Estratégias Controlador Adaptativo Sincronismo Q o S Comunicação MIDDLEWARE Rede

  18. Testbed GPRT • Composição • 8 PCs Athlon, 1.3 GHz, 4 pl. rede cada; • Switch 3Com 48 portas; • Software • Linux; Red Hat 7.3 • Nist.Net para emulação de redes • DiffServ / MPLS • Protocolos de roteamento (RIP, OSPF, BGP)

  19. Testbed GPRT • Ferramentas de medição de tráfego • TCPDump • Ethereal • TCPstat (para geração dos gráficos) • Redes de acesso emuladas • Ethernet • ADSL • RDSI • Acesso Discado • WLAN

  20. Testbed – cenário 1 • LAN • Servidor + 2 clientes • Uso de robots (jogadores virtuais) • Parâmetros medidos: vazão, quantidade de pacotes, perda de pacotes, tamanho de pacote

  21. Testbed – cenário 1

  22. Testbed – cenário 2

  23. Testbed – cenário 3

  24. Cronograma • Fase I (CONCLUÍDA) • Identificar claramente as aplicações e seus requisitos (março/2002) • Primeiro ponto de verificação e relatório parcial 1 (reunião BH – 15 de março de 2002) • Fase II (CONCLUÍDA) • Projeto do testbed (reunião SBRC – maio/2002) • Estudo e seleção de funções de middleware (maio/2002) • Segundo ponto de verificação e relatório parcial 2 (maio/2002)

  25. Cronograma • Fase III (EM ANDAMENTO) • Montar o testbed • Topologia de rede (redes de acesso e trânsito) • Tecnologias de rede • Aplicações e Tráfego • Ferramentas de medição • Previsão de conclusão da primeira parte dos testes: outubro/2002 • Executar testes para identificar funcionalidades necessárias às aplicações selecionadas que devem fazer parte do middleware (dezembro/2002) • Terceiro ponto de verificação e relatório parcial 3 (dezembro/2002)

  26. Atividades Realizadas • Identificação das aplicações para teste e seus requisitos básicos de qualidade de serviço • Definição das redes de acesso que serão simuladas e/ou testadas no projeto • Implantação do testbed • Instalação do Nist.Net para emulação de WAN • Definição da arquitetura do testbed • Testes em rede local utilizando um jogo comercial para medição de tráfego

  27. Atividades em andamento • Desenvolvimento de jogo de ação “tipo futebol” para validação final do middleware. • Outubro • Terminar versão sem suporte à rede • Novembro • Suporte à rede com sockets • Dezembro • Suporte à rede com o middleware • Elaboração de um questionário para avaliação qualitativa (percepção do jogador) das condições do jogo. • Tratamento estatístico sobre os resultados das medições realizadas. • Elaboração de novos testes utilizando o testbed (cenários 2 e 3)

  28. Próximas atividades • Fase IV • Especificar as funcionalidades do middleware e as interfaces entre aplicação e middleware • Relatório para o CNPq do primeiro ano do projeto • Implementar middleware e interfaces • Testar, avaliar e otimizar vários aspectos do funcionamento das aplicações e do middleware • Quarto ponto de verificação e relatório parcial 4

  29. Obrigado. www.cin.ufpe.br/~gprt/qosware www.atm.dcc.ufmg.br/qosware Djamel Sadok jamel@cin.ufpe.br

More Related