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 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 Whiteboard agent Agente de vídeo Agente de áudio Agente de dados de sensores Controle de conferência Controle de configuração Floor control Membership control Controle de mídia Gerente de sessão Agente de espaço compartilhado Agentes de mídia Protocolo de controle de sessão Protocolo de transporte confiável Protocolos de transporte de 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