Protocolos de Multicast na Camada de Aplicação para Streaming

Fundação Universidade Federal do Rio Grande
Engenharia de Computação
MulticastStreaming
na Camada de
Protocolos de
Aplicação para
Felipe Lopes Madruga
Rio Grande, 1 de Abril de 2008
Fundação Universidade Federal do Rio Grande
Engenharia de Computação
MulticastStreaming
na Camada de
Protocolos de
Aplicação para
Felipe Lopes Madruga
Trabalho
de
de
Graduação
Conclusão
em
do
Engenharia
Curso
de
Computação submetido à avaliação, como
requisito parcial à obtenção do título de
Engenheiro de Computação.
Orientador(a): Prof. Dr. Nelson Lopes Duarte Filho
Rio Grande, 1 de Abril de 2008
Este trabalho foi analisado e julgado adequado para a obtenção do título de Engenheiro
de Computação e aprovado em sua forma nal pelo orientador.
Prof. Dr. Nelson Lopes Duarte Filho
Banca Examinadora:
Prof. Dr. Nelson Lopes Duarte Filho
Departamento de Matemática - FURG
Profa . Dra . Silvia da Silva Costa Botelho
Departamento de Física - FURG
Prof. MSc. Celso Luiz Lopes Rodrigues
Departamento de Matemática - FURG
Dedico esse trabalho aos meus pais.
Agradecimentos
De forma especial, agradeço à minha família por me apoiar em todos os
momentos, tornando mais fácil a conquista do diploma de nível superior.
Agradeço ao professor Nelson Lopes Duarte Filho pela orientação, paciência
e ajuda. O meu aprendizado com ele foi de extrema importância na minha
carreira acadêmica.
Agradeço também a minha namorada Aline pelo apoio e principalmente pela
ajuda nos momentos difíceis.
Finalmente, agradeço aos meus poucos, porém muito bons amigos pelos bons
momentos que passamos juntos.
Conteúdo
Lista de Figuras
iii
Lista de Tabelas
iv
Lista de Abreviaturas
v
Resumo
vii
Abstract
viii
1 Introdução
2
Streaming
4
2.1
Construção de um Sistema de
Streaming . . . . . . . . . . . . . . . . . . .
6
2.2
Qualidade de Serviço . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7
2.3
Streaming sobre TCP/UDP . . . . . . . . . . . . . . . . . . . . . . . . . .
8
2.3.1
Transport Control Protocol (TCP) . . . . . . . . . . . . . . . . . .
8
2.3.2
User Datagram Protocol (UDP) . . . . . . . . . . . . . . . . . . . .
9
2.4
3
1
Protocolos Especializados
. . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.4.1
Real-Time Streaming Protocol (RTSP) . . . . . . . . . . . . . . . . 10
2.4.2
Real-Time Transport Protocol (RTP) . . . . . . . . . . . . . . . . . 11
Multicast na Camada de Aplicação
3.1
13
Alguns Protocolos de Application-Layer Multicast (ALM) . . . . . . . . . . 14
3.1.1
YOID . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
3.1.2
Host Multicast Tree Protocol (HMTP) . . . . . . . . . . . . . . . . 16
i
CONTEÚDO
ii
3.1.3
Application-Level Multicast Infrastructure (ALMI) . . . . . . . . . 17
3.1.4
NICE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
3.1.5
Bayeux . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
3.1.6
CAN-Multicast . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
3.1.7
Narada . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
3.2
Comparação entre os Protocolos Apresentados . . . . . . . . . . . . . . . . 20
4 O Protótipo
4.1
21
Descrição da Proposta . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
4.1.1
Rede Sobreposta . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
4.1.2
Topologia de Controle . . . . . . . . . . . . . . . . . . . . . . . . . 22
4.1.3
Topologia de Dados . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
4.2
Implementação do Sistema . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
4.3
Funcionamento do Protótipo . . . . . . . . . . . . . . . . . . . . . . . . . . 27
4.4
Experimentos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
4.5
Trabalhos Completos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
5 Conclusão
30
Bibliograa
32
Lista de Figuras
1.1
Possibilidades de entrega de dados. . . . . . . . . . . . . . . . . . . . . . .
3
2.1
Diagrama representando
download. . . . . . . . . . . . . . . . . . . . . . .
5
2.2
Diagrama representando
streaming. . . . . . . . . . . . . . . . . . . . . . .
5
2.3
Variações no sistema podem interromper a reprodução da mídia. . . . . . .
6
2.4
Diagrama de tempo em uma transmissão RTSP. . . . . . . . . . . . . . . . 11
3.1
Modelo de Referência TCP/IP. . . . . . . . . . . . . . . . . . . . . . . . . 13
3.2
Tipos de árvores de distribuição. . . . . . . . . . . . . . . . . . . . . . . . . 15
3.3
Modelo de Camadas do NICE. . . . . . . . . . . . . . . . . . . . . . . . . . 18
3.4
Estrutura de um Content-Addressable Network (CAN). . . . . . . . . . . . 19
4.1
Tipos de registros empregados no sistema. . . . . . . . . . . . . . . . . . . 22
4.2
Exemplo do processo de entrada. . . . . . . . . . . . . . . . . . . . . . . . 25
4.3
Camadas do sistema implementado. . . . . . . . . . . . . . . . . . . . . . . 26
4.4
Tela principal do protótipo. . . . . . . . . . . . . . . . . . . . . . . . . . . 28
iii
Lista de Tabelas
3.1
Comparação entre protocolos de ALM. . . . . . . . . . . . . . . . . . . . . 20
4.1
Comparação entre arcabouços para programação P2P. . . . . . . . . . . . . 26
iv
Lista de Abreviaturas
ALM Application-Layer Multicast
ALMI Application-Level Multicast Infrastructure
API Application Program Interface
CAN Content-Addressable Network
FURG Fundação Universidade Federal do Rio Grande
HMTP Host Multicast Tree Protocol
HTTP HyperText Transfer Protocol
ICMP Internet Control Message Protocol
IGMP Internet Group Management Protocol
IP Internet Protocol
ISP Internet Service Provider
JMF Java Media Framework
JRE Java Runtime Environment
LAN Local Area Network
MMS Microsoft Media Streaming
P2P Peer-to-Peer
RDT RealNetworks Data Transport
v
LISTA DE TABELAS
RP Rendezvous Point
RTCP Real-Time Control Protocol
RTP Real-Time Transport Protocol
RTSP Real-Time Streaming Protocol
RTT Round-Trip Time
TCP Transport Control Protocol
UDP User Datagram Protocol
WWW World Wide Web
vi
Resumo
O envio de um uxo contínuo de dados (streaming) para um grupo de computadores da
Internet de forma eciente é um problema principalmente devido ao fato da funcionalidade
de
multicast do protocolo Internet Protocol (IP) ser de difícil utilização e pouca
disponibilidade. Uma sugestão para solucionar essa questão é realizar tal função em
camadas superiores da pilha de protocolos, sendo tal proposta chamada de
multicast na
camada de aplicação. Essa alternativa utiliza somente o modelo de comunicação
unicast
do protocolo IP, deixando todas as questões de criação e manutenção dos grupos para
a camada de aplicação. Usando esse modelo de comunicação, foram projetados vários
protocolos com diversas peculiaridades. A utilização desse paradigma é uma alternativa
viável tanto para baratear os custos de grandes empresas que desejem enviar uxos para
um grande número de usuários, quanto para usuários ao redor do mundo, que queiram
utilizar os computadores domésticos para formar uma grande estrutura de transmissão.
Esse trabalho analisa quais protocolos podem ser ecientes em criar um ambiente propício
para
streaming, bem como as principais características a serem levadas em conta. Além
disso, é proposto um modelo de construção de árvores de distribuição usando uma
combinação de técnicas, visando maior descentralização e escalabilidade em relação às
propostas atuais. Para demonstrar a funcionalidade foi construído um protótipo para
publicação de uxos e transmissão de mídia contínua através de um protocolo ApplicationLayer Multicast (ALM) e de um sistema Peer-to-Peer (P2P).
Palavras-chave: Multicast na camada de aplicação, redes sobrepostas, streaming.
vii
Abstract
The delivery of a continuous data ow (streaming) to a group of computers on the Internet
eciently is a problem, mainly due to the diculty of use and the limited availability of
the
multicast funtionality of the IP protocol. One sugestion to solve this issue is to
perform such function in upper layers of the protocol stack, and that proposal is called
Application-Layer Multicast. This alternative uses only the unicast communication model
from the IP protocol, leaving all the concerns about creation and maintenance of groups
to the application layer. Many protocols were designed using this communication model,
each one with its own peculiarities. The use of this paradigm is a feasible alternative for
both minimize the costs of large companies wishing to send streams to a large number
of users, and for users around the world, who want to use home computers to form a
large structure of transmission. This work examines which protocols can be eective
in creating an environment conducive to
streaming, as well as the main features to be
taken into account. In addition, it proposes a model of building distribution trees using a
combination of techniques, seeking greater decentralization and scalability on the today
proposals. Intending to demonstrate the functionality, a prototype was built to perform
publication and transmission of streams of continuous media through a Application-Layer
Multicast (ALM) protocol and a P2P system.
Keywords:
Application-Layer Multicast, overlay networks,
viii
streaming.
Capítulo 1
Introdução
A transmissão de dados como vídeo e áudio consome uma grande largura de banda em
relação a um arquivo de texto, uma imagem ou qualquer documento típico da World Wide
Web (WWW). O envio dessas mídias contínuas [Lee, 2005] (que possuem embutidos em
si restrições de tempo), sendo elas consumidas antes da recepção de sua última parte, é
chamado de streaming e geralmente se dá em uma relação de um transmissor para muitos
receptores. Quando há muitos clientes em uma transmissão, a técnica de entrega mais
indicada é o
multicast.
Notadamente, a respeito do consumo de largura de banda, o ideal seria a duplicação de
pacotes acontecer nos roteadores, para o tráfego gerado ser o menor possível. Entretanto,
a infraestrutura atual da
Internet não disponibiliza de maneira satisfatória o serviço de
entrega a vários receptores com esse modelo de comunicação. Assim, o que acontece na
maioria das vezes é um transmissor ter uma comunicação
gerando um gargalo.
unicast com cada receptor,
Uma outra opção é realizar o roteamento e a construção das
árvores de distribuição nos
hosts nais. O multicast IP, incumbido de implementar essa
funcionalidade na camada de rede, ainda não é totalmente habilitado na
seguir, apresentamos alguns motivos para isso [Diot et al., 2000].
• manutenção custosa de controle de grupos;
• problemas de segurança;
• localização de endereços pouco escalável;
1
Internet. A
CAPÍTULO 1.
2
INTRODUÇÃO
• robustez, controle de congestionamento, problemas de controle de uxo;
• disponibilização lenta por parte dos Internet Service Provider (ISP)s.
Para tornar o processo de streaming mais escalável, algumas pesquisas sobre multicast
direcionaram-se para camadas superiores [Abad et al., 2004].
Nesses métodos todas
as funcionalidades de criação e manutenção dos grupos são feitas pelos
por isso, eles são chamados de ALM ou
end-host multicast.
podemos mais facilmente contornar os problemas do
hosts nais;
Com essa solução,
multicast IP. Desse modo, a
tarefa de disponibilização ca muito facilitada por não requerer nenhuma modicação
na infraestrutura da
Internet existente.
Segundo o modelo de referência TCP/IP
[Tanenbaum, 2003], a camada inter-redes (implementada através do protocolo IP) é
responsável por fazer com que os pacotes injetados em uma rede cheguem ao seu
destino. Portanto, realizar
multicast na camada de aplicação vai de encontro a teoria
que fundamentou a criação desse modelo.
Existem algumas desvantagens e vantagens nessa abordagem. A diferença essencial
entre o
nos
multicast IP e o ALM é que a duplicação dos pacotes no último é feita
hosts nais.
Essa duplicação feita nos
hosts gera desperdício de largura de
banda, atraso e, portanto, uma queda de performance considerável. Uma vantagem
é a utilização de recursos como a capacidade de processamento e armazenamento
dos computadores responsáveis pelo roteamento.
Bons exemplos que tiram proveito
disso são os de distribuição de conteúdo multimídia adaptativos (e.g., transcodicação
[J. Youn and Sun, 2000] e codicação em camadas [Lee, 2005]). A gura 1.1 retirada
de [Chu et al., 2000] ilustra quatro possibilidades de entrega de dados a partir de
um transmissor A para os receptores B, C e D, onde R1 e R2 são roteadores. Na
gura identicam-se (a) Ambiente do exemplo; (b) Múltiplos uxos
transmissor; (c)
unicast a partir do
Multicast na camada de rede; (d) Multicast na camada de aplicação.
Muitos são os serviços de distribuição de vídeo na Internet. O mais popular atualmente
é o
youtube [Youtube, 2008]. Sistemas como o youtube são chamados de vídeo sob
demanda, pois os vídeos são requisitados e, em seguida, enviados. Existem, portanto,
restrições diferentes das de um vídeo ao vivo, digamos, da exibição de um jogo de futebol,
por exemplo. Essas diferenças são essenciais para a elaboração do arcabouço que torna
CAPÍTULO 1.
3
INTRODUÇÃO
Figura 1.1: Possibilidades de entrega de dados.
possível sua implementação. Aqui levamos em consideração transmissões que não são sob
demanda, ou assíncronas.
O desao de construir um protocolo de multicast na camada de aplicação eciente para
sistemas de
streaming, como rádio e televisão pela Internet, é abordado nesse trabalho.
Propomos também uma solução que visa atender primordialmente a dois requisitos desses
sistemas: escalabilidade e descentralização.
No próximo capítulo são apresentados tópicos sobre
streaming, os dados geralmente
envolvidos e as questões que caracterizam essa categoria de aplicações. No capítulo 3, são
abordados os protocolos utilizados para comunicação em grupo em redes sobrepostas e são
discutidos exemplos e características. Após, o capítulo 4 se refere ao protótipo decorrente
deste trabalho, bem como questões acerca da sua implementação. Finalmente, são feitas
considerações nais sobre ALM e o seu futuro, no capítulo 5.
Capítulo 2
Streaming
Na
Internet, há vários tipos de mídia, como imagens, áudio, texto e vídeo. No contexto
deste trabalho, é interessante classicar os tipos de mídia em dois grupos [Lee, 2005]:
mídia discreta e mídia contínua.
Consideremos um cliente utilizando um navegador para abrir uma página que contém
uma imagem. Essa imagem será transferida do servidor web para a máquina cliente em um
tempo que depende da largura de banda disponível, e então decodicada e apresentada.
Embora seja bom minimizar o tempo da transferência, não existe restrição rígida quanto
ao tempo que a imagem vai levar pra ser apresentada e, após concluída a apresentação, o
processo está terminado. Isso é um exemplo de mídia discreta.
Já na mídia contínua, há requerimentos explícitos de tempo embutidos nos dados.
Bons exemplos dessa classe de mídia são áudio e vídeo. Esses dados, em muitos casos, são
consumidos à medida em que são recebidos; as próximas partes que vão sendo recebidas são
essenciais para a integridade da informação e devem estar disponíveis no cliente assim que
forem necessárias para apresentação. Desse modo, o tráfego na rede para uma transmissão
desse tipo precisa manter certos parâmetros para proporcionar a integridade de tempo.
Variações quanto aos tempos de chegada dos dados, e outros parâmetros, são classicados
entre quesitos de qualidade de serviço, tópico exposto em uma seção deste capítulo.
A relação temporal entre transferência e consumo desse tipo de dados denota a
diferença entre download(mídia discreta) e streaming(mídia contínua). A gura 2.1 mostra
um diagrama representando um
download, e a gura 2.2 mostra o mesmo no caso de um
streaming. Obviamente, é possível realizar um download de um arquivo de áudio ou
4
CAPÍTULO 2.
STREAMING
5
vídeo. Porém, em alguns casos, é melhor consumir os dados enquanto eles são recebidos,
reduzindo drasticamente o atraso do início da reprodução.
Figura 2.1: Diagrama representando
download.
Figura 2.2: Diagrama representando
streaming.
Este trabalho trata da construção de um arcabouço para realizar streaming sobre uma
rede sobreposta (overlay). Tendo isso em vista, as próximas seções discorrem a respeito
das questões envolvidas com esse tipo de aplicação.
CAPÍTULO 2.
2.1
STREAMING
6
Construção de um Sistema de
Streaming
Uma das preocupações que devemos ter ao construir um sistema de
streaming é que os
fragmentos de dados sejam entregues ao cliente a tempo de manter a continuidade da
apresentação da mídia. É preciso estabelecer em que momento a reprodução deve iniciar
depois que o processo de
streaming começou. Uma vez que é iniciada a exposição dos
dados, o momento de reprodução de todos os outros fragmentos será xado. Quanto maior
for o atraso para o início da reprodução, maior será o tempo para realizar a transferência
dos dados. Entretanto, não se pode atrasar demais o início da reprodução, o que é uma
métrica importante de desempenho.
Além disso, a performance de um sistema de
streaming possui diversas variações
devidas à performance de cada componente individual do sistema. Os principais fatores
que podem causar variações são, no servidor, o processo de compressão de dados, a
passagem dos dados comprimidos ao
buer de memória do servidor, a preparação dos
pacotes e o envio destes. No cliente, a eciência do sistema pode variar principalmente
por causa do processo de decodicação. Quaisquer dessas variações podem fazer com
que os dados cheguem muito atrasados para a reprodução, ocasionando uma perda da
continuidade, conforme é ilustrado na gura 2.3 [Lee, 2005].
Figura 2.3: Variações no sistema podem interromper a reprodução da mídia.
Como a mídia contínua geralmente gera uma grande quantidade de dados para
armazenamento e transferência, ao projetarmos um sistema de
streaming é preciso
CAPÍTULO 2.
STREAMING
7
conseguir eciência nos seus vários subsistemas para determinar a eciência do serviço
como um todo. Atualmente, apesar dos avanços tecnológicos, o custo de servir mídia de
alta qualidade (como os emergentes vídeos de alta denição) é ainda bastante substancial.
Também é desejável que o sistema seja escalável - que suporte um crescimento em larga
escala no número de usuários sem queda exagerada em performance. E que sobreviva a
falhas, o que pode ser conseguido introduzindo redundância de hardware e mecanismos
de tolerância a falhas.
2.2
Qualidade de Serviço
Segundo [Marchese, 2007], do ponto de vista da rede, qualidade de serviço é a habilidade
que um elemento de rede (e.g., uma aplicação, um host ou um roteador) tem de ter alguma
garantia de que o tráfego e o serviço solicitados satisfarão suas necessidades. Dentre as
métricas de qualidade de serviço, podem-se citar
1.
taxa de perda de pacotes:
tendo em vista que a Internet é interconectada através
do protocolo IP, que não provê garantia de entrega, dados transmitidos às vezes
não chegam ao destinatário. Por exemplo, um roteador com a la de chegada
congestionada pode simplesmente descartar os pacotes que chegam. Esse quesito
está relacionado a isso.
2.
throughput (largura de banda):
reete a quantidade de dados que a rede é
capaz de entregar durante um intervalo de tempo. Uma maior largura de banda
normalmente causa melhoras em outros parâmetros de qualidade de serviço.
3.
taxas de erros de pacotes:
mede a taxa de pacotes que chegam no receptor com
inconsistências, assim denotando problemas de transmissão.
4.
jitter:
é a variação do atraso entre os pacotes. É alto quando, em uma seqüência
de pacotes enviados, o intervalo de chegada varia muito.
5.
atraso:
dimensiona o tempo que os pacotes levam desde a saída do transmissor até
a chegada no receptor.
CAPÍTULO 2.
6.
skew:
STREAMING
8
trata-se de um parâmetro exclusivo das transmissões de multimídia, que
é a disparidade das taxas de uxos diferentes que compõe o mesmo objeto a ser
reproduzido. Um exemplo é quando um vídeo com áudio está sendo transmitido e
o áudio está chegando corretamente, porém o vídeo está atrasado.
É evidente que cada tipo de aplicação possui suas restrições e é sensível a quesitos
diferentes. Conforme discutido na seção anterior, as aplicações de
streaming são sensíveis
a todas as citadas. Entretanto, pouco atraso não é muito importante para transmissões
sob demanda e é essencial para transmissões ao vivo.
Atualmente, na
Internet, no caso do protocolo IPv4, não se utilizam os mecanismos
que proveriam garantia de qualidade de serviço, por uma série de razões. Desse modo,
essas métricas podem ser medidas ou estimadas, geralmente sem haver qualquer garantia
por parte dos ISPs. A largura de banda, para usuários comuns com conexão ADSL,
por exemplo, não é garantida devido aos algoritmos empregados, havendo cobranças de
grandes taxas para se obter tal garantia.
Streaming
2.3
sobre TCP/UDP
Nesta seção, trataremos sobre o uso dos protocolos de
de
Internet existentes para aplicações
streaming. A camada de transporte utilizada na Internet suporta o TCP e o UDP,
principalmente.
2.3.1
TCP
Como o TCP já possui controle de erro, de uxo e de congestionamento embutidos, o
desenvolvimento de uma aplicação de streaming para esse protocolo ca um tanto simples.
O TCP protege a aplicação das complexidades de gerenciar o tráfego pela
O
Internet.
streaming sobre HTTP/TCP tem muitas vantagens óbvias: o provedor de serviços
não precisará investir em caros servidores de mídia especializados; a sua operação é
simplicada, visto que o tráfego é tratado da mesma forma que o tráfego da WWW
(assim, ele passa de forma transparente por
rewalls e gateways); o amplo suporte para
HTTP aumenta a compatibilidade com as aplicações do cliente. Contudo, a desvantagem
CAPÍTULO 2.
do
STREAMING
9
streaming HTTP/TCP é a performance. Ao nível da aplicação, o servidor não está
projetado para entregar dados de maneira sensível ao tempo. Portanto, se ele estiver
sobrecarregado, pode não conseguir sustentar uma reprodução de mídia suave, estável.
No nível do transporte, as características do TCP foram desenvolvidas para aplicações
genéricas.
Não há suporte para aplicações com sensibilidade de tempo e de largura de banda,
como é o caso do streaming de mídia. Além do mais, o mecanismo de controle do TCP força
a entrega dos dados sem erros (incorrendo em retransmissões de pacotes) e na seqüência
exata em que foram enviados. Conseqüentemente, se o dado retransmitido chegar depois
do momento correto da reprodução, tornar-se-á inútil e será descartado pelo receptor.
Para piorar, o algoritmo de controle de congestionamento do TCP interpretará a perda
de pacote como um indício de congestionamento na rede e então diminuirá sua taxa de
transmissão como meio de reduzir a janela de congestionamento. Essa diminuição afetará
o
streaming de mídia, atrasando a transmissão dos dados, podendo fazer com que eles
cheguem após o momento em que são necessários para a exibição.
2.3.2
UDP
O UDP, por outro lado, não sofre dos problemas do TCP. É um protocolo mais simples,
que transfere datagramas sem controle de uxo, de congestionamento ou de erro. Por isso,
o UDP não introduz atraso adicional como o TCP. Dessa forma, o UDP se torna adequado
para transmissão de dados de mídia sensível ao tempo. Entretanto, no streaming de mídia,
às vezes é necessário fazer um controle de uxo para reagir ao congestionamento da rede
e às perdas de pacotes. A questão é que, quando estão sendo utilizadas essas funções, os
requerimentos de tempo e largura de banda da mídia devem ser levados em conta. Isso
pode ser feito construindo-se uma outra camada com um protocolo de
streaming acima
do UDP, onde o protocolo de streaming cuida das questões especícas e o UDP só é usado
para entregar mensagens de controle e os dados.
CAPÍTULO 2.
2.4
STREAMING
10
Protocolos Especializados
Ao longo dos anos, inúmeros protocolos de
streaming foram desenvolvidos tanto para
companhias comerciais quanto para a comunidade da
Internet. Exemplos de alguns
protocolos proprietários desenvolvidos são o Microsoft Media Streaming (MMS) e o
RealNetworks Data Transport (RDT). O MMS usa o TCP/IP para troca de mensagens
de controle e pode enviar dados de mídia sobre UDP ou TCP.
A comunidade da
Internet desenvolveu protocolos para streaming de forma aberta.
Fazem parte desses protocolos o RTSP e o RTP, sobre os quais as subseções seguintes
discorrem.
2.4.1
RTSP
O RTSP é um protocolo da camada de aplicação desenvolvido para controlar a transmissão
de dados de mídia (por exemplo,
play, pause e seek) com informação de tempo embutida,
bem como áudio e vídeo. Como é independente do protocolo da camada inferior, o
RTSP pode ser transportado sobre TCP, UDP ou outros protocolos de transporte. A
sintaxe do RTSP tem muita semelhança com HTTP/1.1, simplicando a implementação
e organização; todavia, difere do HTTP em muitos aspectos importantes.
Diferentemente do HTTP, o RTSP é um protocolo ciente do estado, requerendo ao
host a manutenção da informação do estado da sessão de
streaming através de múltiplas
solicitações RTSP. Outra diferença é que ambos servidor RTSP e cliente podem emitir
requisições RTSP. Por último, os dados de mídia são entregues fora da banda, isto é,
usando um protocolo separado, como o RTP.
Em uma aplicação típica de
streaming, o cliente primeiro obterá um arquivo de
apresentação de descrição (por exemplo, através da web usando HTTP) - ver a gura
2.4. Esse arquivo descreve uma ou mais apresentações, cada uma composta de um ou
mais uxos de mídia sincronizados. O arquivo de apresentação de descrição também
contém propriedades dos uxos de mídia, como formato de codicação, para possibilitar
que o cliente selecione e prepare a reprodução da mídia. Cada uxo de mídia controlável
é identicado por um URL RTSP separado, que é similar ao URL HTTP que identica
o servidor que está hospedando o uxo de mídia e o caminho lógico identicando o uxo
CAPÍTULO 2.
STREAMING
11
de mídia.
Figura 2.4: Diagrama de tempo em uma transmissão RTSP.
2.4.2
RTP
O RTP foi projetado para transportar dados em aplicações de tempo real como áudio
e videoconferências.
O protocolo foi projetado para ser independente do protocolo
da camada inferior, o qual basicamente transporta os pacotes RTP. Na
Internet, os
pacotes RTP são freqüentemente transportados sobre datagramas UDP, que provêem
multiplexação de uxos RTP no mesmo host (usando diferentes números de portas UDP
para diferentes uxos). O RTP também suporta transporte de dados sobre redes
e
unicast
multicast. Um protocolo de controle - RTP Control Protocol (RTCP) - é denido
como parte do padrão para prover funções de controle como sincronização, relatório de
estatísticas de recepção, monitoramento de participantes, entre outros.
Vale notar que RTP/RTCP sozinhos não provêem controle de qualidade de
serviço/garantia ou realizam alocação de recursos de rede. Os protocolos foram projetados
para dar o arcabouço necessário, como os campos de cabeçalho (números seqüenciais,
CAPÍTULO 2.
STREAMING
identicação de
payload, etc.) no RTCP, para os desenvolvedores implementarem seus
12
próprios mecanismos de qualidade de serviço, que provavelmente são especícos da rede
e da aplicação em questão. Comumente os protocolos RTP/RTCP são extendidos e
integrados às aplicações ao invés de existirem como protocolos de transporte de propósito
geral como o UDP e o TCP.
Capítulo 3
Multicast na Camada de Aplicação
A maioria das redes de computadores, visando a diminuição da complexidade de projeto,
é estruturada de modo a possuir várias camadas ou níveis [Tanenbaum, 2003] com funções
bem denidas. O modelo de referência que indica a hierarquia de protocolos da Internet é
o TCP/IP (vide gura 3.1). As funções da camada Internet ou inter-redes, implementadas
através dos protocolos IP, Internet Group Management Protocol (IGMP) e Internet
Control Message Protocol (ICMP), são endereçamento, roteamento, controle de envio
e recepção. Contudo, as transmissões do tipo um-para-muitos ou
camada inter-redes não é sucientemente habilitada na
multicast através da
Internet devido a vários motivos
[Diot et al., 2000]. Assim, muitas pesquisas estão voltadas para a implementação dessa
funcionalidade na camada de aplicação, chamando-se essa alternativa de
multicast na
camada de aplicação - ALM. Em [Lao et al., 2005] encontra-se uma discussão sobre em
que camada a função de
multicast deve ser implementada.
Figura 3.1: Modelo de Referência TCP/IP.
Há uma série de vantagens em realizar esse serviço nos
13
hosts nais ao invés de
CAPÍTULO 3.
nos roteadores.
MULTICAST NA CAMADA DE APLICAÇÃO
14
Entre elas estão a utilização da capacidade de processamento e de
armazenamento muito maiores.
Outro fator signicativo é que, de acordo com os
argumentos de sistemas m-a-m [Saltzer et al., 1984], funcionalidades mais complexas
devem ser implementadas em camadas superiores.
Isso se justica porque são mais
difíceis de serem feitas em camadas mais baixas, e serviços complexos implementados
em camadas inferiores e usados por poucas aplicações trazem queda de desempenho, até
naquelas que não usam o serviço. Muitas são as propostas para esse tipo de protocolo
[Francis, 2000], [Pendarakis et al., 2001], [Zhang et al., 2002], [Banerjee et al., 2002],
[Castro et al., 2002b], [Zhuang et al., 2001], [Ratnasamy et al., 2001] e [Chu et al., 2000].
3.1
Alguns Protocolos de ALM
As propostas de ALM até hoje implementadas caracterizam-se por organizar os membros
dos grupos em duas topologias: topologia de controle e topologia de dados. A topologia de
controle trata de reparar as partições de grupo que acontecem de modo "ingrato"(quando
um nó sai de um grupo sem informar através de mensagens de controle).
Já a
topologia de dados indica o caminho e todas as questões acerca de como um pacote
sai do transmissor e chega a todos os componentes do grupo. Existem vários trabalhos
no sentido de comparar os protocolos que implementam ALM [Li and Shin, 2002],
[Banerjee and Bhattacharjee, 2002], [El-Sayed, 2004]. A classicação mais encontrada
chama de árvore-primeiro as propostas que denem a topologia de dados antes da
topologia de controle e malha-primeiro as que fazem o inverso. Ainda existem muitas
abordagens alternativas às anteriores, chamadas implícitas. Além disso, na grande maioria
dos protocolos ALM existe a gura chamada Rendezvous Point (RP) (que pode ser
traduzido como "ponto de encontro"), cuja função normalmente é coordenar o mecanismo
de entrada de novos nós no sistema.
As árvores de distribuição utilizadas em algoritmos de multicast podem ser classicadas
como
•
árvores compartilhadas:
são aquelas em que qualquer nó pode enviar mensagens
através com o objetivo de alcançar os outros nós.
•
árvores de fonte especíca:
a árvore é formulada de modo que a raiz sempre
CAPÍTULO 3.
MULTICAST NA CAMADA DE APLICAÇÃO
15
seja a mesma, ou seja, os dados sempre partem de um dado nó e somente dele.
Vamos considerar o seguinte exemplo, um grupo
multicast com os nós X , Y e Z como
receptores, sendo X e Z transmissores também. O painel 1 da gura 3.2 mostra como seria
uma árvore compartilhada pelos membros do grupo. Já o painel 2, apresenta como seriam
as duas árvores de fonte especíca para as transmissões tendo X e Z como transmissores.
Figura 3.2: Tipos de árvores de distribuição.
Nas próximas subseções são expostos alguns exemplos com uma breve descrição de seu
funcionamento. E, no m desta seção, há uma breve comparação entre eles.
3.1.1
YOID
O protocolo Yoid [Francis, 2000] cria, em primeiro lugar, a árvore de distribuição dos
dados, exercendo controle direto sobre a escolha de membros vizinhos na árvore e grau
de saída dos nós. Esse controle contrasta com a abordagem chamada de malha-primeiro,
que possui um controle indireto sobre esses aspectos.
Nos esquemas em que a topologia de dados é construída primeiro, é criada uma árvore
compartilhada, e cada nó entrante deve procurar o seu pai dentre os nós já pertencentes
à árvore. Cada nó da árvore tem um grau de saída limite que restringe o número de lhos
que ele pode ter.
No processo de entrada, o futuro membro do grupo consulta o RP e recebe em troca
uma lista de participantes do grupo. Um componente do grupo é um possível pai caso ele
1. seja escolhido como pai por algum critério relevante, não cause a formação de um
laço na árvore (isso se refere ao caso de um nó que está entrando novamente na
árvore e já possui lhos);
CAPÍTULO 3.
MULTICAST NA CAMADA DE APLICAÇÃO
16
2. possa ter mais um lho sem exceder o seu limite de grau de saída.
Se nenhum possível pai é obtido na lista, em [Francis, 2000] são mostradas algumas
propostas para achar outro pai em potencial. No caso de serem encontrados mais de um
pai em potencial, o melhor, segundo alguma métrica, será o escolhido.
O Yoid é um conjunto de protocolos para distribuição de conteúdo muito geral. Por
ser uma proposta tão abrangente e tentando resolver tantos aspectos, não há necessidade
descrevê-lo por completo. Alguns autores [El-Sayed, 2004] chegam a armar que seu
interesse é histórico.
3.1.2
HMTP
Em [Zhang et al., 2002], é proposto o HMTP, um protocolo do tipo árvore-primeiro que
se assemelha em alguns aspectos ao Yoid. A entrada de um nó na árvore compartilhada
segue a seguinte sequência de passos:
1. Descobrir a raiz da árvore consultando o RP;
2. Começando pela raiz, percorrer cada nível da árvore procurando um possível pai que
esteja próximo de si. Caso encontre um nó próximo mas que não seja um possível
pai, passa ao próximo nível e continua a procurar.
Esse processo faz com que a árvore de distribuição tenda a car balanceada por altura.
Além disso, o atraso médio em relação à saída dos pacotes da raiz ca propenso a ser
menor.
A especicação indica que os participantes do grupo mantêm informações sobre os
membros no caminho deles até a raiz. Dessa forma, periodicamente eles tentam achar um
pai melhor na árvore, reiniciando o processo de entrada a partir de um nó aleatoriamente
escolhido. O problema da formação de laços é tratado com um algoritmo distribuído de
detecção de laços ao invés de evitá-los.
Esse protocolo não cria explicitamente uma malha.
Entretanto, de tempos em
tempos, os componentes apanham informações sobre outros integrantes do grupo. Esse
conhecimento diminui o problema do único ponto de falha causado pela necessidade do
RP e ajuda a recuperação devido a partições.
CAPÍTULO 3.
3.1.3
MULTICAST NA CAMADA DE APLICAÇÃO
17
ALMI
Um protocolo totalmente centralizado proposto é o ALMI [Pendarakis et al., 2001]. Nesse
protocolo, um programa executado em um lugar acessível por todos os membros grupo
controla a sessão de
multicast. Pode-se armar que o sistema é composto de um
controlador de sessão e de múltiplos membros da sessão.
Os participantes das seções são organizados em uma árvore compartilhada para a
troca de dados, enquanto mensagens de controle são trocadas entre cada membro e o
controlador da sessão. As árvores de distribuição são construídas pelo controlador, sendo
elas formadas com base em medições feitas por alguns membros e enviadas ao controlador,
como Round-Trip Time (RTT), por exemplo.
3.1.4
NICE
O protocolo NICE [Banerjee et al., 2002] foi desenvolvido visando aplicações onde as
transmissões de dados sejam com baixo consumo de largura de banda e para um grande
conjunto de destinatários. A topologia de controle é constituída de maneria a tomar uma
forma hierárquica, o que dene implicitamente o caminho de dados para um grupo de
maneira escalável. A hierarquia é essencial para a escalabilidade, visto que os membros
da camada mais baixa (a maioria dos membros) mantêm informações sobre o estado de
um número constante de nós, e os das superiores, de O(logN ) membros. As informações
sobre os nós vizinhos são detalhadas, enquanto as que dizem respeito aos outros nós do
grupo são limitadas.
A criação da hierarquia é feita atribuindo membros a diferentes camadas, conforme
ilustrado na gura 3.3 [Banerjee et al., 2002]. Os nós de cada camada são divididos em
clusters. Cada cluster tem um líder. Todos os nós pertencem à camada mais baixa, e
os líderes pertencem também à camada imediatamente superior àquela onde ele é líder
de um
cluster. Essas denições fazem com que as topologias de dados em um cluster
sejam sempre em estrela, criando um gargalo em uma aplicação que requer alta largura
de banda.
A localização dos nós dentro dos grupos da hierarquia é feita considerando como
métrica de distância o atraso entre os
hosts. Assim, os nós mais próximos se encontram
MULTICAST NA CAMADA DE APLICAÇÃO
CAPÍTULO 3.
18
Figura 3.3: Modelo de Camadas do NICE.
na mesma parte da hierarquia, fazendo com que as árvores de distribuição tenham um
menor atraso médio.
3.1.5
Bayeux
O esquema de
multicast na camada de aplicação chamado Bayeux [Zhuang et al., 2001]
é estruturado em cima de um sistema de busca para redes P2P chamado Tapestry. O
roteamento de mensagens é todo feito pelo sistema Tapestry. Portanto, são utilizados os
seus algoritmos.
Cada nó possui um identicador e consigo uma tabela para mapeamento de mensagens
baseada nos identicadores dos nós. Mesmo sem entrar em detalhes sobre a transmissão
de uma mensagem, ca claro que uma mensagem destinada a um nó pode passar por uma
série de nós que não estão interessados em recebê-la. Assim, para atividades que utilizam
alta largura de banda, como
3.1.6
streaming, esse sistema é inadequado.
CAN-Multicast
Conforme o mostrado em [Ratnasamy et al., 2000], uma rede endereçável por conteúdo
(CAN) é uma rede
overlay que implementa uma tabela de hash distribuída sobre uma
rede geogracamente distribuída, como a Internet. O CAN baseia-se na construção de um
espaço n-dimensional, onde cada
host toma conta de uma porção de mesma dimensão.
Para exemplicar, consideremos um exemplo bidimensional no painel 0 da gura 3.4,
retirada de [Li and Shin, 2002].
Em [Ratnasamy et al., 2001] é formulada uma proposta de ALM usando a estrutura
do CAN. A topologia de dados é formada intuitivamente de acordo com a localização
CAPÍTULO 3.
MULTICAST NA CAMADA DE APLICAÇÃO
19
Figura 3.4: Estrutura de um CAN.
dos nós no sistema de coordenadas, conforme é exposto no painel 1 da gura 3.4, ou seja,
cada nó é responsável por distribuir mensagens para os seus vizinhos. As duplicações de
pacotes são evitadas com uma
cache de pacotes já enviados.
O procedimento de entrada é ilustrado nos painéis 2 e 3 da gura 3.4. O nó Z (nó
que deseja entrar no CAN) consulta o RP para achar pelo menos um nó que já é membro
(nó Y). O nó Z procura um ponto aleatório no espaço de coordenadas através do nó X.
O dono desse espaço (nó Y) divide-o em dois. Uma das metades passa a pertencer ao nó
Y, e a outra, ao nó Z.
3.1.7
Narada
Sendo um dos pioneiros na tarefa de realizar multicast nos hosts nais, o protocolo Narada
[Chu et al., 2000] é um protocolo do tipo malha-primeiro. Quando um nó quer se tornar
um membro da malha, ele obtém uma lista dos nós que já fazem parte da rede com o RP
- que mantém informações sobre o estado de todos os membros que entraram no grupo.
Então, o nó seleciona aleatoriamente um subconjunto desses nós e tenta se tornar vizinho
deles, sendo bem sucedido quando pelo menos um o aceita como vizinho.
Depois de começar a fazer parte da malha, o membros passam a trocar mensagens
de manutenção e atualização. Quando um membro entra ou sai do grupo, a informação
é propagada ao longo da malha. Assim, cada membro possui informações sobre todos
aqueles que compõem o grupo. O número de mensagens de controle é dado por uma
função que pertence a O(N 2 ), onde N é o número de participantes do grupo. Isso faz com
que o protocolo Narada seja pouco eciente para grupos grandes.
Para a construção da árvore de abrangência ao longo do grafo, os
hosts executam um
CAPÍTULO 3.
MULTICAST NA CAMADA DE APLICAÇÃO
protocolo de roteamento achando os caminhos
20
unicast. Assim, o caminho de entrega de
dados e sua qualidade dependem da qualidade das arestas (links) da malha.
3.2
Comparação entre os Protocolos Apresentados
A respeito dos protocolos brevemente discutidos, foi formulada a tabela 3.2. A tabela
mostra alguns quesitos relevantes no que se refere a protocolos de
multicast na camada
de aplicação, e principalmente ao tratado neste trabalho.
Protocolo
Tipo
Árvore
Comp. do Grau de Saída
Caminho
Máximo
ALMI
centralizado
compartilhada
ilimitado
limitado
NARADA
malha-primeiro
fonte especíca
ilimitado
ilimitado
Bayeux
malha-primeiro
fonte especíca
O(logN )
O(logN )
CAN-Multicast
malha-primeiro
fonte especíca
O(dN1/d )
constante
HMTP/Yoid
árvore-primeiro
compartilhada
ilimitado
O(maxgrau)
NICE
árvore-primeiro
fonte especíca
O(logN )
O(logN )
Tabela 3.1: Comparação entre protocolos de ALM.
Alguns dos protocolos acima citados não satisfazem os requisitos para realizar tarefas
de grande consumo de largura de banda. Porém, isso é evidente, tendo em vista que
muitos deles não foram projetados visando tal atividade. De acordo com as características
de cada um deles, pode-se decidir se ele é apropriado ou não para determinada tarefa.
Entretando, apesar do protocolo HMTP ser de árvore compartilhada, o que não é um
fator desejado em um sistema de
streaming com uma fonte especíca, fazendo da raiz a
única fonte de dados, ele se mostra mais eciente que os demais citados em uma série de
características [Proença, 2006]. O controle do grau de saída dos nós e do mecanismo de
entrada na árvore de distribuição é fator indispensável para o tipo de aplicação tratado
nesse trabalho.
Capítulo 4
O Protótipo
Levando em consideração as pesquisas realizadas, propõe-se uma solução para o problema
de realizar
streaming sobre uma rede overlay usando um protocolo ALM. Além de criar
uma solução que combina uma série de técnicas, foi projetado um protótipo que traz à
tona questões de implementação de um sistema distribuído e demonstra satisfatoriamente
a funcionalidade deste tipo de aplicação.
O presente capítulo discorre a respeito da proposta e de sua materialização através da
elaboração de um sistema distribuído. Também são discutidos alguns trabalhos de cunho
semelhante ao abordado neste documento.
4.1
Descrição da Proposta
As idéias principais da proposta são a solução de forma descentralizada de algumas
questões e a utilização de tecnologias P2P presentes em redes de compartilhamento de
arquivos. Os
hosts do sistema utilizam uma rede P2P para buscar uxos que estejam
disponíveis e participantes de alguma árvore de distribuição, de forma semelhante ao
feito em [Jiang et al., 2003]. O sistema serve somente para a busca e registro dos uxos
e participantes, respondendo assim pelas funções normalmente desempenhadas pelo RP,
mas indo além ao publicar os uxos e servir como mecanismo de busca por estes.
Em [Proença, 2006], é mostrado através de experimentos que o protocolo HMTP tem
muitos aspectos positivos. Entretanto, o processo de entrada com busca de um pai próximo
por nível é extremamente lento para grupos muito grandes. A construção da topologia
21
CAPÍTULO 4.
22
O PROTÓTIPO
de dados proposta aqui é mais escalável, pois as medições de atraso são feitas para um
número constante de hosts, só que não alcança necessariamente uma árvore tão boa como
a referente a topologia de dados do HMTP.
4.1.1
Rede Sobreposta
O sistema proposto é construído sobre uma rede sobreposta que possua pelo menos estas
funcionalidades: inserção e remoção de registros (uxos publicados ou usuários que estão
participando recebendo alguma transmissão) e busca de ambos tipos de registro. Toda a
formulação é feita independente de como essa camada de
software é implementada.
Os registros são dos formatos expostos na gura 4.1. O painel 1 da gura mostra
os registros referentes aos uxos, sendo ele composto por uma cadeia de caracteres
identicando o uxo, um identicador global e um registro de usuário referente à raiz
da árvore. Aquele tipo de registro referente a usuário que não é raiz, mostrado no painel
2, tem um campo com o identicador do uxo ao qual ele pertence, o nível da árvore ao
qual ele pertence, o número de uxos que ele ainda está disposto a prover, e outro com
seu endereço IP e uma porta para ser usada na topologia de controle.
Figura 4.1: Tipos de registros empregados no sistema.
4.1.2
Topologia de Controle
Esta parte do programa cuida das questões de manutenção e recuperação da estrutura
que torna o processo de streaming possível. Dentre as funções desempenhadas aqui, podese mencionar a recuperação da árvore quando um nó sai do sistema, detecção de falhas
CAPÍTULO 4.
23
O PROTÓTIPO
de participantes do sistema e descobrimento de laços na árvore quando um
host entra
novamente no sistema.
Descobrimento de Falhas
Os nós considerados vizinhos são o pai e os lhos de cada nó, ou seja, cada nó tem
informações somente sobre esses nós. Para detectar falhas, os vizinhos trocam mensagens
conhecidas como "batidas de coração", que servem somente para vericar o estado dos
vizinhos. Eventualmente, se algum nó não estiver respondendo, seu registro é removido
do banco de registros, para manter a consistência. Esse mecanismo poderia não ser
necessário, no caso das transmissões serem orientadas a conexões, pois assim as falhas
provavelmente seriam detectadas no nível de transporte.
Porém, podem existir casos em que falhas não sejam descobertas assim. Uma grande
parte da árvore pode falhar ou sair de maneira ingrata (sem executar os procedimentos
necessários) simultaneamente, por exemplo.
Para esses casos, quando um nó tenta
conectar-se a ele e não consegue, no processo de entrada, ele pode informar ao sistema
que cuida dos registros a falha do membro que estava inacessível.
Detecção de Laços
Escolheu-se não realizar a prevenção de formação de laços. Assim, periodicamente e
sempre que algum nó entra no sistema pela segunda vez possuindo algum lho, é efetuada
a vericação dos caminhos da árvore.
A vericação é feita enviando-se uma mensagem com um número aleatório ao longo da
árvore. Quando essa mensagem passa pelos nós eles a armazenam em uma tabela por um
certo tempo e sempre antes de armazenar eles vericam se já não a tinham recebido. No
caso de possuírem esse número na tabela, eles param de propagar a mensagem e repetem
o processo de entrada. Nas vericações periódicas, essa mensagem parte da raiz da árvore
e, quando é feita a vericação por reinserção na árvore, parte do nó entrante.
CAPÍTULO 4.
4.1.3
24
O PROTÓTIPO
Topologia de Dados
O processo de entrada na árvore de distribuição é feito após pesquisas na rede sobreposta.
Para melhor compreensão, o algoritmo de entrada é exibido a seguir como uma seqüência
de passos.
1. O nó entrante realiza uma consulta para descobrir o identicador global do uxo ao
qual ele pretende participar;
2. A partir deste identicador, ele obtém uma lista dos k membros mais altos da árvore
e os ordena de acordo com a sua altura na árvore;
3. Seguindo essa ordem, são feitas medições de atraso m a m;
4. Caso seja vericado um valor de atraso em relação a algum
host abaixo de uma
constante determinada previamente, esse é escolhido como pai;
5. Se dentre os k nós da lista obtida nenhum tiver um atraso menor do que o valor
estabelecido, o mais próximo, segundo essa métrica, é selecionado como pai;
6. No caso da tentativa de entrada falhar (por uma inconsistência nos registros, por
exemplo) , o processo se repete.
Vamos considerar o exemplo a seguir (gura 4.2), onde o nó Z quer entrar na árvore
(painel 1). Primeiro ele resgata uma lista com os quatro nós mais altos da árvore com
uxos disponíveis (C , D, E e X ), mostrado no painel 2, e realiza medições de atraso com
eles (painel 3). O nó X é o escolhido por ter um atraso em relação a Z menor do que os
outros. Finalmente, o nó Z tenta se tornar lho do nó X e obtém sucesso (painel 4).
Diferente do HMTP, o algoritmo de entrada não é executado periodicamente para
melhorar as qualidades da árvore. Em uma transmissão de uxo, isso poderia acarretar
em perda na qualidade da reprodução. Desse modo, esse novo chamamento da função de
entrada só é feito no caso de falha ou saída do nó pai, ou de algum nó no caminho até a
raiz da árvore de distribuição.
CAPÍTULO 4.
25
O PROTÓTIPO
Figura 4.2: Exemplo do processo de entrada.
4.2
Implementação do Sistema
A implementação da proposta para o cliente pode ser apresentada por um diagrama em
camadas, ilustrado na gura 4.3. Na gura, o nome "Mecanismo de Busca"se refere à
escolha feita para juntar as informações a respeito dos nós e recuperá-las.
Para a camada mais inferior, que dá suporte às buscas descentralizadas, existem
muitos arcabouços disponibilizados para realizar essas funções sem se preocupar com
os detalhes de sua programação.
Dentre vários, podemos citar como relevantes
[Francesquini and Reverbel, 2007]:
•
JXTA [Gong, 2002]:
O projeto JXTA é uma estrutura criada para suportar
aplicações P2P usando Java. Compõe-se de um conjunto de protocolos abertos que
habilitam dispositivos conectados para se comunicar e colaborar. Promete realizar
buscas de
hosts e recursos em redes diferentes e prover comunicação segura entre
eles.
•
FreePastry [Castro et al., 2002a]:
trata-se de uma implementação livre do
sistema Pastry [Rowstron and Druschel, 2001] com a intenção de disponibilizar
CAPÍTULO 4.
26
O PROTÓTIPO
Figura 4.3: Camadas do sistema implementado.
aplicações na
Internet. O Pastry foi desenvolvido para trazer um esquema de busca
distribuída de objetos escalável para sistemas P2P.
•
Bamboo [Bamboo, 2008]: é uma estrutura para construção de aplicações P2P
que utiliza tabelas de hash distribuídas para tratar inserção, remoção e recuperação
de pares chave-valor. As tabelas de hash desse tipo mapeiam colaborativamente
pares chave-valor.
A tabela 4.2, retirada de [Francesquini and Reverbel, 2007], visa mostrar os recursos
que essas estruturas de programação oferecem.
JXTA FreePastry Bamboo
Troca de Mensagens
•
•
•
Busca Exata
•
•
•
Busca Aproximada
•
Comunicação em Grupo
•
•
•
Armazenamento Distribuído
•
•
•
Autenticação de Usuários
•
•
Tabela 4.1: Comparação entre arcabouços para programação P2P.
Apesar da utilização desses sistemas ser viável, resolveu-se implementar o arcabouço
por questões de aprendizado. Fez-se um mecanismo de indexação central no estilo daquele
CAPÍTULO 4.
O PROTÓTIPO
27
envolvido no pioneiro Napster [Yang and Garcia-Molina, 2001].
Os algoritmos que concebem a topologia de controle, assim como o mecanismo de
busca, foram desenvolvidos utilizando programação de Sockets em Java. Para todo o
desenvolvimento que lidou com mídia, foi utilizado um Application Program Interface
(API) chamado Java Media Framework (JMF). Esse API foi desenvolvido pela Sun
MicroSystems em conjunto com a IBM para conceder muitas funções relativas a áudio
e vídeo [Microsystems, 2008].
Entre essas funções estão codicação, decodicação,
transcodicação, multiplexação, demultiplexação, captação dos dados de dispositivos e
serviços de streaming. A topologia de dados foi desenvolvida a partir das funções do JMF
que implementam o protocolo RTP.
As simulações foram feitas somente com arquivos de áudio sendo transmitidos.
No entanto, o sistema foi desenvolvido de forma que, com poucas modicações, as
transmissões possam envolver mais de um uxo, como uma transmissão de um vídeo
que utiliza normalmente um canal de vídeo e um de áudio. Essa mudança, assim como
a mudança do sistema de busca, é facilmente realizável devido à construção em camadas
e utilizando uma abordagem orientada a objetos. Além disso, utilizar Java tornou o
sistema multi-plataforma, bastando a instalação do Java Runtime Environment (JRE) e
JMF para o sistema operacional desejado.
4.3
Funcionamento do Protótipo
Visando demonstrar as funcionalidades implementadas, nesta seção é exibida a interface
gráca (ilustrada na gura 4.4) e são explicadas as funções desempenhadas pelos
componentes grácos. A seguir, são descritas as funções dos botões.
•
Buscar:
Faz uma busca no sistema P2P e exibe o resultado na tabela para que o
usuário possa selecioná-lo a m de participar da transmissão.
•
Participar:
Esse botão faz com que o usuário execute o procedimento de entrada
na árvore de distribuição do uxo selecionado.
•
Deixar Grupo:
Realiza o procedimento de saída do grupo. Fazendo com que seus
lhos tenham de chamar novamente o procedimento de entrada.
CAPÍTULO 4.
•
O PROTÓTIPO
Iniciar Transmissão:
28
Com este botão é possível cadastrar um uxo no sistema.
Esse uxo pode ser tanto um arquivo de áudio com uma codicação suportada pelo
JMF instalado na máquina, quanto a captação de um microfone.
Figura 4.4: Tela principal do protótipo.
4.4
Experimentos
Com a intenção de testar e analisar o funcionamento do protótipo, foram feitos alguns
experimentos. Para executar os experimentos, utilizou-se dois ambientes: um envolvendo
cinco computadores em uma Local Area Network (LAN) e outro com três computadores
conectados através da
Internet, cada um com capacidades de acesso diferentes em
relação à largura de banda.
Nos dois ambientes, o protótipo funcionou sem trazer
perdas na qualidade do áudio recebido, usando-se diferentes congurações nas árvores
de distribuição.
Os algoritmos de controle foram testados separadamente. Assim, puderam ser feitos
testes com várias instâncias de um programa no mesmo computador. Isso pode ser feito
pois a topologia de controle não depende muito das questões relacionadas ao atraso e
à largura de banda, que devem ser levados em consideração nos testes relacionados à
topologia de dados. Os resultados foram satisfatórios quanto a recuperação de falhas e
na detecção de laços.
CAPÍTULO 4.
4.5
29
O PROTÓTIPO
Trabalhos Completos
Existe uma série de trabalhos relacionados a
streaming sobre redes P2P. Dentre as várias
características de cada um, pode-se fazer a seguinte classicação simples em três grupos
[Pianese et al., 2006].
•
Estruturados:
Nesses sistemas, os nós são organizados seguindo a forma de uma
árvore hierárquica para formar a rede sobreposta. Cada nó recebe todos os dados
do uxo de seu pai e transmite para seus lhos.
As diferenças desse tipo de
sistema está no jeito em que se organizam e nos algoritmos usados para criar e
reparar a estrutura de funcionamento. Pode-se citar como deste grupo Spreadit
[Deshpande et al., 2002], Peercast [Deshpande et al., 2001], ESM [Chu et al., 2003]
e ZigZag [Tran et al., 2003].
•
Não estruturados:
Aqui as associações entre os nós são direcionadas pelos dados
que eles receberam previamente. O uxo é dividido em partes que são dispostas
aos nós. Os nós requisitam independentemente as partes que eles precisam para
completar o uxo. Um sistema que adota esse mecanismo de trocas de dados em
uma malha dinâmica é o CoolStreaming [Zhang et al., 2005].
•
Outros:
Tais sistemas não podem ser classicados como nenhum dos grupos
anteriores. Um exemplo é o SplitStream [Castro et al., 2003] que combina técnicas
de codicação com múltiplas redes sobrepostas, dividindo o uxo e distribuindo-o
através de duas árvores disjuntas.
Capítulo 5
Conclusão
A facilidade na publicação de uxos de mídia na
Internet é um problema que ainda está
para ser resolvido. Esta proposta visa utilizar o potencial dos
hosts para tornar possível
esse serviço. O problema abordado aqui é um tópico de extensiva pesquisa, principalmente
por causa do sucesso dos sistemas de compartilhamento de arquivos, que hoje em dia
compreendem uma boa parcela de todo o tráfego da
Internet.
Apesar de existirem alguns programas que se propõem a disponibilizar a distribuição
de uxos através de sistemas P2P, ainda não existem propostas globalmente aceitas
nem largamente utilizadas. Já as transmissões de canais de rádio e televisão através
de servidores dedicados com múltiplos canais
unicast são uma realidade. Grandes
empresas pagam quantias consideráveis para garantir esses serviços, o que com
bem menos investimento em um sistema distribuído traria uma grande economia
[Hefeeda et al., 2002].
Alguns ISPs provêem
multicast IP, porém ele ca limitado a
algumas áreas onde o serviço é habilitado nos roteadores.
Ao longo do texto foram mostradas as questões de projeto envolvidas a respeito do
problema de fornecer a funcionalidade de multicast visando realizar
streaming sobre redes
overlay. Este trabalho, assim como alguns outros, demonstrou que essa tarefa, apesar de
ser complicada, pode ser resolvida de várias maneiras, inclusive como aqui apresentado.
A proposta atinge o objetivo de descentralização, por eliminar a gura do RP, e é de fácil
disponibilização por poder funcionar no topo de muitos sistemas de compartilhamento
de arquivos, estendendo suas funcionalidades. Desse modo, aplicações de distribuição de
vídeo e áudio síncrona de maneira escalável e de livre utilização podem ser largamente
30
CAPÍTULO 5.
CONCLUSÃO
disponibilizadas na
Internet.
31
Bibliograa
[Abad et al., 2004] Abad, C., Yurcik, W., and Campbell, R. (2004).
A survey and
comparison of end-system overlay multicast solutions suitable for network centric
warfare.
[Bamboo, 2008] Bamboo (2008). The bamboo distributed hash table.
[Banerjee and Bhattacharjee, 2002] Banerjee, S. and Bhattacharjee, B. (2002).
A
comparative study of application layer multicast protocols.
[Banerjee et al., 2002] Banerjee, S., Bhattacharjee, B., and Kommareddy, C. (2002).
Scalable application layer multicast.
[Castro et al., 2002a] Castro, M., Druschel, P., Hu, Y. C., and Rowstron, A. (2002a).
Exploiting network proximity in peer-to-peer overlay networks. Technical Report MSRRT-2002-82, Microsoft Research.
[Castro et al., 2003] Castro, M., Druschel, P., Kermarrec, A., Nandi, A., Rowstron,
A., and Singh, A. (2003).
Splitstream: High-bandwidth multicast in cooperative
environments.
[Castro et al., 2002b] Castro, M., Druschel, P., Kermarrec, A., and Rowstron, A. (2002b).
SCRIBE: A large-scale and decentralized application-level multicast infrastructure.
IEEE Journal on Selected Areas in communications (JSAC), 20(8):14891499.
[Chu et al., 2003] Chu, Y., Ganjam, A., Ng, T., Rao, S., Sripanidkulchai, K., Zhan, J.,
and Zhang, H. (2003). Early experience with an internet broadcast system based on
overlay multicast.
32
33
BIBLIOGRAFIA
[Chu et al., 2000] Chu, Y.-H., Rao, S. G., and Zhang, H. (2000). A case for end system
multicast. In
Measurement and Modeling of Computer Systems, pages 112.
[Deshpande et al., 2002] Deshpande, H., Bawa, M., and Garcia-Molina, H. (2002).
Streaming live media over a peer-to-peer network.
[Deshpande et al., 2001] Deshpande, H., Bawa, M., and Molina, G. H. (2001). Streaming
live media over peers.
Technical Report 2001-31, Computer Science Department,
Stanford University.
[Diot et al., 2000] Diot, C., Levine, B. N., Lyles, B., Kassem, H., and Balensiefen, D.
(2000). Deployment issues for the IP multicast service and architecture.
IEEE Network,
14(1):7888.
[El-Sayed, 2004] El-Sayed, A. (2004). Application-level multicast transmission techniques
over the internet.
[Francesquini and Reverbel, 2007] Francesquini, E. and Reverbel, F. (2007). Hermes:
Um
Arcabouço para Programação de Aplicações P2P.
[Francis, 2000] Francis, P. (2000). Yoid: Extending the internet multicast architecture.
[Gong, 2002] Gong, L. (2002). Project jxta: A technology overview.
[Hefeeda et al., 2002] Hefeeda, M., Habib, A., and Bhargava, B. (2002).
Cost-prot
analysis of a peer-to-peer media streaming architecture.
[J. Youn and Sun, 2000] J. Youn, J. X. and Sun, M.-T. (2000). Fast video transcoding
architectures for networked multimedia applications.
Proc. IEEE Int. Symp. Circuits
and Systems (ISCAS'00).
[Jiang et al., 2003] Jiang, X., Dong, Y., Xu, D., and Bhargava, B. (2003). Gnustream: A
p2p media streaming system prototype.
[Lao et al., 2005] Lao, L., Cui, J.-H., Gerla, M., and Maggiorini, D. (2005). A comparative
study of multicast protocols: Top, bottom, or in the middle?
34
BIBLIOGRAFIA
[Lee, 2005] Lee, J. Y. B. (2005).
Scalable Continuous Media Streaming Systems. John
Wiley & Sons Ltd.
[Li and Shin, 2002] Li, Z. and Shin, Y. (2002). Survey of overlay multicast technology.
[Marchese, 2007] Marchese, M. (2007).
QoS Over Heterogeneous Networks. John Wiley
& Sons Ltd.
[Microsystems, 2008] Microsystems, S. (2008).
http://java.sun.com/products/java-
media/jmf/.
[Pendarakis et al., 2001] Pendarakis, D., Shi, S., Verma, D., and Waldvogel, M. (2001).
ALMI: An application level multicast infrastructure. In Proceedings of the 3rd USENIX
Symposium on Internet Technologies and Systems (USITS), pages 4960.
[Pianese et al., 2006] Pianese, F., Keller, J., and Biersack, E. W. (2006). Pulse, a exible
p2p live streaming system. In
INFOCOM. IEEE.
[Proença, 2006] Proença, T. S. (2006). Proposta e avaliação de uma arquitetura escalável
para distribuição de tv na internet.
[Ratnasamy et al., 2000] Ratnasamy, S., Francis, P., Handley, M., Karp, R., and Shenker,
S. (2000). A scalable content addressable network. Technical Report TR-00-010,
Berkeley, CA.
[Ratnasamy et al., 2001] Ratnasamy, S., Handley, M., Karp, R., and Shenker, S. (2001).
Application-level multicast using content-addressable networks.
Lecture Notes in
Computer Science, 2233:14.
[Rowstron and Druschel, 2001] Rowstron, A. and Druschel, P. (2001). Pastry: Scalable,
decentralized object location, and routing for large-scale peer-to-peer systems.
Lecture
Notes in Computer Science, 2218:329.
[Saltzer et al., 1984] Saltzer, J. H., Reed, D. P., and Clark, D. D. (1984). End-to-end
arguments in system design.
ACM Transactions on Computer Systems, 2(4):277288.
[Tanenbaum, 2003] Tanenbaum, A. S. (2003).
Computer Networks. Prentice Hall.
35
BIBLIOGRAFIA
[Tran et al., 2003] Tran, D. A., Hua, K., and Do, T. (2003). A peer-to-peer architecture
for media streaming.
[Yang and Garcia-Molina, 2001] Yang, B. and Garcia-Molina, H. (2001).
hybrid peer-to-peer systems. In
Comparing
The VLDB Journal, pages 561570.
[Youtube, 2008] Youtube (2008). www.youtube.com.
[Zhang et al., 2002] Zhang, B., Jamin, S., and Zhang, L. (2002). Host multicast: A
framework for delivering multicast to end users.
[Zhang et al., 2005] Zhang,
Coolstreaming/donet:
X.,
Liu,
J.,
Li,
B.,
and Yum,
T.-S. P. (2005).
A data-driven overlay network for peer-to-peer live media
streaming.
[Zhuang et al., 2001] Zhuang, S. Q., Zhao, B. Y., Joseph, A. D., Katz, R. H., and
Kubiatowicz, J. D. (2001). Bayeux: An architecture for scalable and fault-tolerant
wide-area data dissemination. In
Proceedings of NOSSDAV.