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