comunicação multimídia. sub-sistema de aplicação computação colaborativa = cscw dimensões de...
Post on 07-Apr-2016
219 Views
Preview:
TRANSCRIPT
Comunicação Multimídia
Sub-sistema de Aplicação• Computação colaborativa = CSCW• Dimensões de colaboração
– tempo• trabalho cooperativo assíncrono• trabalho cooperativo síncrono
– escala de usuário• único usuário• multi-usuário (grupo)
– controle• centralizado• distribuído
Dimensões de colaboração (cont.)– escala de usuário (cont.)
• grupo– estático ou dinâmico
– membros: membro, participante, iniciador de conferência, chairman de conferência, token holder, observador
– características e requisitos de membros: homogêneas ou heterogêneas
– controle• centralizado: chairman/gerente controla o trabalho colaborativo e
os membros (agentes) se reportam a ele
• distribuído: cada membro controla suas próprias tarefas
Arquitetura da Comunicação em Grupo• Comunicação em grupo envolve a comunicação de
múltiplos usuários em modo síncrono ou assíncrono com controle centralizado ou distribuído
• Modelo de suporte– Group Rendezvous– Aplicações compartilhadas– Conferência
Group Rendezvous• Métodos síncronos de rendezvous usam
– serviços de diretórios: acessam informações em uma base sobre a conferência, como nome da conferência, participantes registrados, usuários autorizados, nomes e papéis dos participantes
• Ex: ferramenta sd (session directory) do Mbone - usado como guia para anúncio de conferências abertas
– convites explícitos: convites são enviados ponto-a-ponto ou ponto-multiponto para participantes da conferência
• Métodos assíncronos de rendezvous podem ser implementados usando e-mail ou bulletin board, por exemplo
Aplicações Compartilhadas
• Arquitetura centralizada– saída/resultados da aplicação são distribuídos para
todos os sites– vantagem: fácil manutenção– desvantagem: tráfego de rede pesado
Aplicações Compartilhadas (cont.)
• Arquitetura replicada– eventos de entrada (mais leves) são distribuídos e os
resultados computados localmente– vantagens: tráfego de rede reduzido e baixos tempos
de resposta (resultados locais)– desvantagens: ambientes de execução têm que ser
iguais em todos os sites e dificuldade para manutenção de consistência
Aplicações Compartilhadas (cont.)
• Mecanismos para manutenção de consistência de dados entre os membros do grupo:– locks centralizados– floor control: o membro do grupo que tem a vez
(“holds the floor”) tem o direito de manipular objetos compartilhados em janelas compartilhadas
– detecções de dependência
Conferência• Vídeo:
– em conferência com muitos participantes deve haver mecanismos que reduzem o tamanho das imagens para evitar que os recursos de tela se esgotem
• Áudio:– deve haver eliminação de eco
• Armazenamento dos estados da conferência:– centralizado– distribuído
Conferência (cont.)• Controle centralizado
– consistência garantida do estado da conferência– se uma falha em um link de algum participante ocorrer, é
mais difícil restabelecer o estado da conferência• Controle distribuído
– não há garantias que todos os usuários têm a mesma visão do espaço de estado
– consistência eventual através de re-transmissão periódica de estado
– este controle loose funciona bem para grandes conferências
Conferência (cont.)
• Controle distribuído (cont.)– tolerância a falhas inerente: mais fácil
restabelecer o estado da conferência porque não há requisitos estritos de consistência
– escala– desvantagem: participantes podem não ter a
mesma visão do espaço de estado da conferência
Gerência de Sessão• Gerente de sessão:
– separa controle de transporte– funcionalidades locais:
• controle de membership (ex: autenticação de usuário)• controle do espaço compartilhado (ex: floor control)• controle de mídia (ex: sincronização)• gerência de configuração (ex.: seleção de serviços apropriados de acordo
com QoS)• gerência de conferência (estabelecimento, modificação e fechamento de uma
conferência– remotamente o gerente de sessão comunica-se com outros gerentes
de sessão para trocar informações de estado
Gerência de Sessão (cont.)
• Agentes de mídia: responsáveis por decisões específicas para cada tipo de mídia
• Agente de espaço compartilhado: transmite objetos compartilhados (ex.: coordenadas de cursor) entre as aplicações compartilhadas
Arquitetura do controle de sessão
Whiteboardagent
Agentede vídeo Agente
de áudioAgente dedados desensores
Controle deconferência
Controle deconfiguração
Floor controlMembership
control
Controlede mídia
Gerente de sessão
Agentede espaçocompartilhado
Agentesde mídia
Protocolo decontrole de sessão
Protocolo detransporte confiável
Protocolos de transportede tempo-real
Sub-sistema de Transporte
• Aplicações multimídia distribuídas impõem novos requisitos nos projetistas das aplicações, assim como nos projetistas de sistemas e de protocolos de redes
• As aplicações precisam de– bastante throughput– rápido data forwarding– garantias de serviços– multicasting
Rápido data forwarding • Em geral, quanto mais rápido um sistema de
comunicação pode transferir um pacote de dados, menos pacotes precisam de buffer
• Este requisito precisa de um cuidadoso gerenciamento de recursos espaciais (ex.: buffers) e temporais– Uma aplicação como vídeo sob demanda, orientada a
recuperação, um atraso de até 1 segundo é tolerável– Em uma aplicação de vídeo-conferência, orientada a diálogo,
um atraso de mais de 200 ms inibe a comunicação natural entre os usuários
Garantias de serviços
• Aplicações digitais multimídia distribuídas precisam dar garantias de serviço para competir com serviços de televisão e rádio
• Sem gerência de recurso, sistemas multimídia não podem fornecer QoS confiável porque transmissão em recursos não-reservados leva a pacotes perdidos ou atrasados
Camada de Transporte
• Protocolos de transporte, para dar suporte a aplicações multimídia, precisam prover as seguintes funções:– informação de tempo,– semi-confiabilidade,– multicasting,– mecanismo de recuperação de erro baseado em NAK
(None-AcKnowledgment) e– controle de taxa de trasmissão
TCP
• Confiabilidade• Feixe de bytes full-duplex• Aplicações multimídia nem sempre
precisam de conexões full-duplex para o transporte de mídias contínuas– transmissão de TV em rede precisa de
• full-duplex para controle (remoto)• simplex para transmissão de mídia contínua
TCP (cont.)
• Para multimídia, o reconhecimento (acknowledgment) positivo (“o pacote chegou”) causa grande overhead– o ideal seria o reconhecimento negativo
• TCP não é apropriado para transmissão de áudio e vídeo em tempo-real porque o mecanismo de re-transmissão pode causar a violação de deadlines
UDP
• Em geral, UDP não é apropriado para feixes de mídias contínuas porque não fornece a noção de conexões, não podendo assim fornecer diferentes garantias de serviços
Camada de Rede
• Requisitos para a transmissão multimídia:– alta banda passante– multicasting– reserva de recursos– garantias de QoS– novos protocolos de roteamento
• IPv6 é projetado para atender alguns destes requisitos
top related