Apresentação do Projeto QoSWare

Andamento das atividades

Apresentação do Apresentação do Projeto QoSWareProjeto QoSWare

Setembro, 2002

2

RoteiroRoteiro

1. O Projeto QoSWare • Objetivo• Visão geral• Aplicações selecionadas

2. Atividades• Atividades realizadas• Atividades em andamento

UFPE UFMG

• Próximas atividades

3

Projeto QoSWareProjeto 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 QoSWareProjeto QoSWareVisão geralVisã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 QoSWareProjeto QoSWareVisão geralVisã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 redeJogos 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 redesJogos 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” - ObjetivosJogo “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ísticasJogo “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” - ArquiteturaJogo “NetSoccer” - Arquitetura

Gerenciador Partidas Central

Jogador PlacarTempo Barra

Cadastro Jogadores

Campo Bola

Middleware: Sockets

ClienteGerenciador Gráfico

Gerenciador Entradas

11

Jogos empresariaisJogos 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 / funcional de 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”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


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


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 Realidade virtual distribuída e colaborativacolaborativa 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 Realidade virtual distribuída e colaborativacolaborativa

Estação de Estação de desempenho desempenho

médio médio rodando Rrodando R

Estação de alto Estação de alto desempenho desempenho

rodando rodando ENVI/IDLENVI/IDL

MiddlewareMiddleware - - Protocolo de Manipulação para Ambientes VirtuaisProtocolo de Manipulação para Ambientes Virtuais

DispositivoDispositivoportátil com portátil com

câmaracâmara

17

Arquitetura MiddlewareArquitetura Middleware(proposta)(proposta)

Interface

Unidade de ControleMatemático

Aplicação

Sincronismo

Rede

Comunicação Q o S

Sessões

MIDDLEWARE

Selecionador de Estratégias

Controlador Adaptativo

18

Testbed GPRTTestbed 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 GPRTTestbed 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 1Testbed – 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


Vazão (em bps) - Cliente 1

0

500

1000

1500

2000

2500

3000

3500

4000

1 5 9 13

17

21

25

29

33

37

41

45

Bps

Nº de Pacotes recebidos e enviadosCliente 1

0500

1000150020002500300035004000

1 5 9 13

17

21

25

29

33

37

41

45

No Pacotes

Vazão (bps) - Servidor

0

500

1000

1500

2000

2500

3000

3500

4000

1 5 9 13

17

21

25

29

33

37

41

45

bps

Nº de Pacotes enviados e recebidosServidor

0

500

1000

1500

2000

2500

3000

3500

4000

1 5 9 13

17

21

25

29

33

37

41

45

No Pacotes

22


23


24

CronogramaCronograma

Fase I (CONCLUÍDA)Fase I (CONCLUÍDA)1. Identificar claramente as aplicações e seus requisitos

(março/2002)2. Primeiro ponto de verificação e relatório parcial 1 (reunião

BH – 15 de março de 2002)

Fase II (CONCLUÍDA)Fase II (CONCLUÍDA)3. Projeto do testbed (reunião SBRC – maio/2002)4. Estudo e seleção de funções de middleware (maio/2002)5. Segundo ponto de verificação e relatório parcial 2

(maio/2002)

25

Fase III (EM ANDAMENTO)Fase III (EM ANDAMENTO)6. 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

7. Executar testes para identificar funcionalidades necessárias às aplicações selecionadas que devem fazer parte do middleware (dezembro/2002)

8. Terceiro ponto de verificação e relatório parcial 3 (dezembro/2002)

CronogramaCronograma

26

Atividades RealizadasAtividades 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 andamentoAtividades 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 atividadesPróximas atividades

Fase IVFase 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

Obrigado.Obrigado.

www.cin.ufpe.br/~gprt/qosware

www.atm.dcc.ufmg.br/qosware

Djamel [email protected]

Documents

Apresentação do Projeto QoSWare