sistemas multimÍdia - joinville.udesc.br osi 3/44. sistemas multimídia ... •operação plug and...
Post on 19-Jun-2018
216 Views
Preview:
TRANSCRIPT
Sistemas Multimídia 2011/2
UDESC
SISTEMAS MULTIMÍDIA
Prof. Claudinei Dias
Capítulo 4 – Redes IP e o Transporte
de Dados Multimídia
Sistemas Multimídia 2011/2
UDESCEmenta Cap. 4
• 4. Redes IP e o Transporte de Dados Multimídia
– A arquitetura Internet;
– Protocolo IP e a multimídia;
– Requisitos para protocolos de transporte;
– Protocolo TCP;
– Protocolo UDP.
2/44
Sistemas Multimídia 2011/2
UDESCArquitetura TCP/IP
• Nível de Aplicação
• Oferece ao usuário acesso aos serviços da internet– Web (HTML/HTTP)
– Correio Eletrônico (SMTP/POP)
– Conexão Remota (Telnet)
– Transferência de arquivos (FTP)
– Real-Time Transport Protocol (RTP)
– Multimedia Messaging Service (MMS)
7. Aplicação
6. Apresentação
5. Sessão
4. Transporte
3. Rede
2. Enlace
1. Física
Modelo OSI
3/44
Sistemas Multimídia 2011/2
UDESC
• Nível de Transporte
• Transmission Control Protocol(TCP)– Multiplexação e Demultiplexação (Portas)– Fornece comunicação confiável– Sequenciamento de Pacotes– Controle de fluxo e congestionamento
• User Datagram Protocol (UDP)– Multiplexação e Demultiplexação (Portas)
– Serviço sem confiabilidade
7. Aplicação
6. Apresentação
5. Sessão
4. Transporte
3. Rede
2. Enlace
1. Física
Modelo OSI
Arquitetura TCP/IP
4/44
Sistemas Multimídia 2011/2
UDESC
• Nível de Rede
• Internet Protocol (IP)– Serviço de comunicação sem
conexão, baseado em comutação de pacotes
• Mecanismo de roteamento de mensagens– Encaminha os datagramas do nó
fonte para o nó destino
– Utiliza protocolos de roteamentoque atualizam as tabelas de roteamento nos nós intermediários (roteadores)
7. Aplicação
6. Apresentação
5. Sessão
4. Transporte
3. Rede
2. Enlace
1. Física
Modelo OSI
Arquitetura TCP/IP
5/44
Sistemas Multimídia 2011/2
UDESC
• Nível de Enlace e Físico
• Não são definidos padrões específicos na arquitetura da internet
• Objetivo é acomodar diversos tipos de redes existentes
– Possibilidade de usar padrões de redes locais ou protocolos personalizados
7. Aplicação
6. Apresentação
5. Sessão
4. Transporte
3. Rede
2. Enlace
1. Física
Modelo OSI
Arquitetura TCP/IP
6/44
Sistemas Multimídia 2011/2
UDESCProtocolo IP e Multimídia
• IPv4
– Amplamente usado nas redes atuais
– Endereços de rede de 32-bits
– IPv4 Multicast
• Extensão do IPv4 para suportar multicast
• IPv6
– Evolução do IPv4, introduz novas características
– Endereços de rede de 128-bits
7/44
Vídeo Warriors Of The Net - http://www.youtube.com/watch?v=tFKVFWfC2nk&feature=related
Sistemas Multimídia 2011/2
UDESCProtocolo IP e Multimídia
• Protocolo IP oferece serviço de “melhor esforço”
• Problema?
– Não garante vazão, atraso, variação de atraso e taxa de perda de pacotes
– Não garante qualidade de apresentação de áudio e vídeo
– No caso de sobrecarga da rede, pacotes podem ser descartados
• Geralmente ocorre nas filas dos roteadores
8/44
Sistemas Multimídia 2011/2
UDESCIP Multicast
• Suportado no IPv4 (extensão)
• Permite o envio de datagramas IP para um conjunto de máquinas
– Grupo multicast é identificado por um endereço IP
• Existe uma distinção dos pacotes unicast e multicast
– Roteador distingue os tipos de pacotes olhando no formato do endereço de destino
– Pacotes Multicast: 4 primeiros bits do endereço IP tem o valor “1110” (classe D), demais bits identificam o grupo multicast
9/44
Sistemas Multimídia 2011/2
UDESCIPv6
• Proposto em 1992 pelo Internet Engineering Task Force– Motivação: espaço de endereçamento disponível no IPv4 terminaria
no início do século 21
• Projetado para melhorar o IPv4– Aumento do espaço de endereçamento
– Autenticação
– Criptografia
– Extensões para fluxos de dados multimídia
• Compatibilidade com o IPv4– Uma das metas principais do projeto IPv6
– Hosts e roteadores IPv6 são capazes de co-existir com hosts IPv4
• Migração gradativa
10/44
Sistemas Multimídia 2011/2
UDESCIPv6 - Características
• IPv6 se baseia nos principais paradigmas do IPv4
– Sem conexão, sem controle de erro e de fluxo na camada de rede
– Oferece serviço de “melhor esforço”
• Suporte a bilhões de hosts
– Expansão do espaço de endereçamento (128 bits)
– Mais níveis de hierarquia
11/44
Sistemas Multimídia 2011/2
UDESCIPv6 - Características
• Permissão de multicast
– Campo scope no endereçamento limita o seus domínio de validade
• Redução da tabela de roteamento e melhoria no roteamento
– Inclusão de hosts móveis
• Extensibilidade através do uso dos cabeçalhos de extensão
12/44
Sistemas Multimídia 2011/2
UDESCIPv6 - Características
• Identificação dos pacotes de um mesmo fluxo (campo flow)
• Fluxo é uma sequencia de pacotes enviados por um host para um endereço unicast ou multicast
• Todos os roteadores podem identificar os pacotes de um fluxo e tratá-los de modo específico
– Exemplo: priorizar pacotes de áudio sobre pacotes de transferência de arquivos
13/44
Sistemas Multimídia 2011/2
UDESCIPv6 – Novas Características
• Simplificação do cabeçalho do protocolo
– Diminuição do tempo de processamento na análise dos cabeçalhos
• Garantia de mais segurança
– Autenticação e criptografia
• Recursos para mobilidade em redes IP
• Operação plug and play
– Habilidade dos nós se auto configurarem ao serem ligados na rede
• Novo tipo de endereço: anycast
– Identifica um grupo de nós
– O pacote enviado será entregue a um destes nós do grupo
14/44
Sistemas Multimídia 2011/2
UDESCRequisitos para Protocolos de Transporte Multimídia
• Quais são os requisitos básicos para um protocolo de transporte, visando Sistemas Multimídia?
– Abstrair as funções e serviços oferecidos pelos níveis de enlace e físico
– Alta vazão
– Suporte multicast
15/44
Sistemas Multimídia 2011/2
UDESCRequisitos para Protocolos de Transporte Multimídia
• Alta Vazão
• Dados multimídia necessitam de grande largura de banda– Vídeo de qualidade compactado necessita de 1,4 à 8 Mbps (ou mais)
• Requisitos de vazão do ponto de vista da aplicação?– Todos os dados passam pela pilha de transporte.
– Qual(is) seria(m) o(s) requisito(s)?
• Protocolo de transporte deve ser rápido o suficiente para suportar os requisitos de grande largura de banda
– Aplicações podem envolver vários fluxos de dado.
– Qual(is) seria(m) o(s) requisito(s)?
• Velocidade do protocolo de transporte deve ser maior que a largura de banda agregada dos fluxos
16/44
Sistemas Multimídia 2011/2
UDESCRequisitos para Protocolos de Transporte Multimídia
• Alta Vazão
• Requisitos do ponto de vista do sistema de comunicação?
– Vazão de um protocolo de transporte deve ser maior ou próxima a velocidade de acesso a rede
– Senão a largura de banda fornecida pelos pontos de acesso a rede não poderiam ser inteiramente usados• Protocolo de transporte seria o gargalo no sistema de
comunicação
17/44
Sistemas Multimídia 2011/2
UDESCRequisitos para Protocolos de Transporte Multimídia
• Multicast
• Muitas aplicações multimídia exigem multicast
– Sistema de transporte deve fornecer capacidades multicast
• Multicast é implementado na camada de rede
– Muitos sistemas de transporte multimídia usam o algoritmo IP multicast
– Ou assumem a existência de certos algoritmos de roteamento multicast
18/44
Sistemas Multimídia 2011/2
UDESCProtocolo TCP
• Projetado para comunicação de dados confiável em redes de baixa largura de banda e altas taxas de erro
• Problema?– Não é otimizado para operações de alta velocidade
– Não fornece suporte a multicast
– Não atende todos os requisitos para comunicações de vários tipos de aplicações multimídia
• TCP possui aspectos indesejáveis para multimídia.
• Quais?– Controle de erro
– Controle de fluxo e de congestionamento
– Não suporte a multicast
19/44
Sistemas Multimídia 2011/2
UDESCProtocolo TCP: Controle de Erro
Porta Origem Porta Destino
Número da Seqüencia
Número do Acknowledge
JanelaTam.Cab. Res. Code Bits
Checksum Urgência
Opções Padding
Dados
...
20/44
Sistemas Multimídia 2011/2
UDESCProtocolo TCP: Controle de Erro
• Quando um nó transmite um segmento, ele:
– Coloca uma cópia do segmento em uma fila de retransmissão e dispara um temporizador
– Caso o reconhecimento do segmento é recebido, o segmento é retirado desta fila
– Caso o reconhecimento não ocorra antes do temporizadorexpirar, o segmento é retransmitido
21/44
Sistemas Multimídia 2011/2
UDESCCenários de Retransmissão
Host A Host B
PerdaXti
meo
ut
Ack Perdido
22/44
Sistemas Multimídia 2011/2
UDESCCenários de Retransmissão
Host A Host BSe
q=9
2 t
imeo
ut
Seq
=10
0 t
imeo
ut
Timeout prematuro,Ack acumulativo
23/44
Sistemas Multimídia 2011/2
UDESCControle de Erro e Multimídia
• Retransmissão não é ideal para várias aplicações multimídia
• Porque?– Protocolo fica complicado e lento
• Implementação de estratégias de retransmissão necessitam de temporizadores e buffers maiores
– Retransmissão causa atrasos para os dados subsequentes
• Mais dados sem utilidade no receptor
– Dados multimídia toleram alguns erros ou perdas
• Aplicável somente em aplicações baseadas em servidor para aumentar a qualidade– Requer tempos de bufferização maiores
24/44
Sistemas Multimídia 2011/2
UDESCControle de Erro e Multimídia
• Em várias aplicações multimídia somente a detecção de erros é suficiente– Quando acontecer um erro, a aplicação deveria ser notificada
– Aplicação decide se a retransmissão é necessária
• Retransmissão Seletiva: pacotes perdidos são retransmitidos
• Alternativa: usar codificação Forward Error Correction (FEC)– Não necessita de retransmissão quando erros são detectados
– Envio de informações extras para permitir a correção de erros no receptor
– Problema?
• Consumo adicional de banda
25/44
Sistemas Multimídia 2011/2
UDESCRecuperação de Perdas de Pacotes
• Paridade bidimensional
– Paridade tanto da linha como da coluna
– Erro em um único bit pode ser corrigido
101011
111100
011101
001010
Sem erros
101011
110100
011101
001010
Correção do erro de bit
26/44
Sistemas Multimídia 2011/2
UDESCRecuperação de Perdas de Pacotes
• Intercalar fluxos de alta e baixa qualidade
– Vantagem?
• Na perda de pacotes, a informação de baixa qualidade é apresentada
– Desvantagem?
• Mau uso da largura de banda
• Perdas em rajada não são bem tratadas
• Como resolver esses problema?
27/44
Sistemas Multimídia 2011/2
UDESCEntrelaçamento de Pacotes
• Não tem redundância, mas causa atraso na apresentação
– Exemplo: dividir audio de 20 ms em pacotes de 5 ms, e entrelaçados
28/44
Sistemas Multimídia 2011/2
UDESCEntrelaçamento
Vantagem? Reduz perda em rajada
29/44
Sistemas Multimídia 2011/2
UDESCProtocolo TCP: Controle de Fluxo
Porta Origem Porta Destino
Número da Seqüencia
Número do Acknowledge
JanelaTam.Cab. Res. Code Bits
Checksum Urgência
Opções Padding
Dados
...
30/44
Sistemas Multimídia 2011/2
UDESCProtocolo TCP: Controle de Fluxo
• Mecanismo usado pelo receptor para determinar o volume de dados que o transmissor envia
– Janela deslizante
• Receptor envia, junto com o acknowledge, o número de bytes que ele ainda pode receber
– Considera-se o último pacote recebido com sucesso
31/44
Sistemas Multimídia 2011/2
UDESCProtocolo TCP: Controle de Fluxo
• Tamanho típico da janela é 64 Kb
• Muito grande para redes lentas– Rede de 64 Kbps leva 8s para transmitir 64kbytes
– Atraso de ida-e-volta normal é muito menor que 8s
– Transmissor receberá um reconhecimento antes de acabar o envio dos bits de uma janela
• Muito pequeno para rede rápidas– Transmissor aguardará muito para receber a permissão de transmissão
– Largura de banda não é inteiramente utilizada
– Transmissor enviará 64 Kbytes em 50 ms na velocidade de 10 Mbps
– Em WAN o atraso ida-e-volta é normalmente muito maior que 50 ms
32/44
Sistemas Multimídia 2011/2
UDESCProtocolo TCP: Controle de Congestionamento
• “Excessivo número de fontes enviando uma grande quantidade de dados mais rápido do que a rede pode manipular”
• Conseqüências?
– Pacotes perdidos (overflow dos buffers nos roteadores)
– Grandes atrasos (enfileiramento nos buffers dos roteadores)
• Um grande problema de rede!
33/44
Sistemas Multimídia 2011/2
UDESCProtocolo TCP: Controle de Congestionamento
Host A Host BAlgoritmo de Partida Lenta
• Incremento exponencial no tamanho dajanela• Janela aumenta enquanto não houverperda ou o treshold for alcançado• Perda = timeout ou 3 ACKs duplicados
34/44
Sistemas Multimídia 2011/2
UDESCProtocolo TCP: Controle de Congestionamento
• Fase de prevenção de congestionamento
– Inicia quando o tamanho da janela ultrapassa o threshold
– A partir daí, a janela cresce linearmente
• Na ocorrência de um timeout
– Valor do threshold é modificado para a metade do valor da janela de congestionamento atual
– Janela de congestionamento atual = número de segmentos permitidos para transmitir quando ocorreu a perda
– Partida lenta é reiniciada
35/44
Sistemas Multimídia 2011/2
UDESCProtocolo TCP e Multimídia
• Controle de erros e retransmissão
– Não é interessante para várias aplicações multimídia
• Controle de congestionamento e de fluxo
– Requer que a aplicação se adapte a situação da rede
– Também não é interessante para várias aplicações multimídia• Requer que a rede suporte a taxa de apresentação (+sobrecargas
do protocolo)
• Multicasting
– Não suportado
37/44
Sistemas Multimídia 2011/2
UDESCProtocolo UDP
• Não oferece meios que permitam uma transferência confiável de dados
• Não tem controle da taxa de transmissão entre os nós
• Não implementa mecanismos de reconhecimento, de seqüencialização, nem de controle de fluxo das mensagens
38/44
Sistemas Multimídia 2011/2
UDESCProtocolo UDP
• Datagramas podem ser perdidos, duplicados, ou entregues fora de ordem ao sistema de destino
• Aplicação assume toda a responsabilidade pelo controle de erros
• Serve para transportar uma mensagem de uma estação para outra, utilizando o IP para enviar e receber estes datagramas
39/44
Sistemas Multimídia 2011/2
UDESCProtocolo UDP
• É um protocolo simples – Latência menor
• Usa mais eficientemente a banda da rede– Cabeçalho por segmento é menor
– Sem controle de congestionamento e de fluxo: permite usar a banda de maneira mais eficiente
– Pode provocar taxa de perdas altas e perdas
• Muito usado para aplicações multimídia de streaming– Tolerantes a perda
– Sensíveis a taxa
• Transferência confiável sobre UDP– Adicionar confiabilidade na camada de aplicação
– Recobrimento de erro específico de aplicação
40/44
Sistemas Multimídia 2011/2
UDESCProtocolo UDP e Multimídia
• Serviço orientado datagrama simples sem confiabilidade
– Melhor para aplicações multimídia (nem todas!)
• Aplicações podem rodar no topo do UDP com funções adicionais integradas nas aplicações
– Delegando-se às estações o recobrimento das dificuldades que a rede tem quanto a garantias de serviço• Técnicas de bufferização
• Protocolos de transporte melhores adaptados (RTP)
41/44
Sistemas Multimídia 2011/2
UDESCProtocolos Application Level Framing (ALF)
• Inclusão de estratégias de controle de fluxo ou retransmissão na aplicação
• Para suportar a interoperabilidade
– Protocolos ALF são definidos pela especificação dos formatos da unidade de dados de protocolo
– Protocolos ALF não definem algoritmos para controle de fluxo e retransmissão• Estes são baseados nos requisitos das aplicações
• RTP é um bom exemplo de projeto de protocolo baseado no ALF
42/44
Sistemas Multimídia 2011/2
UDESCBibliografia
• WILLRICH, R. Sistemas Multimídia Distribuídos. Apostila do curso de Especialização em Redes de Computadores, UFSC, agosto, 2004.
• KERLOW, I. V. Art of 3D computer animation and effects , The - 4th ed / c2009
• VELHO, L. Anais do SIBGRPI 96 : IX Simpósio Brasileiro de Computação Gráfica e Processamento de Imagens - 1 ed. / 1996
• AGNEW, P. W.; KELLERMAN, A. S. Distributed Multimedia: Technologies, Applications, andOpportunities in the Digital Information Industry. A Guide for Users and Providers. AddisonWesley, 1996.
• ENGLAND, E.; FINNEY, A.; FINNEY, A. Managing Multimedia. Addison Wesley, 1996.
• GIBSON, J. D.; BERGER, T.; LINDBERGH, D. Digital Compression for Multimedia: Principles andStandards. Morgan Koufman, 1998.
• FLUCKIGER, F. Understanding Networked Multimedia: applications and technology. Prentice Hall, 1995.
• STEINMETZ, R, NAHRSTEDT, R. Multimedia: computing, communications & applications. Prentice Hall, 1995.
43/44
Sistemas Multimídia 2011/2
UDESC
SISTEMAS MULTIMÍDIA
Prof. Claudinei Dias
Capítulo 4 – Redes IP e o Transporte
de Dados Multimídia
top related