Apresentação do
Projeto QoSWare
Andamento das atividades
Setembro, 2002
Roteiro
1. O Projeto QoSWare
•
•
•
Objetivo
Visão geral
Aplicações selecionadas
2. Atividades
•
•
Atividades realizadas
Atividades em andamento


•
UFPE
UFMG
Próximas atividades
2
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”
3
Projeto QoSWare
Visão geral
 Equipes
(UFPE)





4
2
1
2
2
Professores
Bolsistas DTI (suzana e Joseane)
Aluno de Mestrado (arthur)
Alunos de Doutorado (cak e vt)
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
4
Projeto QoSWare
Visã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
5
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)
6
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
7
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
8
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
9
Jogo “NetSoccer” - Arquitetura
Jogador
Tempo
Cadastro
Jogadores
Barra
Placar
Campo
Bola
Gerenciador
Partidas Central
Middleware:
Sockets
Gerenciador
Entradas
Cliente
Gerenciador
Gráfico
10
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 / 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.
11
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)
12
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.
13
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.
14
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.
15
Realidade virtual distribuída e
colaborativa
Dispositivo
portátil com
câmara
Estação de
desempenho
médio
rodando R
Estação de alto
desempenho
rodando
ENVI/IDL
Middleware - Protocolo de Manipulação para Ambientes Virtuais
16
Arquitetura Middleware
(proposta)
Aplicação
Interface
Sessões
Unidade de Controle
Selecionador de Estratégias
Matemático
Controlador Adaptativo
Sincronismo
Comunicação
QoS
MIDDLEWARE
Rede
17
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)
18
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
19
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
20
Testbed – cenário 1
Vazão (em bps) - Cliente 1
Nº de Pacotes recebidos e enviados
Cliente 1
4000
Bps
No Pacotes
45
41
37
33
29
25
45
41
37
33
29
25
21
17
13
9
5
45
41
37
0
33
500
0
29
1000
500
25
1500
1000
21
2000
1500
17
2500
2000
13
3000
2500
9
3500
3000
5
4000
3500
1
Nº de Pacote s e nviados e re ce bidos
Se rvidor
4000
1
21
No Pacotes
Vazão (bps ) - Se rvidor
bps
17
1
45
41
37
33
29
25
21
17
13
9
5
1
500
0
13
1500
1000
9
2500
2000
5
4000
3500
3000
2500
2000
1500
1000
500
0
3500
3000
21
Testbed – cenário 2
22
Testbed – cenário 3
23
Cronograma
 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)
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)
24
Cronograma
 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)
25
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
26
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)
27
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
28
Obrigado.
www.cin.ufpe.br/~gprt/qosware
www.atm.dcc.ufmg.br/qosware
Djamel Sadok
[email protected]