ANÁLISE DE FLASH CROWD PARA TRANSMISSÕES MULTIMÍDIA … · MPEG Moving Pictures Experts Groups...
79
FERNANDO ZANK CORREA EVANGELISTA ANÁLISE DE FLASH CROWD PARA TRANSMISSÕES MULTIMÍDIA EM REDES PAR-A-PAR CANOAS, JUNHO DE 2009
Transcript of ANÁLISE DE FLASH CROWD PARA TRANSMISSÕES MULTIMÍDIA … · MPEG Moving Pictures Experts Groups...
FERNANDO ZANK CORREA EVANGELISTA
ANÁLISE DE FLASH CROWD PARA TRANSMISSÕES MULTIMÍDI A
EM REDES PAR-A-PAR
CANOAS, JUNHO DE 2009
2
FERNANDO ZANK CORREA EVANGELISTA
ANÁLISE DE FLASH CROWD PARA TRANSMISSÕES MULTIMÍDIA
EM REDES PARA-A-PAR
Trabalho de conclusão apresentado à banca examinadora do curso de Ciência da Computação do Centro Universitário La Salle - UNILASALLE, como exigência parcial para a obtenção do grau de bacharel em Ciência da Computação, sob a orientação do professor Ms. Tasso Gomes de Faria.
CANOAS, JUNHO DE 2009
3
TERMO DE APROVAÇÃO
FERNANDO ZANK CORREA EVANGELISTA
ANÁLISE DE FLASH CROWD PARA TRANSMISSÕES MULTIMÍDIA
EM REDES PAR-A-PAR
Trabalho de conclusão aprovado como requisito parcial para obtenção do grau de bacharel em Ciência da Computação do Curso de Ciência da Computação do Centro Universitário La Salle - UNILASALLE, pela seguinte banca examinadora:
Prof. Ms. Marcos Ennes Barreto
Unilasalle
Prof. Ms. Rafael Kunst
Unilasalle
Canoas, de Junho de 2009.
DEDICATÓRIA
Dedico este trabalho a minha família que me deu todo apoio necessário para
chegar até aqui, principalmente minha mãe Márcia e meu pai Mário, ao meu avô
Mário que infelizmente não pode acompanhar até o final, mas foi muito importante
durante o caminho percorrido para chegar até aqui e a minha avó Suely. Também
dedico a minha namorada Priscila que teve paciência para me aguentar nos
momentos difíceis e compreender os dias que tive que me dedicar totalmente ao
trabalho. Também dedico aos amigos e colegas que acompanharam esta jornada e
todos os demais que de alguma maneira foram importante para a conclusão deste
trabalho. Finalmente dedico este trabalho ao meu orientador Tasso Gomes de Faria
que aceitou o desafio de me orientar durante este trabalho e fez isso brilhantemente
conseguindo me mostrar caminhos viáveis para chegar até o fechamento deste
trabalho.
AGRADECIMENTOS
Agradeço a Unilasalle pela estrutura disponibilizada para realizar este
trabalho e ao quadro docente do curso de Ciência da Computação pelo
conhecimento transmitido e pela ajuda dada nos momentos necessários. Agradeço
por todo empenho, dedicação e pela ajuda incentivadora do meu orientador Tasso
Gomes de Faria. Agradeço aos meus colegas de curso que também partilharam
deste trabalho especialmente aos colegas Gian Franscesco Jaskulski e Nélson Buis
Sonntag que me incentivaram e se disponibilizaram em momentos importantes para
a realização deste trabalho. Também agradeço aos colegas Thiago Cabelleira,
Thiago Oliveira, Michel David, Rafael Garbin, Cassius Pain entre muitos outros que
também foram importantes durante este processo. Também agradeço a todos meus
amigos que acompanharam este sonho desde antes dele se iniciar até o final do
percurso.
RESUMO
Com a popularização da Internet e o aumento da velocidade da banda larga, um grande número de usuários opta por acessar a informações através de conteúdo multimídia. Sistemas de fluxo de vídeo ao vivo par-a-par são utilizados para entregar conteúdo multimídia para os usuários; estes sistemas podem ser afetados por uma série de problemas que interferem em sua transmissão ou qualidade do conteúdo, um destes problemas é flash crowds. Este trabalho apresenta uma análise de parâmetros que influenciam no flash crowd em sistemas de fluxo de vídeo ao vivo par-a-par. Palavras-Chave: redes par-a-par, live streaming e flash crowd.
ABSTRACT
With the popularization of the Internet and the broadband’s increase of speed, many users choose to access the information through multimedia content. Peer-to-peer live streaming systems are employed to delivery multimedia content to the users; these systems may be affected by a series of problems that interfere in its transmission or content’s quality, one of these problems is flash crowds. This work presents one analyses of parameters that interfere on flash crowds in live streaming peer-to-peer systems.
Keywords: peer-to-peer networks, live streaming and flash crowd.
LISTA DE ABREVIATURAS E SIGLAS
ALM Application layer multicast
AOL American on line
BSD Berkeley Software Distribution
CAN Content Addressable Network
CD Compact Disc
CDN Content Delivery Network
CNN Cable News Network
CPU Central Processing Unit
CSV Comma-separated values
DHT Distributed Hash Table
DTV Digital Television
DV Digital Video
DVD Digital Video Disk
DoS Denial of Service
HTTP Hypertext Transfer Protocol
IEEE Institute of Electrical and Electronics Engineers
IP Internet Protocol
ISP Internet Service Provider
MPEG Moving Pictures Experts Groups
MPF Média de pacotes transmitidos até a falha
NF Número de falhas ocorridas
NM Número máximo de falhas
NP Número de pares utilizados
NR Número de repetições realizadas
P2P Peer-to-peer
PF Percentual de falhas ocorridas
PG Total de pacotes gerados durante uma transmissão sem erros
PTF Percentual médio do vídeo transmitido até a falha
QoS Quality of Service
RFC Request for Comments
8
RTP Real-time Transport Protocol
RTSP Real Time Streaming Protocol
TCP Transmission Control Protocol
TP Tempo médio de execução dos pares que não apresentaram
falhas
TPF Tempo médio de execução dos pares que apresentaram falhas
TS Tempo médio de execução do servidor
VCR Video Cassete Recording
VoD Video on Demand
VOIP Voice Over Internet Protocol
LISTA DE FIGURAS
Figura 1 – Fluxo de vídeo unicast .............................................................................18
Figura 2 – Fluxo de vídeo multicast...........................................................................19
Figura 3 – Arquitetura centralizada ...........................................................................21
Figura 4 – Arquitetura baseada em proxy .................................................................22
Figura 5 – Rede de distribuição de conteúdo............................................................22
Figura 6 – Arquitetura híbrida....................................................................................23
Figura 7 – (a) Falha ou saída inesperada de um par ................................................28
Figura 7 – (b) Auto-adaptação da rede .....................................................................28
Figura 8 – Topologia de fluxo de vídeo P2P organizado em árvore..........................30
Figura 9 – Topologia de fluxo de vídeo P2P organizado em malha ..........................31
Figura 10 – Distribuição de conteúdo no PRIME.......................................................35
Figura 11 – Gráfico demonstrativo de flash crowd ....................................................43
Figura 12 – Gráfico percentual de pares sem falhas x pares com falhas em A1.......54
Figura 13 – Gráfico percentual de pares sem falhas x pares com falhas em A2.......54
Figura 14 – Gráfico relação PTF x NF em A .............................................................55
Figura 15 – Gráfico percentual de pares sem falhas x pares com falhas em B1.......56
Figura 16 – Gráfico percentual de pares sem falhas x pares com falhas em B2.......57
Figura 17 – Gráfico percentual de pares sem falhas x pares com falhas em B3.......58
Figura 18 – Gráfico percentual de pares sem falhas x pares com falhas em B4.......59
Figura 19 – Gráfico relação PTF x NF em B .............................................................60
Figura 20 – Gráfico percentual de pares sem falhas x pares com falhas em C1 ......61
Figura 21 – Gráfico percentual de pares sem falhas x pares com falhas em C2 ......61
Figura 22 – Gráfico percentual de pares sem falhas x pares com falhas em C3 ......62
Figura 23 – Gráfico percentual de pares sem falhas x pares com falhas em C4 ......63
Figura 24 – Gráfico relação PTF x NF em C .............................................................64
Figura 25 – Gráfico relação PTF x PF dos melhores casos ......................................65
Figura 26 – Gráfico relação PTF x PF dos piores casos ...........................................66
10
LISTA DE QUADROS
Quadro 1 – Comparativo entre sistemas de streaming P2P.................................... 38
Quadro 2 – Comparativo entre características de flash crowds e aaques de DoS.. 42
Quadro 3 – Parâmetros utilizados nas experimentações dos cenários ................... 51
Quadro 4 – Parâmetros utilizados nas experimentações dos cenários ................... 52
Quadro 5 – Siglas e Parâmetros utilizados na avaliação.......................................... 55
SUMÁRIO
1 INTRODUÇÃO................................................................................................. 13
1.1 Motivação.......................................... ........................................................... 13
1.2 Objetivos.......................................... ............................................................ 14
1.3 Organização do texto............................... ................................................... 14
2 FLUXO DE VÍDEO........................................................................................... 15
2.1 Aplicações ......................................... .......................................................... 16
2.2 Tipos de fluxos de vídeo........................... .................................................. 17
2.2.1 Fluxo de vídeo sob demanda (VoD) ........................................................... 17
2.2.2 Fluxo de vídeo ao vivo (Live streaming) ..................................................... 18
2.3 Protocolos......................................... ........................................................... 19
2.4 Arquitetura e topologia............................ ................................................... 20
2.4.1 Centralizada ............................................................................................... 20
2.4.2 Baseada em proxy...................................................................................... 21
2.4.3 Rede de distribuição de conteúdo (CDN) ................................................... 22
2.4.4 Híbrida ........................................................................................................ 23
2.4.5 Considerações sobre o Capítulo ................................................................ 23
3 REDES PAR-A-PAR (P2P) .............................. ............................................... 25
3.1 Características de redes P2P ....................... .............................................. 26
3.2 Organização de redes de sobreposição............... ..................................... 28
3.3 Streaming P2P...................................... ....................................................... 29
3.3.1 Topologia em árvore................................................................................... 30
3.3.2 Topologia em malha ................................................................................... 31
4 TRABALHOS RELACIONADOS ............................. ....................................... 32
4.1 Chainsaw ..................................................................................................... 32
4.2 AnySee ......................................................................................................... 33
4.3 Coolstreaming ............................................................................................. 33
4.4 PRIME ........................................................................................................... 34
4.5 Análise comparativa de sistemas de fluxo de vídeo p ar-a-par ............... 35
4.6 Problemas identificados............................ ................................................. 37
5 FLASH CROWD ........................................ ...................................................... 39
12
5.1 Identificação de eventos de flash crowd............ ....................................... 39
5.2 Flash crowds em sistemas Par-a-par ................. ....................................... 41
6 MÉTODO PROPOSTO.................................................................................... 44
6.1 Escopo do Trabalho................................. ................................................... 44
6.2 Linguagem e ambiente de programação................ ................................... 45
6.3 Estrutura do protótipo ............................. ................................................... 46
6.3.1 Módulo Bootstrap ....................................................................................... 46
6.3.2 Módulo Servidor de Fluxo de vídeo ............................................................ 47
6.3.3 Módulo par.................................................................................................. 48
6.3.4 Módulos e funcionalidades do protótipo ..................................................... 48
6.4 Avaliação do Método ................................ .................................................. 49
6.5 Cenários........................................... ............................................................ 49
6.5.1 Cenário A.................................................................................................... 51
6.5.2 Cenário B.................................................................................................... 51
6.5.3 Cenário C ................................................................................................... 51
6.6 Análise e resultados ............................... .................................................... 52
6.6.1 Resultados e análise do cenário A ............................................................. 53
6.6.2 Resultados e análise do cenário B ............................................................. 56
6.6.3 Resultados e análise do cenário C ............................................................. 60
6.6.4 Comparação entre cenários ....................................................................... 64
7 CONSIDERAÇÕES FINAIS............................... .............................................. 67
7.1.1 Resultados encontrados ............................................................................. 67
7.1.2 Limitações e dificuldades encontradas....................................................... 68
7.1.3 Trabalhos futuros........................................................................................ 69
REFÊRENCIAS..................................................................................................... 71
APÊNDICE A – Código fonte do módulo Bootstrap ...... ................................... 76
APÊNDICE B – Código fonte do módulo Servidor de flu xo de vídeo ............. 78
APÊNDICE C – Código fonte do módulo Par ............ ........................................ 79
1 INTRODUÇÃO
Na medida em que os avanços tecnológicos são constantes, a necessidade
de obter informações em tempo real é imprescindível. Este comportamento
ocasionou um aumento na demanda por acessos, e com ela a criação de
mecanismos para atendê-las. A transmissão de vídeos em tempo real é um grande
desafio, pois fluxos de vídeo em tempo real sofrem grande sensibilidade ao atraso e
perda de pacotes, por este motivo é necessário garantir uma série de pré-requisitos
para que seja garantida a usabilidade desta tecnologia.
Redes par-a-par (P2P) (CLARK, 2001) responsáveis atualmente por grande
parte da disponibilidade do conteúdo multimídia na rede (Internet) acompanham o
aumento da banda, possibilitando assim que mais usuários tenham acesso a
informações em tempo real. Conseqüentemente esta estrutura necessita de um
grande poder de escalabilidade para aumentar os recursos disponíveis na rede.
1.1 Motivação
A utilização de sistemas par-a-par para as mais diversas áreas vem
crescendo dia a dia podendo ser aplicados nos contextos mais variados, como
principal fator de motivação deste estudo é o desafio de se iniciar novas discussões
e pesquisas na área de flash crowd em sistemas de fluxo de vídeo ao vivo par-a-par,
uma vez que a maioria dos estudos relacionados a flash crowd nestes ambientes
está diretamente relacionada ao estudo do comportamento de usuários na rede.
14
1.2 Objetivos
Existem muitos desafios encontrados para se disponibilizar conteúdo com
qualidade em sistemas de distribuição de fluxo de vídeo ao vivo para um grande
número de usuários simultaneamente. Um dos tópicos em aberto é a estabilidade e
escalabilidade destes sistemas quando estão sofrendo eventos de flash crowds.
Os eventos de flash crowd são problemas encontrados em diversas áreas da
computação onde existem vários usuários que podem acessar ao mesmo conteúdo,
desde um site na Internet até sistemas de transmissão de conteúdo multimídia.
Diante disto este trabalho tem como principal objetivo analisar o problema de
flash crowds em sistemas de fluxo de vídeo ao vivo par-a-par através de
experimentações e análises dos resultados. Serão analisados neste trabalho a
influencia que o tamanho do payload enviado pelo servidor de fluxo de vídeo e o
tamanho de buffer de leitura especificado em cada um dos pares gera para o
sistema de fluxo de vídeo ao vivo par-a-par durante flash crowds.
1.3 Organização do texto
Além da apresentação do presente Capítulo, o restante deste trabalho esta
organizado como segue. No Capítulo 2, são apresentados conceitos e definições de
fluxo de vídeo, áreas de aplicação e aplicações, tipos, protocolos e arquitetura. O
Capítulo 3 apresenta redes par-a-par assim como suas características, organização
e topologia. O Capítulo 4 reúne os trabalhos diretamente relacionados a estes. No
Capítulo 5 é abordada a descrição de flash crowds, formas de identificação e flash
crowds em sistemas de fluxo de vídeo ao vivo par-a-par. No capítulo 6, é
apresentada a metodologia utilizada durante as análises realizadas neste trabalho.
As conclusões e considerações sobre a continuação do trabalho são apresentadas
no Capítulo 7, que encerra este trabalho.
2 FLUXO DE VÍDEO
Segundo Apostolopoulos (2002), vídeo tem sido uma importante mídia para
comunicação e entretenimento durante muitas décadas. Inicialmente a captura e
transmissão dos vídeos eram feitas de uma forma analógica, com o avanço da
tecnologia foram criadas técnicas de digitalização de vídeo. As pesquisas na área de
compressão de vídeo começaram a se tornar importantes desde então, resultando
em tecnologias largamente utilizadas atualmente como armazenamento de vídeo em
DVDs e CDs, transmissão de vídeo digital sobre cabo, satélite e televisão digital
terrestre (DTV) e conferências de vídeo e videofones. Inicialmente as aplicações de
comunicação de vídeo através da Internet eram feitas de acordo com o
funcionamento da Internet, ou seja, utilizando a entrega de pacotes por melhor
esforço. Foi constatado que as transmissões de vídeo utilizando melhor esforço
eram problemáticas por diversos fatores, tais como, jitter, delay, perda de pacotes,
falta de um mecanismo para distribuição justa de recursos da rede e também a falta
de uma maneira eficiente para de distribuição conteúdos populares de uma fonte
para muitos receptores (Apostolopoulos, 2002).
Fluxos de vídeo são sequências de “imagens em movimento” comprimidas e
distribuídas através da Internet, podendo ser acessadas assim que alcançarem o
seu destino final. O servidor de fluxo de vídeo pode utilizar transmissões do tipo
unicast ou multicast.
Uma das grandes vantagens na distribuição do conteúdo por fluxo de vídeo é
que os usuários não necessitam esperar o download completo de um arquivo para
poderem reproduzir o mesmo, o receptor começa a reproduzir o conteúdo assim que
os primeiros pacotes começam a chegar a seu computador, desta forma o usuário
inicia a reprodução do vídeo mesmo sem ter o arquivo completo em seu
computador. Para a reprodução do conteúdo, é necessário, que o usuário tenha um
16
software de reprodução de mídia (player) instalado em seu computador ou um plugin
integrado em seu navegador de Internet. Geralmente este player ou plugin podem
ser encontrados diretamente no site do fabricante ou responsável pelo software de
fluxo de vídeo.
2.1 Aplicações
A forma como os usuários acessam as informações na Internet tem mudado
ao longo do tempo, cada vez mais os usuários procuram conteúdos como filmes,
programas de televisão e outros tipos de conteúdos multimídia, os quais eles
consigam acessar pela rede. A distribuição de fluxo de vídeo agrega funcionalidades
nas mais diversas áreas, entre elas se podem citar as áreas de educação à
distância, cursos e treinamentos, rádios virtuais, publicidade, notícias, televisão
digital, videoconferência, teleconferência, jogos distribuídos, realidade virtual,
entretenimento, entre outras.
Muitas empresas têm investido pesado em pesquisa e aplicações de
distribuição de conteúdo por fluxo de vídeo, esta Seção irá apresentar algumas
delas.
O YouTube é uma aplicação gratuita que permite que os usuários
disponibilizem e assistam vídeos, estes são transmitidos para os usuários através de
fluxo de vídeo sob demanda (VoD) (YOUTUBE, 2009).
CNN Pipeline (CNN PIPELINE, 2009) é um serviço que disponibiliza fluxo de
vídeo sob demanda e fluxo de vídeo ao vivo aos usuários.
Amazon Video on Demand (AMAZON, 2009) é um serviço disponibilizado
pela Amazon onde o usuário pode comprar e alugar filmes, seriados, eventos
esportivos. Também existem conteúdos que são disponibilizados de graça para o
usuário.
AOL Video (AOL VIDEO, 2009) disponibiliza um serviço parecido com o
YouTube onde os usuários podem assistir a diversos vídeos enviados através de
fluxos de vídeo sob demanda e fazer upload de vídeos de autoria própria.
17
2.2 Tipos de fluxos de vídeo
Existem diferentes tipos de fluxos de vídeo, estes podem ser feitos através de
fluxo de vídeo sob demanda (VoD) (MOL, 2008) ou fluxo de vídeo ao vivo (live
streaming) (APOSTOLOPOULOS, 2002).
2.2.1 Fluxo de vídeo sob demanda (VoD)
O fluxo de vídeo sob demanda possibilita ao usuário escolher entre uma lista
de vídeos disponibilizados em uma coleção e reproduzi-los assim que o inicio dos
dados começarem a chegar a seu computador. Thouin (2007), afirma que neste tipo
de transmissão o usuário tem praticamente o mesmo controle do conteúdo que ele
teria se estivesse assistindo ao vídeo em um videocassete (VCR) tradicional. O
usuário tem controle dos comandos de pause, play, avanço, avanço rápido,
retrocesso e retrocesso rápido.
O conteúdo multimídia fica previamente armazenado em um servidor e
poderá ser acessado por um longo período de tempo (enquanto o conteúdo estiver
armazenado no servidor), sempre que o usuário fizer uma requisição para acessar
esta mídia, uma das aplicações mais conhecidas de vídeo sob demanda é o
YouTube. (YOUTUBE, 2009)
A entrega de conteúdo consiste em transmitir objetos de um servidor (source)
ou origem para os clientes. Geralmente a entrega de conteúdo ocorre de forma
unicast, ou seja, existe um fluxo de vídeo para cada cliente, o que consome bastante
recurso de rede.
Cada cliente pode acessar ao conteúdo em horas variadas e visualizar partes
diferentes da mídia, de acordo com sua própria escolha.
Geralmente esse tipo de fluxo de vídeo é enviado de maneira unicast. Para a
transmissão unicast são necessárias múltiplas conexões do mesmo servidor de fluxo
de vídeo, mesmo quando este esta transmitindo o mesmo conteúdo para mais de
um receptor. A figura 1 ilustra um servidor de fluxo de vídeo enviando dados desta
maneira.
18
Figura 1 – Fluxo de vídeo unicast Fonte: Autoria própria, 2009.
2.2.2 Fluxo de vídeo ao vivo (Live streaming)
O fluxo de vídeo ao vivo, popularmente conhecido como live streaming ou
streaming em tempo real, assim como o fluxo de vídeo sob demanda, consiste em
enviar o conteúdo de um servidor (source) ou origem para diversos clientes. Uma
das principais diferenças entre fluxo de vídeo ao vivo e fluxo de vídeo sob demanda
é que no fluxo de vídeo ao vivo os clientes não podem acessar o conteúdo do fluxo
de vídeo a qualquer momento, neste tipo de transmissão, existe um agendamento
de horário, onde o responsável pela distribuição do conteúdo irá definir a hora em
que a transmissão será iniciada.
Entretanto caso o usuário queira assistir ao conteúdo em outro momento, é
possível que ele pause o vídeo e futuramente reproduza o conteúdo que esta salvo
em buffer no seu computador.
O fluxo de vídeo ao vivo geralmente só fica disponível por um determinado
período de tempo, por exemplo, a transmissão ao vivo de uma partida de futebol
(APOSTOLOPOULOS, 2002).
De acordo com Rodenas (2008) um grande número de aplicações atuais,
incluindo televisão pela Internet, transmissão de eventos esportivos, jogos online e
educação à distância, requerem suporte para transmissões de fluxo de vídeo ao
vivo. Esta categoria de aplicações caracteriza-se pela entrega de conteúdo
multimídia que está sendo codificado e transmitido quase simultaneamente a uma
quantidade de usuários potencialmente grande.
19
Na maioria dos casos a distribuição de vídeo por fluxo de vídeo ao vivo é feita
de maneira multicast, onde o servidor de fluxo de vídeo envia o mesmo fluxo de
dados para todos os usuários que estão acessando ao seu conteúdo. Cada novo
usuário que requisitar o acesso a esse conteúdo irá recebê-lo a partir do ponto em
que a mídia localizada no momento da requisição e não a partir do início da
transmissão.
A grande maioria dos softwares que fazem transmissão de fluxo de vídeo ao
vivo utiliza um arquivo de vídeo previamente gravado, porém é possível transmitir
eventos ao vivo através da captura de uma câmera web ou de uma câmera digital
video (DV).
A figura 2 mostra um servidor de fluxo de vídeo enviando um fluxo de dados
multicast para os computadores que estão no inscritos no grupo de multicast deste
computador, estes computadores podem ser identificados na figura ao se observar
os computadores que estão recebendo o fluxo de dados enviado pelo servidor, este
fluxo é representado através de setas que são direcionadas diretamente para o
computador pertencente ao grupo de multicast.
Figura 2 – Fluxo de vídeo multicast Fonte: Autoria própria, 2009.
2.3 Protocolos
Existem alguns protocolos específicos para a transmissão de fluxos de mídia,
alguns destes foram padronizados pela IETF e são utilizados em boa parte de
aplicações de fluxo de mídia e fluxo de mídia ao vivo na Internet. Entre eles estão o
RTP (RFC 1889), RTCP (RFC 3550) e RTSP (RFC 2326).
20
O protocolo de transporte Real-time transport protocol (RTP) (RFC 1889,
2009) foi definido e padronizado pela IETF na RFC 1889, este protocolo prove
transporte de dados em tempo real. Ele define padrões de pacote para o transporte
de áudio e vídeo na Internet. Foi desenvolvido para a transmissão de dados em
ponto a ponto em tempo real. Este protocolo não garante a entrega, ele apenas
possui algumas informações que serão úteis para a reconstrução de dados. O
padrão de RTP define um par de protocolos que são usados em conjunto, o RTP
para fazer a entrega de dados e o RTCP para informações de controle e qualidade
de serviço (QoS).
Real-time transport control protocol (RTCP) é um protocolo definido pela RFC
3550 (RFC 3550, 2009), é utilizado em conjunto com o RTP, ele provê estatística e
controle de informações nos fluxos de dados RTP. Este protocolo sozinho não
suporta a transmissão de pacotes, por isto necessita ser utilizado em parceria com o
RTP que trafega os dados enquanto ele envia feedbacks de QoS sobre a
distribuição da mídia.
O Real-time streaming protocol (RTSP), definido pela IETF na RFC 2326
(RFC 2326, 2009), é o protocolo responsável pelo controle do conteúdo multimídia
que esta sendo distribuído via fluxo de dados. Ele possibilita que o usuário envie
controles para o servidor e tenha a possibilidade de controlar a sessão de fluxo de
dados com comandos similares a de um vídeo cassete. Ele possui uma sintaxe
similar a sintaxe do HTTP (RFC 2616, 2009). Alguns servidores de fluxo de dados
possuem as funcionalidades de controle do RTSP implementadas, como é o caso do
Helix Server (Helix Server, 2009) e do QuickTime Streaming Server (QUICKTIME,
2009).
2.4 Arquitetura e topologia
2.4.1 Centralizada
Em uma arquitetura centralizada, o servidor de origem é responsável por
servir todos os clientes do fluxo de dados (THOUIN, 2007). Esta arquitetura também
é conhecida como modelo cliente-servidor. Ela requer uma capacidade alta de
21
banda para que possa transmitir para um número decente de usuários mesmo
quando o streaming que esta sendo enviado tem uma qualidade baixa. “Por
exemplo, para prover 1 Mbit/s de vídeo para 1000 usuários, exige que o servidor
sustente 1000 Mbits/s de throughput de Internet.” (TRIBLE STREAMING
EXPLAINED, 2009).
Thouin (2007) destaca outros problemas desta arquitetura como, por
exemplo, um único ponto de falha e uso elevado da largura da banda. A figura 3
ilustra a sua topologia.
Figura 3 – Arquitetura centralizada Fonte: Adaptada de (THOUIN, 2007).
2.4.2 Baseada em proxy
Esta arquitetura é definida por Thouin (2007) como um avanço da tecnologia
centralizada, sua principal característica é espalhar servidores de proxy com a
réplica do conteúdo do fluxo de dados para perto do usuário final. Estes servidores
armazenam o cache e diminuem o carregamento da rede.
A figura 4 ilustra esta arquitetura onde os servidores de proxy estão
diretamente conectados ao servidor de fluxo de dados, esta ligação é feita para que
os servidores de proxy mantenham cópias do conteúdo original (réplicas). O fluxo
de dados pode ser enviado para os clientes por um dos servidores de proxy ou pelo
servidor de fluxo de dados, dependendo da localidade do cliente na rede.
22
Figura 4 – Arquitetura baseada em proxy Fonte: Adaptada de (THOUIN, 2007).
2.4.3 Rede de distribuição de conteúdo (CDN)
Esta arquitetura é mais conhecida como Content Delivery Network (CDN), o
servidor envia seu conteúdo e a rede CDN fica responsável por fazer a distribuição
do fluxo de dados para os clientes. Hefeeda (2003) questiona que arquiteturas
baseadas em proxy e CDN apenas transferem o gargalo da rede do servidor de
origem para os servidores proxy e não tem um bom custo benefício para a
transmissão de fluxo de mídia. Arquitetura CDN é demonstrada na figura 5.
Figura 5 – Rede de distribuição de conteúdo Fonte: Adaptada de (THOUIN, 2007).
23
2.4.4 Híbrida
Também conhecida como descentralizada, esta arquitetura é baseada no
paradigma par-a-par (P2P) de distribuição de conteúdo. O servidor de origem
funciona como um par fazendo o papel de semente (seed) em uma rede P2P
(HEFEEDA, 2004). Esta arquitetura apresenta vantagens de um custo menor em
relação às demais arquiteturas apresentadas, atualmente existem diversos sistemas
que utilizam arquiteturas híbridas para fazer distribuição de fluxo de conteúdo
multimídia sob redes par-a-par. Cada cliente ou par compartilha seus recursos com
outros clientes para fazer a distribuição do conteúdo, sendo assim a carga do
servidor é diminuída e proporcionalmente o custo de tráfego na rede. A figura 6
apresenta um exemplo desta arquitetura.
Figura 6 – Arquitetura híbrida Fonte: Adaptada de (THOUIN, 2007).
2.4.5 Considerações sobre o Capítulo
Este capítulo apresentou conceitos sobre fluxos de vídeo, assim como suas
aplicações, tipos e topologia, a importância destes conceitos para este trabalho é
entender as diferenças de topologias de fluxo de vídeo e fluxo de vídeo par-a-par,
embora eles utilizem os mesmos tipos de fluxo de vídeo, a topologia da rede e a
distribuição do conteúdo ocorrem de formas diferentes. Entre as topologias de fluxo
de vídeo, podemos acompanhar uma evolução entre elas, iniciando na topologia
24
centralizada com apenas um ponto único de falha, até chegar á arquitetura híbrida
que se aproxima das arquiteturas utilizadas nas redes par-a-par.
3 REDES PAR-A-PAR (P2P)
Originalmente par-a-par (P2P) foi definido como um modelo totalmente
diferente do modelo cliente-servidor, em suas primeiras aparições na literatura,
redes P2P eram referidas como sistemas distribuídos completamente
descentralizados onde todos os pares têm a mesma função dentro da rede,
funcionando tanto como cliente, quanto como servidor (BARCELLOS, 2006). Uma
vantagem em relação à arquitetura cliente-servidor é que nas redes par-a-par os
recursos são compartilhados entre todos os seus pares, com estas características a
rede P2P fica mais suscetível à implementação de balanceamento de carga e
tolerância a falhas.
Este modelo trata todos os usuários da rede com os mesmo direitos e
privilégios (salvo algumas exceções onde existem pares com funções especificas na
rede), todos os participantes da rede são definidos como pares. Eles atuam tanto
como clientes, quanto como servidores e compartilham seus recursos com os outros
pares da rede, os quais são identificados como vizinhos.
As redes P2P foram inicialmente projetadas para o compartilhamento de
recursos computacionais (conteúdo, armazenamento, processamento) através de
trocas diretas ao invés da necessidade de intermediação ou suporte de um servidor
central ou ponto de autoridade na rede (ANDROUTSELLIS-THEOTOKIS, 2004).
Esta característica elimina alguns problemas de redes centralizadas, como por
exemplo, o problema de um único ponto de falha na rede.
Aplicativos P2P passaram a ser associados a uma classe de aplicações que
aproveitam e compartilham recursos como disco, banda de acesso e CPU presentes
nas bordas da Internet (BARCELLOS, 2006).
26
Estas definições de P2P apresentadas anteriormente são a visão primordial
de aplicações par-a-par, excluindo diversas aplicações aceitas recentemente, como
por exemplo, em alguns casos de aplicações podem ser utilizados servidores
centralizados para controle de informações e também pares com funções
diferenciadas de pares ordinários.
Em Barcellos (2006) pode se observar que a utilização de redes P2P não está
mais somente limitada a usuários domésticos, estas aplicações estão sendo
utilizadas também nos meios acadêmicos e corporativos. “Por exemplo, sistemas de
armazenamento de arquivos em rede de transmissão de dados, de computação
distribuída e de colaboração também têm tirado proveito dessas redes”
(BARCELLOS, 2006). Alguns dos fatores que são propícios para essas mudanças
são que as redes P2P são escaláveis, eliminam um ponto único de falha sendo mais
resistentes a ataques de negação de serviço (DoS) e também possibilitam que o
usuário da rede tenha uma autonomia maior quanto à decisão do tempo de
utilização da rede, este de acordo com seu interesse e disponibilidade.
3.1 Características de redes P2P
Dentro das muitas características apresentadas pelas redes par-a-par,
algumas das mais referenciadas nos estudos sobre a área são:
• Descentralização: Os dados são distribuídos em diversos pares localizados
em pontos geográficos diferentes, amenizando o problema de falhas de algum
par.
• Escalabilidade: Redes P2P são conhecidas por sua auto escalabilidade,
geralmente permitindo que um número maior de clientes utilize a rede se
comparada a uma arquitetura centralizada ou ao modelo cliente-servidor, um
dos fatores que possibilitam esta característica é o compartilhamento de
recursos entre o grupo que está conectado na mesma rede.
• Anonimato: Aos pares conectados a uma rede P2P é garantido o anonimato,
este é garantido para autoria de conteúdo, publicação de conteúdo, acesso,
disponibilização de conteúdo, armazenamento e pesquisa.
27
• Custo de propriedade: O compartilhamento de recursos entre os pares
possibilita um baixo custo de propriedade e manutenção do conteúdo.
• Conectividade Ad-Hoc: Pares podem conectar-se e desconectar-se de uma
rede P2P a qualquer momento, ficando assim disponíveis ou não para outros
pares da rede.
• Segurança: Alguns fatores das redes P2P dificultam a segurança no sistema,
entre eles alguns fatores citados por Barcellos (2006) como anonimato,
disponibilidade, autenticidade, confidencialidade, integridade, autorização,
reputação, negabilidade e o não repúdio acarretam em alguns problemas
relacionados à área de segurança. Barcellos (2006) ainda afirma que isto
torna a área de segurança uma das suas principais áreas de pesquisa em
redes par-a-par. Wallach (2002) diz que tornar esta área segura é um grande
desafio.
• Tolerância a falhas: Pela sua descentralização, sistemas P2P são propícios
para tolerância a falhas. Embora essa característica, ainda existe outros
fatores que causam falhas nesses sistemas, entre eles, a entrada e saída
inesperada de muitos pares da rede (churn) (MOL, 2007) e também flash
crowds (LI, 2007).
Barcellos (2006) diz que em um sistema P2P, pares estabelecem ligações
lógicas e interagem através das mesmas, formando uma “rede de sobreposição” ou
overlay no nível de aplicação.
São destacadas três características consideras chaves por Androutsellis-
Theotokis (2004), elas são:
• Compartilhamento direto de recursos computacionais entre os pares sem a
necessidade de intervenção de um servidor centralizado (servidores centrais
são aceitáveis para tarefas específicas como adicionar um par na rede,
manter chaves globais para criptografia e também um index com todos os
pares na rede para pesquisa).
• Sua habilidade de tratar a instabilidade e conectividade variável como norma,
se adaptando automaticamente a falhas tanto em conexões de servidores
quanto em conexão de clientes.
• Capacidade de tolerância a falhas e auto-organização de acordo com a
entrada e saída de pares na rede, a figura 7(a) apresenta essa característica
28
utilizando uma estrutura de aplicações de camada de árvores multicast (ALM)
(LIU, 2008) em uma rede que sofreu uma saída inesperada do sistema e a
figura 7(b) demonstra seu comportamento de se reorganizar.
Figura 7 – (a) Falha ou saída inesperada de um par
Figura 7 – (b) Auto-adaptação da rede Fonte: Adaptada de (LIU, 2007).
3.2 Organização de redes de sobreposição
Redes de sobreposição também são referenciadas como overlays na
literatura disponível sobre estudos de redes P2P, neste estudo serão referenciados
sempre como redes de sobreposição.
Segundo Lua (2005), existe duas classes de construção de redes de
sobreposição em redes P2P, elas podem ser construídas de maneiras estruturas ou
de maneiras não estruturada.
“Essencialmente, a organização determina as regras, caso exista alguma,
para alocação de objetos (ou suas chaves) a nodos, e os algoritmos de busca
empregados” (BARCELLOS, 2006).
De acordo com Lua (2005) alguns dos principais exemplos de infra-estrutura
de redes estruturadas são Chord (STOICA, 2003), Tapestry (ZHAO, 2004), Content
29
Addressable Network (CAN), (RATNASAMY, 2001), Pastry (ROWSTRON, 2001),
Kademlia (MAYMOUNKOV, 2002) e Viceroy (MALKHI, 2002).
Barcellos (2006) e Lua (2005) assumem que os principais exemplos de infra-
estrutura par-a-par não estruturados são Napster (NAPSTER, 2009), Gnutella
(ADAR, 2000), FastTrack/Kazaa (KAZAA, 2009), BitTorrent (BitTorrent, 2009),
Overnet/eDonkey2000, porém este último não está mais disponível por motivos de
infração de leis e distribuição de downloads ilegais.
3.3 Streaming P2P
Geralmente aplicações fluxo de vídeo ao vivo possuem somente uma única
origem (source), esta origem tem a responsabilidade de gerar e distribuir o conteúdo.
A origem é assumida como não falha, permanecendo durante toda a sessão de
broadcast. O endereço de origem é conhecido previamente pelos pares interessados
no conteúdo, servido como um ponto de encontro (rendezvous) para novos usuários
ingressarem na sessão (LIU, 2008).
Para as redes P2P transportarem fluxos de vídeo é necessário que elas
atendam características como larga escalabilidade de usuários, bom desempenho,
restrições de tempo real (a interatividade deve ser garantida, mas é necessária a
sincronização de áudio e vídeo causando um pequeno atraso devido aos buffers) e
degradação cuidadosa da qualidade para atender a diversas larguras de banda.
Segundo Jurca (2007) as aplicações de fluxo de vídeo ao vivo utilizam arquiteturas
de redes adaptativas e auto-organizáveis para conseguirem alcançar seus requisitos
de qualidade. Utilizando redes P2P pode-se dividir a responsabilidade do servidor
com os clientes da rede.
As estruturas básicas consideradas para se prover aplicações em “tempo
real” utilizando redes P2P são: topologia em árvore, e topologia em malha.
30
3.3.1 Topologia em árvore
Os pares da rede são organizados em árvore, tendo suas relações definidas
como pai e filho. Esta organização é útil para propagação de dados na rede com um
menor esforço. Como todos os pacotes são enviados através da árvore, uma
limitação ou problema em um par próximo à raiz pode afetar diversos receptores.
Torna se crítico garantir que a estrutura esteja otimizada para oferecer bom
desempenho para todos os receptores (LIU, 2008).
Segundo Rodenas (2008) As arquiteturas de árvores múltiplas visam tratar os
problemas apresentados pelas árvores simples, provendo redundância nos
caminhos da rede e buscando justiça na participação dos pares. Ela conduz à
solução de problemas contraditórios como minimizar a profundidade da árvore,
enquanto simultaneamente provê a diversidade de caminhos de rede. A topologia
física subjacente deve ser cuidadosamente estudada para obter uma disseminação
eficiente de conteúdo (JURCA, 2007). A figura 8 ilustra a topologia de redes par-a-
par em árvore, o streaming tem a origem em um servidor de fluxo de dados que
repassa o fluxo de dados para os demais pares da rede que estão organizados em
uma estrutura de árvore.
Figura 8 – Topologia de fluxo de vídeo P2P organizado em árvore Fonte: Autoria própria, 2009.
31
3.3.2 Topologia em malha
Diferente das arquiteturas de árvores onde um nó filho recebe um fluxo de
dado do seu nó pai, esta arquitetura permite que os pares existentes na rede
estabeleçam conexões com seus vizinhos de forma mais autônoma como é
demonstrado na figura 9. As redes de sobreposição se diferenciam das organizadas
em árvores, pois nas primeiras não se constrói nem se mantêm uma estrutura
explícita para entrega de dados (LIU, 2008). Segundo Liu (2008) esta arquitetura é
considerada mais robusta contra a entrada e saída inesperada de pares na rede
(churn). Mesmo existindo uma sobrecarga de troca de mensagens relacionadas à
gerência da malha e a propagação do conteúdo, ela parece ser independente do
tamanho da rede, mas tende aumentar com o dinamismo da rede (FODOR, 2007). A
figura 9 demonstra os pares da rede conectados entre si com troca de fluxo de
dados podendo ser feita de maneira bidirecional, diferentemente da estrutura em
árvore os pares estabelecem conexões com outros pares que estão localizados no
mesmo nível da rede e também podem enviar dados para os pares que estão
localizados em um nível inferior ao seu.
Figura 9 – Topologia de fluxo de vídeo P2P organizado em malha Fonte: Autoria própria, 2009.
4 TRABALHOS RELACIONADOS
Neste Capítulo serão brevemente apresentados alguns trabalhos que estão
relacionados diretamente com esta pesquisa, embora existam outras pesquisas em
andamento na área, está Seção será limitada apenas a algumas delas por serem
consideradas mais atuais.
Para a transmissão do fluxo de dados, os sistemas podem utilizar as formas
de push (origem envia o fluxo de dados para os pares), pull (pares requisitam a
transmissão do fluxo de dados) ou utilizar um sistema híbrido destas duas
tecnologias.
4.1 Chainsaw
Chainsaw (PAI, 2005) é um sistema P2P utilizado para transmitir conteúdos
em aplicações de fluxo de vídeo ao vivo, seus autores enfatizam que sua arquitetura
não é baseada em árvores. Embora este trabalho esteja relacionado à pesquisa
proposta neste artigo, o autor não destaca seus mecanismos de roteamento, apenas
afirma que o conteúdo é distribuído através de um simples protocolo de request-
response.
É possível identificar alguns problemas relacionados a este estudo, entre eles
se destacam que os autores não disponibilizam seu código fonte, impossibilitando a
hipótese de gerar uma avaliação independente do código fonte, também não são
apresentadas análises para tratar o problema de free-riders (este problema esta
explicado na Seção 4.5), bem como, o impacto que a entrada e saída de pares irão
causar no funcionamento do sistema.
33
4.2 AnySee
AnySee (LIAO, 2006) (PROJECT ANYSEE, 2006) é uma aplicação de
distribuição de vídeo por fluxo de dados que adota um sistema de inter-overlay
(múltiplas redes de sobreposição) onde os recursos podem ser obtidos em múltiplas
redes de sobreposição. Sua primeira versão disponibilizada em Java tinha sua
topologia baseada em árvore, sendo totalmente reestruturada, nas versões
seguintes adotou uma nova linguagem de programação (C++) e topologia em malha.
4.3 Coolstreaming
No Coolstreaming (XIE, 2007), cada par mantém uma lista parcial dos
identificadores dos pares ativos na rede. Através desses identificadores os pares
conseguem estabelecer conexões TCP entre os outros pares da rede. Uma vez que
os pares estão conectados, estes trocam informações sobre os pares vizinhos do
parceiro, conhecendo assim também os pares vizinhos de seus vizinhos, esta troca
de informação é feita através de um protocolo de Gossip. Em sua arquitetura
existem três módulos básicos:
• Membership Manager: Mantém visão parcial da rede de sobreposição.
• Partnership Manager: Estabelece e mantém parcerias com outros
pares, troca informações de pares ativos na rede e sobre blocos de
conteúdo disponíveis.
• Stream Manager: Responsável pela gerência do fluxo de dados.
O ingresso de novos pares na rede é dado através de um par chamado
Bootstrap, este par é responsável pela Mcache (lista de todos pares participantes na
rede), cada novo par se conecta a ele e recebe uma lista gerada randomicamente
contendo endereços dos pares da Mcache. Cada par mantém a sua Mcache com os
pares recebidos pelo Bootstrap e tenta se conectar a eles.
O fluxo de vídeo é dividido em K subfluxos onde cada par poderá ter um
número K de pares pais. Cada par é dotado com dois buffers, uma para a
sincronização de todos os subfluxos recebidos pelos diversos pais e o outro de
34
leitura. Através do protocolo de Gossip os pares trocam informações de blocos de
vídeo disponíveis e podem requisitar estes blocos de outros pares (pull).
4.4 PRIME
Em PRIME (MAGHAREI, 2007a) (MAGHAREI, 2007c), os pares participantes
da rede formam uma malha randômica direcionada em uma relação pai-filho. Cada
par tenta estabelecer conexão com um número suficiente de pares pais, até que
consiga ocupar toda largura da banda disponível.
A entrega de conteúdo é dada através de mecanismos dinâmicos conforme
apresentado por Magharei (2007a), este sistema emprega um mecanismo dinâmico
de entrega de conteúdo; esse mecanismo é considerado muito complexo inclusive
pelos próprios autores do sistema. O sistema apresenta duas fases de distribuição
de conteúdo:
• Fase de entrega por difusão: Uma vez que um novo segmento de dado
torna-se disponível na origem, os pares do primeiro nível da topologia
requisitam (pull) coletivamente este segmento para a origem, no
próximo intervalo de tempo, os pares localizados no nível dois da
topologia repetem este processo e assim sucessivamente até o último
nível da topologia.
• Fase de entrega por enxame: No final da fase de difusão, os pares
requisitam os segmentos que eles não tenham recebido para os seus
pares pais de mesmo nível na topologia ou de um nível menor.
A figura 10 ilustra as duas fases de distribuição do conteúdo onde difusion
representa a fase de difusão e swarm representa a fase de enxame.
35
Figura 10 – Distribuição de conteúdo no PRIME Fonte: Retirado de (MAGHAREI 2007a).
4.5 Análise comparativa de sistemas de fluxo de víd eo par-a-par
Os sistemas de fluxo de vídeo par-a-par apresentados no quadro 1, na
maioria dos casos, opta por utilizar a topologia de rede em malhas, muitos deles
apresentam características herdadas de sistemas de troca de arquivo par-a-par,
Estes sistemas apresentados, por serem baseados em outros sistemas de par-a-par,
acabam também herdando alguns problemas encontrados nos sistemas os quais
eles foram baseados, é o caso do problema de flash crowds, que no caso dos
sistemas de troca de arquivos não apresenta um impacto tão negativo quanto o
impacto ocasionado em sistemas de fluxo de vídeo par-a-par.
Entre os sistemas apresentados nesta Seção, é possível identificar algumas
diferenças e similaridades, estas características podem ser observadas no quadro 1.
36
Quadro 1 – Comparativo entre os sistemas de streaming P2P
Sistema de fluxo
de vídeo ao vivo
par-a-par
Topologia
Tipo de
requisição de
envio de fluxo
de conteúdo
Implementação
Características
Similaridade
Chainsaw
Não
apresentada.
Pares
requisitam o
envio.
Prototipação
Pacotes contêm
número de
sequencia,
mantém
informações do
grupo de
vizinhos.
BitTorrent.
CoolStreaming
Malha.
Híbrida.
Implementação
em Python.
Pacotes contêm
número de
identificação
único. Mantém
lista dos pares
que estão
conectados.
Utilização de
protocolo de
Gossip para troca
de informações
dos demais
pares.
BitTorrent.
AnySee
Versão 1.0 –
árvore. Versões
2.0, 3.0 e 4.0
em
Malha.
Não
especificada.
Versão 1.0 em
Java, demais
versões em C++.
Mantém
informações dos
vizinhos mais
próximos,
pacotes com
números de
sequência e
distribuição por
técnica de
enxame (mesmo
tipo do BitTorrent)
Narada, Donet
e Gnutella.
PRIME
Malha.
Híbrida.
Prototipação.
Entrega de
conteúdo por
técnicas de
enxame.
Não
apresentada.
Fonte: Autoria própria, 2009.
37
4.6 Problemas identificados
Com base nestes estudos, é possível identificar alguns problemas
considerados os principais em sistemas de fluxo de vídeo ao vivo par-a-par, entre
eles destacam-se churn, free-riders e flash crowds.
Biskupski (2007) aborda alguns problemas encontrados em Chainsaw e no
CoolStreaming, quanto ao Chainsaw ele destaca que redes de sobreposição
randômicas baseadas em malha são ineficientes em redes heterogêneas, limitando
a distribuição de dados e não explorando a proximidade dos pares na rede, em
relação ao CoolStreaming ele demonstra que este utiliza mecanismos para que os
pares identifiquem os melhores vizinhos na rede (called partners) o que acaba
limitando o número de vizinhos e conseqüentemente acaba por não utilizar de
maneira eficiente a capacidade da largura da banda de upload.
Rodenas (2008) destaca que nos artigos relacionados sobre os sistemas
AnySee, Chainsaw e Coolstreaming não existe uma análise aprofundada sobre o
impacto causado pelo churn na rede e nem a disponibilidade de um código fonte
para que possa ser feita a análise do mesmo.
Outro problema apresentado é o problema de free-riders ou free-loaders,
este problema é causado por pares conectados a rede que não estão dispostos a
compartilhar seus recursos, prejudicando consideravelmente a rede.
Magharei (2007c) apresenta que a presença de free-riders na rede afeta
diretamente o funcionamento do PRIME, prejudicando as conexões entre as sub-
árvores afetando diretamente o desempenho na entrega do conteúdo, mesmo
quando os recursos disponíveis são suficientes. Um estudo mais aprofundando nos
resultados revela que free-loaders afetam a conectividade da rede de sobreposição
de uma maneira que desorganiza as duas fases de entrega de conteúdo
(MAGHAREI, 2007b).
Li (2007) afirma que churn causam mudanças constantes no sistema e é
acreditado por ele que essas mudanças constantes são um dos grandes problemas
em sistemas de fluxo de vídeo ao vivo P2P.
Churn e free-riders são problemas considerados críticos, porém já existem
muitos estudos e soluções propostas para a solução de ambos, outro problema
menos discutido na área, porém não menos importante, é o problema da entrada
38
inesperada de muitos usuários na sessão de streaming em um espaço curto de
tempo (flash crowd), este problema será mais bem especificado no Capítulo 5.
Alguns autores destacam que o tempo de inicialização até o início da
reprodução do conteúdo de um fluxo de vídeo (start up delay) é um fator crítico para
transmissões de eventos ao vivo, este tempo é agravado na ocorrência de flash
crowds. Li (2007) destaca que as altas taxas de falhas de ingresso de pares no
sistema durante flash crowds afetam a escalabilidade do sistema e podem tornar
pares estáveis em pares instáveis no sistema. Quando o Coolstreaming está
sofrendo de flash crowds sua Mcache pode ser preenchida com o endereço de
muitos pares que ainda não estão aptos a distribuir um conteúdo de vídeo de
qualidade, causando várias readaptações de pares na rede (tentativa de conexões
com novos pares pais) e consequentemente uma competição entre estes pares para
ingressar no sistema, tornando o sistema instável.
Dentre os problemas destacados, este estudo abordará o problema de flash
crowds em sistemas par-a-par de fluxos de vídeo ao vivo através de uma análise no
comportamento de sistemas de fluxo de vídeo ao vivo durante flash crowds, por
razões de que já são apresentadas estudos dos outros dois problemas discutidos
nesta Seção, podendo assim agregar mais valor as discussões na área.
5 FLASH CROWD
Flash crowd não é um problema específico de redes par-a-par e sistemas de
fluxo de vídeo ao vivo. Existem referências anteriores de estudos sobre flash crowd
na área computacional. Em suas primeiras definições em aplicações
computacionais, muitos autores definem flash crowd como um tráfego repentino e
inesperado em um determinado servidor na Internet, levando este servidor a ficar
inalcançável na rede Internet.
Stavrou (2004) define flash crowd como fenômenos resultantes de um
aumento inesperado de acessos em um objeto online de popularidade. Esta
definição se referencia a flash crowd ocorridas em servidores web e que levam estes
a ficar instáveis ou indisponíveis.
Pan (2002) define flash crowd como um aumento de volume inesperado nas
taxas de requisições para uma página na Internet em particular, levando esta a ficar
virtualmente inalcançável.
Pan (2002) exemplifica alguns eventos de flash crowd em links de sites
populares como Slashdot ou notícias de última hora, como no caso ocorrido dos
ataques terrorista as torres gêmeas em 11 de setembro, nesses casos sites como o
da CNN recebem um número de acessos maior do que o esperado em um curto
espaço de tempo. Outras características de eventos de flash crowd foram que os
recursos de CPU assim como gargalos na largura da banda de Internet são os
primeiros sintomas que pode ser observados.
5.1 Identificação de eventos de flash crowd
Ataques de negação de serviço (DoS) causam muitas vezes os mesmos
efeitos de eventos de flash crowd, estes são referenciados como flash events
40
(JUNG, 2002). Jung (2002) afirma que antes de se estudar os efeitos de flash
crowds é necessário estudar os efeitos de ataques de DoS, por este ser um efeito
relacionado a flash crowd, porém distinto. É necessário identificar no sistema quais
os efeitos são causados por ataques de DoS para poder conte-los e ao mesmo
tempo identificar quais efeitos são causados por flash events, pois estes são
requisições de usuários legítimos e deverão ter o acesso garantido ao sistema.
Jung (2002) salienta algumas diferenças entre ataques de DoS e flash crowds
que devem ser conhecidas e identificadas pelo sistema, o quadro 2 contém um
comparativo entre estes 2 eventos.
Quadro 2 – Comparativo entre características de flash crowds e ataques de Dos
Característica
Flash Events
Ataques de DoS
Volume de tráfego
Os dois fenômenos causam um aumento no número de requisições.
Número de clientes e sua distribuição
Geralmente causados pelo aumento no número de clientes acessando o site. A distribuição dos clientes é esperada por seguir grupos a população agrupada entre os ISPs e redes.
Causadas pelo aumento no número de clientes ou por um cliente em particular enviando requisições em uma taxa elevada. A distribuição dos clientes entre ISPs e redes não segue a distribuição da população.
Sobreposição de clusters
Significantes antes e durante flash events.
Muito pequena.
Taxa de requisição por clientes
Baixas durante flash crowd.
Alguns poucos clientes emitindo uma taxa muito alta ou vários clientes emitindo uma taxa baixa, porém suas taxas sempre são estáveis.
Arquivos requisitados
Distribuição similar com as formas das leis de ZIPF
Formas de distribuição em formato diferente dos apresentados pelas leis de ZIPF
Fonte: Adaptada de (JUNG, 2002).
Li (2002) apresenta outros fatores que podem caracterizar que ocorreu flash
crowds no sistema, ele diz que o comportamento de usuários durante flash crowds
pode ser mais bem identificado de acordo com o número de tentativas de re-
conexões feitas por um par e pelo tempo de espera do par até conseguir ingressar
em uma sessão de fluxo de vídeo.
41
5.2 Flash crowds em sistemas Par-a-par
Estudos realizados demonstram muitas soluções propostas para combater
problemas de flash crowd (STAVROU, 2004) (PAN, 2004) (STADING, 2002) (HUI,
2004) (DESHPANDE, 2007) (RUBENSTEIN, 2005), porém estes estudos são
aplicados para flash crowd ocorridas em servidores de páginas na Internet e podem
ser resolvida através de proxys, replicação de dados ou sistemas par-a-par que tem
a função de fazer o cache do conteúdo ou a replicação dos dados. Embora estas
soluções sejam consideradas eficientes, elas não abordam sistemas par-a-par para
distribuição de conteúdo multimídia através de fluxo de vídeo ao vivo.
Li (2007) define flash crowd em sistemas de fluxo de vídeo como o aumento
súbito no número de usuários ao aderir ao fluxo de vídeo em um curto período de
tempo
É apresentado por Li (2007) que um dos problemas mais críticos em sistemas
par-a-par de fluxo de vídeo ao vivo são flash crowds, porém não tão críticos em
outros sistemas P2P como de troca de arquivos, pois estes podem tolerar um maior
tempo de espera. Sripanidkulchai (2004) afirma que durante um evento de flash
crowd, existe um grande aumento do número de pessoas querendo se sintonizar no
fluxo de vídeo. Consequentemente a taxa de chegada e o número de clientes
concorrentemente aumentam para uma taxa maior do que a taxa média. Todos os
fluxos de vídeo de curta duração apresentam comportamento de flash crowd
(SRIPANIDKULCHAI, 2004).
Flash crowds trazem um desafio para aplicações de fluxo de vídeo ao vivo,
onde é possível que centenas de usuários ingressem no sistema durante os minutos
iniciais do fluxo de vídeo ao vivo, prejudicando a escalabilidade do sistema e a
qualidade da taxa de serviço aceitável para visualizar o conteúdo multimídia (LI,
2007). Flash Crowd em sistemas de fluxo de vídeo ao vivo par-a-par também podem
apresentar problemas de flash crowd durante outras partes da transmissão do
conteúdo, mas geralmente estes problemas são apresentados nos momentos iniciais
da transmissão, pelo motivo de que os usuários geralmente desejam começar a
assistir ao conteúdo desde o seu início, este comportamento é dado de acordo com
um estudo no comportamento de usuários apresentado por Li (2007).
42
Li (2007) também apresenta um estudo baseado no comportamento dos
usuários e no impacto da escalabilidade do sistema durante eventos de flash crowd.
Como sistema base para o estudo foi utilizado o Coolstreaming, alguns resultados
apresentados por eles foram:
• O comportamento de usuários durante flash crowd pode ser mais bem
identificado através do número de tentativas de entrada no sistema.
• O sistema consegue escalar até um determinado limite durante flash
crowds.
• O número elevado de tentativas de readaptação dos pares no sistema
leva os mesmos a receberem endereços de pares que não estão aptos
a transmitir o conteúdo, causando instabilidade no mesmo.
A figura 11 representa um sistema de fluxo de vídeo ao vivo par-a-par que é afetado
por um evento de flash crowd em um determinado tempo de seu funcionamento, ele
representa a taxa de ingresso no sistema durante seu tempo de funcionamento, é
observado a ocorrência de flash crowd a partir do milésimo minuto de funcionamento
do sistema, onde é ilustrado no gráfico o crescimento repentino da taxa de entrada
no sistema até um determinado tempo (aproximadamente no tempo 1200). Pode-se
também ser observado que o sistema aumenta sua escalabilidade até um
determinado limite durante o evento de flash crowd e leva mais um intervalo de
tempo até que retorne a sua condição original.
Li (2007) diz, que em sistemas de fluxo de vídeo ao vivo par-a-par que um
dos fatores que influenciam na escalabilidade do sistema é o start up delay, este
tempo pode ser aumentado ou diminuído de acordo com o tamanho do buffer de
leitura utilizado, caso o tempo inicial seja muito pequeno o sistema pode sofrer de
problemas como a mídia não estar pronto para ser enviada a outro par, caso este
seja muito grande, podem ocorrer muitas tentativas de re-conexão ao sistema
tornando-o instável. Isto gera muitas sessões curtas no sistema acarretando em
competições entre pares e consequentemente em flash crowds, devido a um grande
número de pares ingressando na rede em um período muito pequeno de tempo.
43
Figura 11 – Gráfico demonstrativo de flash crowd Fonte: Retirado de (HEFEEDA, 2004).
Este trabalho visa agregar conhecimentos na área de pesquisas sobre flash
crowds tendo como sua principal motivação o tamanho do problema para sistemas
de fluxo de vídeo ao vivo par-a-par e ao mesmo tempo o desafio por ainda não
existirem muitas discussões sobre o assunto na área.
Neste primeiro momento, o principal objetivo será analisar como o tamanho
do payload dos pacotes transmitidos pelo servidor de fluxo de vídeo e o tamanho de
buffer de leitura nos pares influenciam durante a ocorrência de flash crowds e
também propor algumas sugestões para que seja possível dar continuidade a este
estudo tornando-o um ponto de partida para outros pesquisadores.
6 MÉTODO PROPOSTO
O objetivo do método proposto foi o desenvolvimento de um protótipo de
envio de fluxo multimídia par-a-par para que se fosse possível fazer
experimentações e obter resultados para a análise do flash crowd nestes sistemas.
O protótipo foi o responsável pelo envio de fluxos de vídeo, pelas conexões dos
pares ao servidor de fluxos de vídeo e pela criação e manutenção da rede de
sobreposição. O principal objetivo deste trabalho é a análise realizada com base nos
resultados obtidos durante as experimentações.
6.1 Escopo do Trabalho
O método proposto consiste na criação de um protótipo que foi utilizado para
a geração dos dados que foram utilizados na análise apresentada neste trabalho. O
protótipo desenvolvido é composto por três módulos, o módulo de Bootstrap
baseado no sistema CoolStreaming, um módulo de servidor de fluxo de vídeo e o
módulo de pares com capacidade de se conectar ao Bootstrap para receber uma
lista aleatória de pares ou diretamente ao servidor de fluxo de vídeo.
Os módulos utilizados para geração dos dados analisados foram o módulo de
servidor de fluxo de vídeo e o módulo Par, o módulo Bootstrap não foi utilizado nesta
primeira análise porque o módulo Par ainda não esta aceitando conexões de outros
pares, o que impossibilita a utilização do módulo Bootstrap, uma vez que este gera
uma lista de possíveis pares que possam exercer o papel de pares pais na rede.
45
Para a utilização do módulo Bootstrap nas experimentações foi necessário
programar a funcionalidade de receber conexões de outros pares no módulo Par.
O servidor de fluxo de vídeo tem a capacidade de disponibilizar conteúdo
multimídia para todos os pares conectados a ele, o conteúdo disponibilizado foi um
arquivo multimídia de vídeo gravado anteriormente no formato MPEG, o tamanho do
arquivo de vídeo é de 15,4mb e o seu tempo de duração é de 1,21min, o tamanho e
o tempo de vídeo foram escolhidos aleatoriamente por não serem especificados em
nenhuma das referências deste trabalho e por não serem o foco principal da análise.
O protótipo será utilizado em conjunto com os cenários criados (especificação
dos cenários na Seção 6.5) onde foram realizadas experimentações para a geração
dos resultados que serão realizados.
A análise dos resultados foi feita utilizando variações do tamanho do payload
dos pacotes enviados pelo servidor e do buffer de leitura especificado nos pares.
6.2 Linguagem e ambiente de programação
Para o desenvolvimento do protótipo, foram utilizados linguagem de
programação Python versão 2.5.2 e o sistema operacional Linux Ubuntu com o
kernel na versão 2.6.27-7.
A linguagem de programação Python foi escolhida em funções de sua
portabilidade, velocidade de desenvolvimento e debbuging, estruturas e classes
disponibilizadas pela linguagem, aliado com os bons resultados encontrados em
outros sistemas que foram estudados no decorrer deste estudo, exemplos destes
sistemas são o YouTube e o Coolstreaming. O fator principal que contribuiu para a
escolha da linguagem de programação é que o protótipo foi baseado no sistema
Coolstreaming e o mesmo foi desenvolvido em Python.
O sistema operacional Linux foi escolhido pela facilidade de depuração de
programas através de seu terminal, pelo ótimo suporte em sockets BSD e também
por se tratar de um sistema aberto e preparado para ser utilizado em ambientes de
redes de computadores.
Para a reprodução dos vídeos foi utilizado o software Mplayer com a versão
1.0rc2-4.3.2 devido a sua grande estabilidade, suporte a diversos codecs, bom
46
desempenho na reprodução das mídias e também pela sua funcionalidade de
reproduzir fluxos de dados redirecionados para ele.
6.3 Estrutura do protótipo
Esta Seção apresenta os módulos do protótipo desenvolvido apresentando
suas funções e características.
6.3.1 Módulo Bootstrap
O módulo Bootstrap é o responsável pela criação e manutenção da rede de
sobreposição e também por manter uma lista com todos os pares participantes da
rede, ele recebe conexões através de sockets TCP de pares dispostos a
ingressarem na rede e atende a requisições enviadas por estes pares. Este arquivo
é identificado com o nome Bootstrap.py, seu código fonte esta disponibilizado no
apêndice A.
O Bootstrap atende aos comandos REGISTER, REMOVE, LIST e EXIT:
• REGISTER: Ao se conectar no Bootstrap, um par envia o comando
REGISTER e passa a fazer parte da lista de pares registrados no
Bootstrap (Mcache).
• LIST: Este comando só é permitido aos pares que estão registrados na
Mcache, um envia o comando LIST para o Bootstrap e recebe uma
lista aleatória de até cinco pares candidatos a serem seus pares pais.
Caso ainda não haja nenhum par registrado na Mcache, o Bootstrap
envia automaticamente o endereço do servidor de fluxo de vídeo.
• REMOVE: Este comando serve para atualização da Mcache, sempre
que um par não consegue encontrar um dos pares candidatos a ser
seu pai, ele guarda o endereço deste par em uma lista. Esta lista de
endereços não alcançáveis pode ser enviada para o Bootstrap através
do comando REMOVE, o Bootstrap recebe uma lista de pares e
remove de sua Mcache e finaliza a leitura dos endereços dos pares a
47
serem removidos quando recebe uma mensagem contendo o comando
“FINISH”.
• EXIT: Um par envia o comando EXIT para encerrar a conexão com o
Bootstrap.
Esta estrutura permite que os pares criem uma topologia de rede em malha
onde todos os pares possam se conectar entre si.
Este módulo de Bootstrap será utilizado para trabalhos futuros e atualmente
não fará parte dos cenários estudados no trabalho atual.
6.3.2 Módulo Servidor de Fluxo de vídeo
O módulo de servidor de fluxo de vídeo, identificado como source.py e
disponibilizado no apêndice B é o responsável pela distribuição do conteúdo
multimídia. Este servidor recebe conexões dos pares do sistema através de sockets.
Ele atende ao seguinte comando:
• PLAY: ao receber este comando de um par, o servidor adiciona o par a
sua lista de reprodução, para onde serão enviados os fluxos de vídeo.
Para a geração de flash crowds, este servidor aguarda até um número x de
conexões (definido por parâmetro em sua inicialização), e após receber todas essas
conexões ele inicializa sua transmissão de fluxo de vídeo simulando o efeito de um
evento de flash crowd no sistema.
Este servidor recebe os seguintes parâmetros em sua inicialização:
• Número de pares: Define o número de pares que irão conectar ao
servidor até que o mesmo inicialize a transmissão de fluxo de vídeo.
• Payload: define o tamanho de pacotes que serão enviados para os
pares, sendo que os primeiros 24 caracteres estão reservados para a
identificação dos pacotes (IDs).
• Nome do log: Define o nome do arquivo de log que será gerado, o
nome configurado por parâmetro será complementado pela timestamp
do sistema e pelo sufixo “.txt”.
48
O servidor gera um arquivo de log com o formato csv contendo o número do
id do pacote (ID), tamanho do payload, endereço do par que será enviado o
conteúdo, timestamp da hora em que o pacote foi enviado ao par.
6.3.3 Módulo par
Este módulo consiste de um par da rede par-a-par, assim como no servidor
de streaming, este par permite configurações passadas por parâmetro para que
sejam facilitadas as análises do trabalho. Como parâmetros o programa recebe o
endereço de IP ao qual ele vai se conectar (podendo ser o endereço Bootstrap.py ou
diretamente do source.py), o tamanho do payload, o tamanho do buffer de leitura e o
nome do arquivo de log (este segue o mesmo padrão do servidor de fluxo de vídeo).
No primeiro momento deste estudo os cenários irão apenas fazer a utilização
do servidor de fluxo de vídeo e do módulo par conforme foi explicado na Seção 6.1,
por este motivo, o par esta apenas enviando o comando “PLAY” que é o comando
compatível com o source.py. Nas primeiras versões o módulo de par executava as
funções compatíveis com o módulo Bootstrap, porém a utilização deste módulo será
reservada para futuros trabalhos.
Este módulo não tem um player de mídia proprietária e por este motivo é
utilizado em conjunto com o software Mplayer, o par recebe a mídia, envia o
conteúdo para a saída padrão do sistema (stdout) e então é feito o redirecionamento
deste conteúdo para o software Mplayer. O código fonte deste módulo tem o nome
de node_buffer.py e é demonstrado no apêndice C.
6.3.4 Módulos e funcionalidades do protótipo
As funcionalidades dos módulos implementados no protótipo deste trabalho
são apresentadas no Quadro 3.
49
Quadro 3 – Módulos e funcionalidades do protótipo
Módulos Funcionalidade
Bootstrap Criação e manutenção da rede de sobreposição
Servidor de fluxo de vídeo Envio do fluxo de vídeo para os pares.
Par Requisão e recepção do fluxo de vídeo.
Fonte: Autoria própria, 2009.
6.4 Avaliação do Método
Faz-se necessária uma avaliação do método proposto, onde através de
experimentação e análise comparativa dos resultados serão identificados quais
parâmetros influenciam o sistema durante a ocorrência de flash crowds.
O objetivo desta análise será identificar os seguintes fatores em cada
ambiente:
• Quais ambientes não foram afetados por flash crowds?
• Quais ambientes foram afetados por flash crowds?
• Em que momento ocorre as flash crowds?
• Quantas vezes ocorrem flash crowds?
6.5 Cenários
Os cenários foram compostos pelo módulo de servidor de fluxo de vídeo
(source) com variações de dois, quatro e oito pares no módulo par. O número de
pares utilizados para a configuração dos ambientes foi escolhido de acordo com a
disponibilidade de recursos disponíveis no laboratório de testes durante as
experimentações.
O equipamento utilizado como servidor de fluxo de vídeo foi um notebook com
processador Turion 64 X2 Mobile Technology TL-64 2.2GHz equipado com 2gb de
50
memória RAM utilizando sistema operacional Ubuntu Linux 8.10 "Intrepid Ibex" -
Release i386. Cada par na rede foi composto por uma estação de trabalho utilizando
processador Pentium 4 2.26GHz contendo 768mb de memória RAM com o sistema
operacional Xubuntu 8.10 "Intrepid Ibex" - Release i386.
Os parâmetros alternados nas experimentações de cada cenário foram
payload e tamanho do buffer de leitura conforme especificado no Quadro 3.
Os valores de payload foram escolhidos e ajustados durante o início das
experimentações, os valores escolhidos foram os valores que tiveram a possibilidade
de causar flash crowds e ao mesmo tempo tiveram a oportunidade de fazer a
transmissão do conteúdo multimídia. Os valores escolhidos para o tamanho do
buffer de leitura foram escolhidos durante as experimentações, não foram
encontrados nas referências deste trabalho nenhuma especificação ou valor ideal
para a utilização do tamanho de buffer, por este motivo foram escolhidos valores
com uma pequena diferença de tamanho para que se fosse possível analisar a
diferença de resultados de acordo com a mudança deste parâmetro.
Em cada cenário foram realizadas 4 experimentações, o Quadro 4 contém os
parâmetros utilizados em cada uma delas, sendo que para cada cenário (A, B e C) é
alterado o número de pares.
Quadro 4 – Parâmetros utilizados nas experimentações dos cenários
Experimentação Payload Tamanho do Buffer
1 128kb 50
2 128kb 150
3 256kb 50
4 256kb 150
Fonte: Autoria própria, 2009.
51
6.5.1 Cenário A
Este cenário é composto pelo módulo Servidor de fluxo de vídeo e por duas
instâncias do módulo Par, os computadores utilizados neste cenário seguem as
especificações definidas na Seção 6.5. Este cenário foi utilizado para a realização
dos experimentos A1, A2, A3 e A4.
Os parâmetros utilizados para estas experimentações estão representados no
Quadro 4.
Todas as experimentações contêm o mesmo número de pares, com
diferentes combinações de tamanho do payload transmitido pelo servidor e tamanho
do buffer de leitura utilizado nos pares.
6.5.2 Cenário B
Este cenário foi utilizado para as experimentações B1, B2, B3 e B4, ele é
composto pelo módulo Servidor de fluxo de vídeo e por quatro instâncias do módulo
Par. Os parâmetros utilizados para cada uma das experimentações estão
especificados no Quadro 4.
Para este ambiente foi utilizado a variação do tamanho do payload enviado
pelo servidor de fluxo de vídeo entre 128kb e 256kb enquanto os pares variaram o
tamanho do buffer de leitura entre 50 e 150.
6.5.3 Cenário C
Este cenário foi composto pelo módulo Servidor de fluxo de vídeo e por oito
instâncias do módulo Par. O quadro 4 contém os parâmetros utilizados nas
experimentações deste cenário.
Nos experimentos realizados neste cenário foi aplicada a variação dos
parâmetros de payload entre 128kb e 256kb e tamanho de buffer de leitura entre 50
e 150.
52
6.6 Análise e resultados
Esta Seção apresenta uma análise dos resultados obtidos nas
experimentações realizadas nos cenários especificados na Seção 6.5, inicialmente
foi feita uma análise e comparações dentro de cada um dos cenários, onde foram
identificados o melhor e o pior caso para o cenário em questão. Com o
conhecimento destes resultados, então foi feita uma comparação entre os melhores
resultados e os piores resultados de cada cenário, identificando o melhor e o pior
caso entre todos os cenários. Foi utilizado como parâmetros de comparação entre os
experimentos o número de falhas (NF) x percentual médio transmitido até a falha
(PTF) esta métrica foi utilizada para definir os melhores e os piores casos, sendo
que os melhores casos são aqueles que apresentaram NF menor do que os outros e
em caso de NF ser igual, então o melhor caso é o que apresenta o PTF maior.
Para cada uma das experimentações, foram realizadas quinze repetições pelo
motivo que os resultados das experimentações com este número de repetições eram
muito parecidos um com os outros, não apresentando uma variação muito grande
entre os resultados encontrados.
É assumido um número máximo de falhas (NM) para cada experimento, o
cálculo para encontrar o NM de cada experimento é dado pelo número de pares
(NP) multiplicado pelo número de repetições realizados no experimento, todos os
experimentos de um cenário terão o mesmo NM, o NM é pode ser calculado pela
fórmula NM = NP × NR.
Para um melhor entendimento da análise realizada neste trabalho, o quadro 5
demonstra as siglas e parâmetros que serão utilizadas durante a avaliação dos
resultados.
53
Quadro 5 – Siglas e Parâmetros utilizados na avaliação
NP Número de pares utilizados.
NR Número de repetições realizadas.
NF Número de falhas ocorridas.
NM Número máximo de falhas.
PTF Percentual médio do vídeo transmitido até a falha.
PF Percentual de falhas ocorridas.
TS Tempo médio de execução do servidor.
TP Tempo médio de execução dos pares que não apresentaram falhas.
TPF Tempo médio de execução dos pares que apresentaram falhas.
MPF Média de pacotes transmitidos até a falha.
PG Total de pacotes gerados durante uma transmissão sem erros.
Fonte: Autoria própria, 2009.
6.6.1 Resultados e análise do cenário A
Neste cenário ocorreram os experimentos A1, A2, A3 e A4, em todos os
experimentos foram utilizados NP com valor 2, NR de 15 gerando NM igual a 60.
No resultado de A1, utilizando o tamanho do payload de 128kb e tamanho do
buffer de leitura de 50, foram encontrados TS igual 1,31min., TP igual 1,33min., TPF
igual a 1,17min., NF igual 2, PG igual 156239, MPF igual 78119,5 e PTF igual 50%.
A figura 12 ilustra o gráfico do percentual de pares que funcionaram sem falhas x
pares que falharam no experimento A1, ele apresenta um resultado bom pois o
número de falhas encontrados neste ambiente é pequeno.
54
Figura 12 – Gráfico percentual de pares sem falhas x pares com falhas em A1 Fonte: Autoria própria, 2009.
Na experimentação A2, utilizando tamanho de payload de 128kb e tamanho
de buffer de leitura de 150, o resultado obtido foi TS igual 1,30min., TP igual
1,33min., TPF igual 1,28min., NF igual a 8, PG igual 156239, MPF igual 84402,57 e
PTF igual 54,02%. Na figura 13 é demonstrado o percentual de pares que
funcionaram sem falhas x pares que falharam durante A2, sendo que este cenário
apresenta um número de falhas maior que A1, logo este cenário teve um
desempenho pior do que A1.
Figura 13 – Gráfico percentual de pares sem falhas x pares com falhas em A2 Fonte: Autoria própria, 2009.
55
Foram utilizados durante a experimentação A3 tamanho de payload de 256kb
e tamanho do buffer de leitura de 50. O resultado obtido neste experimento foi TS
igual a 1s., TP igual a 1s., TPF igual a 1s., NF igual 30, PG igual a 70039, MPF igual
84402,57 e PTF igual 0,33% com um total de 100% dos pares com falha.
O experimento A4, com tamanho do payload de 256kb e tamanho de buffer
de leitura de 150, gerou um resultado muito parecido com A3, exceto por MPF ser
igual 49,3 e PTF igual a 0,07%.
A comparação de todos os experimentos realizados neste ambiente pode ser
visualizada na figura 14, onde é demonstrada no gráfico uma relação entre PTF x NF
onde as colunas representam o PTF e a linha representa NF.
Figura 14 – Gráfico relação PTF x NF em A Fonte: Autoria própria, 2009.
Pode se observar no gráfico ilustrado na figura 14 que embora A2 tenha tido o
PTF maior que A1, A1 teve o NF menor que A2 e por este motivo é considerado o
melhor ambiente dentro do cenário A, A4 obteve o mesmo NF de A3, porém com o
PTF menor, sendo considerado o pior ambiente dentro do cenário A.
56
O ambiente A4 apresentou PTF igual a zero pois em todas as repetições
realizadas em sua experimentação, ocorreram erros e não foi possível transmitir o
conteúdo.
6.6.2 Resultados e análise do cenário B
Neste cenário foram realizados os experimentos B1, B2, B3 e B4, para estes
experimentos foram utilizados NP igual 4, NR igual a 15 resultando em NM igual 60.
Em B1, foi utilizado tamanho do payload de 128kb e tamanho de buffer de
leitura de 50, foram encontrados TS igual 1,30min., TP igual 1,28min., TPF igual
44s., NF igual 17, PG igual 156239, MPF igual 57554,47 e PTF igual 47%. A figura
15 mostra o gráfico do percentual de pares que funcionaram sem falhas x pares que
falharam em B1.
Figura 15 – Gráfico percentual de pares sem falhas x pares com falhas em B1 Fonte: Autoria própria, 2009.
Para a experimentação B2 foi configurado payload de 128kb e tamanho de
buffer de leitura de 150. Os resultados encontrados foram TS igual 1,30min., TP
igual a 1,31min., TPF igual 0,31s., NF igual 10, PG igual 156239, MPF igual 35336,8
e PTF igual 22,6%. A figura 16 mostra o gráfico do percentual de pares que
funcionaram sem falhas x pares que falharam no experimento B2, este cenário
57
apresentou um melhor resultado quando comparado com B1 por apresentar NF
menor do que em B1.
Figura 16 – Gráfico percentual de pares sem falhas x pares com falhas em B2 Fonte: Autoria própria, 2009.
No experimento B3 foi utilizado payload de 256kb e tamanho de buffer de 50.
Foram obtidos os seguintes resultados, TS igual 0,28s., TP igual 1,25min., TPF igual
0,0min., NF igual 54, PG igual 70039, MPF igual 1514 e PTF igual 2,16%. A figura
17 ilustra o gráfico do percentual de pares que funcionaram sem falhas x pares que
falharam durante B3, este resultado não apresentou um desempenho bom pois NF é
muito alto.
58
Figura 17 – Gráfico percentual de pares sem falhas x pares com falhas em B3 Fonte: Autoria própria, 2009.
Para a experimentação B4 os parâmetros utilizados foram payload de 256kb e
tamanho de buffer de leitura de 150. Como resultados, foram obtidos TS igual
1,25min., TP igual 1,27min., TPF igual 0,02s., NF igual 45 PG igual 70039, MPF
igual 2760 e PTF igual 3,94%. A figura 18 ilustra o gráfico do percentual de pares
que funcionaram sem falhas x pares que falharam em B4, este ambiente, embora
não tenha apresentado um bom desempenho, este cenário apresentou resultados
melhores que B3 pois seu NF é menor do que o NF encontrado em B3.
59
Figura 18 – Gráfico percentual de pares sem falhas x pares com falhas em B4 Fonte: Autoria própria, 2009.
Seguindo o exemplo da análise realizada no cenário A, foi realizada uma
comparação entre os experimentos realizados no cenário B, a figura 19 demonstra o
gráfico com a relação entre PTF x NF, sendo que as colunas demonstram o PTF de
cada experimentação e a linha demonstra o NF.
60
Figura 19 – Gráfico relação PTF x NF em B Fonte: Autoria própria, 2009.
Para o cenário B, o melhor ambiente encontrado foi B2 como se pode
observar no gráfico apresentado na figura 19 pois este apresenta NF menor do que
os demais ambientes deste cenário, embora B2 tenha o PTF maior que B1, B2
apresenta o NF menor que B1, B3 é considerado o pior ambiente neste cenário por
apresentar PTF menor e NF maior do que todos os outros.
6.6.3 Resultados e análise do cenário C
Os experimentos C1, C2, C3 e C4 foram realizados neste ambiente, todos
eles utilizaram os seguintes parâmetros NP igual a 8, NR igual 15 e NM igual 120.
Para o experimento C1 foi utilizado payload de 128kb e tamanho de buffer de
leitura de 50. Os resultados obtidos foram TS igual 1,33min., TP igual 1,34min., TPF
igual 37s., NF igual 25 PG igual 156239, MPF igual 50369,60 e PTF igual 32,24%. A
figura 20 ilustra o gráfico do percentual de pares que funcionaram sem falhas x
pares que falharam em C1.
61
Figura 20 – Gráfico percentual de pares sem falhas x pares com falhas em C1 Fonte: Autoria própria, 2009.
No experimento C2 foi utilizado payload de 128kb e tamanho de buffer de
leitura de 150. Os resultados obtidos neste experimento foram TS igual a 1,33min.,
TP igual a 1,34min., TPF igual 33s., NF igual 6 PG igual 156239, MPF igual
41502,28 e PTF igual 26,56%. O gráfico do percentual de pares que funcionaram
sem falhas x pares que falharam em C2 é demonstrado na Figura 21, este ambiente
foi o que obteve maior desempenho com apenas 5% de falhas.
Figura 21 – Gráfico percentual de pares sem falhas x pares com falhas em C2 Fonte: Autoria própria, 2009.
62
Em C3 foi utilizado payload de 256kb e tamanho de buffer de leitura de 50.
Este experimento gerou os seguintes resultados, TS igual 1,26min., TP igual
1,37min., TPF igual 1s., NF igual 102 PG igual 70039, MPF igual 1599,68 e PTF
igual 2,28%. É apresentado na figura 22 o gráfico do percentual de pares que
funcionaram sem falhas x pares que falharam em C3.
Figura 22 – Gráfico percentual de pares sem falhas x pares com falhas em C3 Fonte: Autoria própria, 2009.
No ambiente C4 foi utilizado tamanho de payload de 256kb e tamanho de
buffer de leitura de 150. Os resultados encontrados neste experimento foram, TS
igual 54s., TP igual 1,29min., TPF igual 0s., NF igual 111 PG igual 70039, MPF igual
1234,79 e PTF igual 1,76%. É apresentado na figura 23 o gráfico do percentual de
pares que funcionaram sem falhas x pares que falharam no experimento C4.
63
Figura 23 – Gráfico percentual de pares sem falhas x pares com falhas em C4 Fonte: Autoria própria, 2009.
Foi realizada uma comparação entre todos os experimentos realizados neste
cenário, esta comparação pode ser visualizada no gráfico demonstrado na figura 24
na relação entre PTF x NF onde as colunas representam o PTF de cada
experimento e a linha representa NF.
64
Figura 24 – Gráfico relação PTF x NF em C Fonte: Autoria própria, 2009.
O melhor ambiente para este cenário, como pode ser observado na figura 24,
é C2, ele obteve NF menor do que os demais experimentos realizados neste cenário
e o pior resultado para este cenário foi C4 por obter NF maior do que todos os
experimentos deste cenário e PTF menor do que todos os experimentos realizados
no cenário C.
6.6.4 Comparação entre cenários
Esta Seção ira apresentar uma comparação dos melhores e dos piores
resultados de cada cenário. Os experimentos que apresentaram NF menor, foram
considerados como melhores cenário e os experimentos com NF maior como piores
cenários.
Os melhores resultados para cada cenário foram A1, B2 e C2, é ilustrada no
gráfico da figura 25 uma comparação entre esses cenários através do gráfico da
relação entre PTF x PF.
65
Figura 25 – Gráfico relação PTF x PF dos melhores casos Fonte: Autoria própria, 2009.
De acordo com os resultados demonstrados na figura 24, o melhor resultado
de todos os cenários foi obtido em C2 por apresentar NF menor do que todos os
outros experimentos, seguido de A1 e B2.
Os piores resultados encontrados para cada cenário foram A4, B3 e C4, a
comparação entre eles é feita através do gráfico da relação entre PTF x PF
conforme é ilustrado na figura 26.
66
Figura 26 – Gráfico relação PTF x PF dos piores casos Fonte: Autoria própria, 2009.
Conforme pode ser observado na figura 26, o pior caso de todos é encontrado
em A4 onde PF é maior do que os outros casos assim como PTF é menor, seguido
de B3 e C4.
Entre os melhores casos, todos os resultados obtidos foram com o payload de
128kb e entre os piores casos, todos os experimentos apresentaram payload de
256kb. Para os cenários estudados o tamanho de payload menor obteve melhores
resultados independente de NP. O tamanho de buffer de leitura teve seu
comportamento variável, tendo desempenho pior em todos os casos do cenário A
quando seu valor era de 150, um desempenho melhor em todos os casos de B com
valor de 150. Em C tamanho de buffer de leitura de 150 obteve melhor resultado
com payload de 128kb e pior resultado para payload de 256kb. O tamanho de buffer
de leitura influencia o desempenho durante flash crowds, porém ele depende de
fatores como NP e tamanho do payload para melhorar ou piorar a qualidade do
sistema.
67
7 CONSIDERAÇÕES FINAIS
Durante o decorrer desta pesquisa, foram estudados vários conceitos e
definições até focar no principal problema de estudo deste trabalho que é a análise
no flash crowd para transmissão multimídia em redes par-a-par.
Levando em consideração toda fundamentação teórica analisada, foi
apresentada a proposta de um método para análise no flash crowd para transmissão
de multimídia em redes par-a-par.
7.1.1 Resultados encontrados
Em respostas aos objetivos inicialmente vistos por este trabalho é possível
destacar que todos os objetivos foram atingidos plenamente. A execução do modelo
proposto foi executada com sucesso em diversos ambientes e testada com diversos
parâmetros diferentes. Os problemas de pesquisa apresentados na seção 6.4 foram
numerados e respondidos conforme apresentados a seguir:
1. Quais ambientes não foram afetados por flash crowds? Antes de
responder esta pergunta, é importante salientar que todas as falhas de
pares ocorridas no sistema foram assumidas como falhas causadas
pelas flash crowds, todos os ambientes foram afetados pelas flash
crowds, porém alguns menos do que os outros, o ambiente menos
afetado por todos foi o ambiente C2 que sofreu apenas 5% de erros
durante sua experimentação.
2. Quais ambientes foram afetados por flash crowds? Todos ambientes
foram afetados, alguns sofrendo menos falhas e outros sofrendo falhas
68
críticas ao sistema, os ambientes A3 e A4 resultaram em um total de
100% de falhas para todos os pares e para o servidor em todas suas
tentativas de execução.
3. Em que momento ocorre as flash crowds? Nos testes realizados no
cenário A1 e A2 as falhas ocorrem próximas ao tempo final de
execução, nos ambientes A3, A4, B13, C3 e C4 ocorrem falhas antes
de 1 segundo de execução do programa. Geralmente as falhas
ocorrem no início do programa, conforme foi observado em TPF.
4. Quantas vezes ocorrem flash crowds? O número de vezes que
ocorreram flash crowds durante as experimentações é apresentado
conforme segue, em A1 ocorrem duas vezes, em A2 ocorrem 8 vezes,
em A3 e A4 ocorrem 15 vezes sendo que em todas elas nenhum dos
pares conseguiu executar o programa sem falhas, em B1 ocorrem 12
vezes, em B2 ocorrem 10 vezes, em B3 ocorrem 15 vezes sendo que
em 10 delas acontece o mesmo problema de A3 e A4, em B4
acontecem 15 vezes, em C2 acontecem 5 vezes em C3 acontecem 15
vezes sendo que 1 vez apresenta os mesmos problemas de A3 e A4 e
em C4 ocorrem 15 vezes sendo 6 delas com falha em todos os pares.
Esta análise identificou que em todos ambientes o tamanho do payload menor
funciona com menos erros e que na maioria dos casos o tamanho de buffer de
leitura maior teve um melhor desempenho no sistema, porém este desempenho
varia de acordo com NP e o tamanho do payload utilizado.
7.1.2 Limitações e dificuldades encontradas
Como dificuldades se podem apontar o tempo de execução do período de
testes e a disponibilidade de ambientes para se montar os cenários. Também
existiram algumas dificuldades durante a prototipação, um dos principais fatores foi o
fato de nenhum dos sistemas apresentarem o tamanho de buffer de leitura do
sistema.
69
Pelo motivo do protótipo não apresentar um sistema de re-conexões dos
pares perante as falhas, foi considerado a falha de um par no sistema como uma
falha ocasionado por flash crowd.
Outro fator considerado como limitação neste trabalho é o fato dos cenários
apresentarem um número pequeno de pares na rede e não terem sido testados em
ambiente de Internet.
O protótipo desenvolvido para testes foi baseado em algumas características
do Coolstreaming, porém este não apresenta todas as funcionalidades encontradas
no Coolstreaming original. O motivo da não utilização do próprio Coolstreaming
como sistema de fluxo de vídeo ao vivo par-a-par foi pela indisponibilidade de um
código fonte para análise do mesmo e por este sistema ter se tornado um sistema
comercial não existindo uma versão gratuita.
As experimentações realizadas não utilizaram o módulo de Bootstrap
desenvolvido no protótipo e por este motivo os experimentos realizados se limitaram
a uma topologia de rede em árvore ao invés da topologia de rede em malha
apresentado no Coolstreaming.
7.1.3 Trabalhos futuros
Esta fase inicial deste trabalho identificou alguns parâmetros que influenciam
nos sistemas durante a ocorrência de flash crowds, porém deixou em aberto uma
série de outros fatores que podem ser utilizados para complementar este estudo.
Dentre as linhas de estudo que podem ser seguidas para melhorar esta pesquisa
estão:
• Análise de delay e jitter utilizando o tempo e o número de pacotes
gerados nas análises (quantidade de pacotes gerados/seg).
• Análise utilizando tamanhos de vídeo maiores.
• Experimentação em ambientes reais como, por exemplo, a Internet.
• Implementação de melhorias no servidor de fluxo de vídeo para que
este tenha capacidade de transmitir conteúdos ao vivo capturados
diretamente de uma webcam ou de uma câmera DV.
70
Implementação de melhoria nos pares para que estes possam receber conexões
de outros pares da rede e possam ser utilizados em conjunto com o módulo de
Bootstrap.
REFÊRENCIAS
ADAR, E; HUBERMAN, B. A. Free riding on Gnutella . First Monday, v.5, Oct 2000. Disponível em http://firstmonday.org/issues/issue5_0/adar/index.html. Acessado em Set 2008.
ANDROUTSELLIS-THEOTOKIS, S.; SPINELLIS, D. A Survey of Peer-to-Peer Content Distribution Technologies . ACM COMPUTING SURVEYS, v.36, n.4, p.335-371, 2004.
AOL VIDEO . Site de conteúdo de video disponibilizado por streaming. 2009. Disponível em http://video.aol.com/. Acessado em Mai 2009.
APOSTOLOPOULOS, J.G.; TAN, W.T.; WEE S.J. Video streaming: Concepts, algorithms, and systems. HP, Tech. Rep. HPL-2002- 260, 2002.
Amazon . Site de conteúdo de video disponibilizado por streaming. 2009. Disponível em http://www.amazon.com/gp/video/ontv/start/ref=sv_atv_1. Acessado em Mar 2009.
BARCELLOS, M. P; GASPARY, L. P. Fundamentos, Tecnologias e Tendências rumo a Redes P2P Seguras . SBC JORNADAS DE ATUALIZAÇÃO EM INFORMÁTICA (JAI), 2006.
BISKUPSKI, B.; CUNNINGHAM, R.; MEIER, R. Improving Throughput and NodeProximity of P2P Live Video Streaming through O verlay Adaptation. NINTH IEEE INTERNATIONAL SYMPOSIUM ON MULTIMEDIA, 2007. ISM 2007, p.245-253, Dec 2007.
CLARK, David. Face-to-Face with Peer-to-Peer Networking . IEEE Computer, vol. 34, no. 1, p.18-21, Jan 2001.
CNN Pipeline . Site de conteúdo de video disponibilizado por streaming. 2009. Disponível em http://www.cnn.com/pipeline/. Acessado em Mar 2009.
DESHPANDE, M. et al. Flashback: A Peer-to-Peer Web Server for Flash Crow ds . IN ICDCS '07. 27TH INTERNATIONAL CONFERENCE DISTRIBUTED COMPUTING SYSTEMS, p.15, JUN 2007.
FODOR, V; DAN, G. Resilience in live peer-to-peer streaming. IEEE COMMUNICATIONS MAGAZINE, v.45, issue 6, p.116-123, Jun 2007.
72
HEFEEDA, M. M; BHARGAVA, B. K.; YAU, D. K. Y. A hybrid architecture for cost-effective on-demand media streaming. In: The International Journal of Computer and Telecommunications Networking , v. 44, p.353–382, 2004.
HEFEEDA, M.; BHARGAVA, B. On-Demand Media Streaming Over the Internet. IN PROC. OF 9TH IEEE WORKSHOP ON FUTURE TRENDS OF DISTRIBUTED COMPUTING SYSTEMS (FTDCS'03), p.279-285, San Juan, Puerto Rico, Slides, May 2003.
HUI, K.Y.K.; LUI, J.C.S.; YAU, D.K.Y. Small world overlay P2P networks. IN TWELFTH IEEE INTERNATIONAL WORKSHOP ON QUALITY OF SERVICE, 2004. IWQOS 2004, p.201-210, Jun 2004.
Helix Server . Site da empresa real networks 2009. Disponível em http://www.realnetworks.com/products/media_delivery.html. Acessado em Mai 2009.
JUNG J.; KRISHNAMURTHY B.; RABINOVICH M. Flash crowds and denial of service attacks: characterization and implications for CDNs and web sites . IN ACM INTERNATIONAL WORLD WIDE WEB CONFERENCE ARCHIVE PROCEEDINGS OF THE 11TH INTERNATIONAL CONFERENCE ON WORLD WIDE WEB, p.293-304, 2002.
JURCA, D. et al. Enabling adaptive video streaming in p2p systems. IEEE COMMUNICATIONS MAGAZINE, v.45, issue 6, p.108-114, Jun 2007.
KAZAA . Site do programa de troca de arquivos Kazaa. 2009. Disponível em http://www.kazaa.com. Acessado em Jun 2009.
LI, B. et al. An Empirical Study of Flash Crowd Dynamics in a P2P -Based Live Video Streaming System. IEEE JOURNAL ON SELECTED AREAS IN COMMUNICATIONS, SPECIAL ISSUES ON ADVANCE IN PEER-TO-PEER STREAMING SYSTEMS, v.25, n.9, p.1627-1639, Dec 2007.
LI, B. et al. Inside the New Coolstreaming: Principles, Measureme nts and Performance Implications. IEEE INFOCOM 2008. THE 27TH CONFERENCE ON COMPUTER COMMUNICATIONS, p.1031-1039, Apr 2008.
LIAO, X. et al. Anysee: Peer-to-peer live streaming . INFOCOM 2006. 25TH IEEE INTERNATIONAL CONFERENCE ON COMPUTER COMMUNICATIONS. PROCEEDINGS, p.1-10, Apr 2006.
LIU, J. et al. Opportunities and challenges of peer-to-peer intern et video broadcast . PROCEEDINGS OF THE IEEE, v.96, issue 1, p.11-24, Jan 2008.
73
LUA, E. K. et al. A survey and comparison of peer-to-peer overlay net work schemes . IEEE COMMUNICATIONS SURVEYS & TUTORIALS, v.7, issue 2, p.72-93, 2005.
MAGHAREI, N.; GUO, Y; REJAIE, R. Issues in Offering Live P2P Streaming Service to Residential Users. CONSUMER COMMUNICATIONS AND NETWORKING CONFERENCE, 4th IEEE CCNC, p.757-762, Jan 2007c.
MAGHAREI, N.; REJAIE, R.; GUO, Y. Mesh or Multiple-Tree: A Comparative Study of Live P2P Streaming Approaches. INFOCOM 2007. 26TH IEEE INTERNATIONAL CONFERENCE ON COMPUTER COMMUNICATIONS. p.1424-1432, May 2007a.
MAGHAREI, N.; REJAIE, R. PRIME: Peer-to-Peer Receiver-drIven MEsh-based Streaming . INFOCOM 2007. 26TH IEEE INTERNATIONAL CONFERENCE ON COMPUTER COMMUNICATIONS. p.1415-1423, May 2007b. Accepted to IEEE/ACM TRANSACTIONS ON NETWORKING, to appear in October 2009. Disponível em <http://mirage.cs.uoregon.edu/public.html>.
MALKHI, D.; NAOR, M.;RATAJCZAK, D. Viceroy: a scalable and dynamic emulation of the butterfly. IN PROCESSINGS OF THE ACM PODC’02, Monterey, CA, USA, p.183-192. Jul 2002
MAYMOUNKOV, P.; MAZI`ERES D. Kademlia: A peer-to-peer information system based on the xor metric . IN PROCESSINGS OF THE IPTPS, Cambridge, MA, USA, p.53-65, Feb 2002.
MOL, J.J.D. et al. Give-to-Get: An Algorithm for P2P Video-on-Demand. FIFTEENTH ANNUAL MULTIMEDIA COMPUTING AND NETWORKING CONFERENCE, Jan 2008. Disponível em <http://tv.seas.harvard.edu/give-to-get_algorithm_for_P2P_Video_on_Demand.pdf>.
MOL, J.J.D. et al. The Orchard Algorithm: Building Multicast Trees for P2P Video Multicasting Without Free-Riding. IEEE TRANSACTIONS ON MULTIMEDIA, v.9, N.8, Dec 2007.
NAPSTER. Site do serviço de download de MP3 Napster. 2009. Disponível em http://free.napster.com. Acessado em Mar 2009.
PAI, V. et al. Chainsaw: Eliminating trees from overlay multicast . IN PROC. THE 4TH INTERNATIONAL WORKSHOP ON PEER-TO-PEER SYSTEMS, 2005.
PAN, C. et al. Flash crowds alleviation via dynamic adaptive netwo rk. IN INTERNET CONFERENCE 2004, p.21-28, Tsukuba, Japan, Oct. 2004.
74
PROJECT ANYSEE . Site do projeto ANYSEE. 2009. Disponível em http://grid.hust.edu.cn/qihuang/doku.php?id=anysee. Acessado em Mai 2009.
QUICKTIME. Site da empresa Apple. 2009. Disponível em http://www.apple.com/quicktime/streamingserver/. Acessado em Mai 2009.
RATNASAMY, S. et al. A scalable content addressable network . In ACM SIGCOMM 2001, p.161-172, 2001
RFC 1889. Site da IETF. 2009. Disponível em http://tools.ietf.org/html/rfc1889. Acessado em Mar 2009.
RFC 2326. Site da IETF. 2009. Disponível em http://tools.ietf.org/html/rfc2326. Acessado em Mar 2009.
RFC 2616. Site da IETF. 2009. Disponível em http://tools.ietf.org/html/rfc2616. Acessado em Mar 2009.
RFC 3550. Site da IETF. 2009. Disponível em http://tools.ietf.org/html/rfc3550. Acessado em Mar 2009.
RODENAS, Vânia R. Sávio; JANSCH-PORTO, Ingrid; BARCELLOS, Marinho P. Abordagem para obter uma rede de sobreposição coesa visando aplicações de live streaming em sistemas P2P . ESCOLA REGIONAL DE REDES DE COMPUTADORES (ERRC), 6ª ed. Outubro de 2008.
ROWSTRON, A; DRUSCHEL, P. Pastry: Scalable, distributed object location and routing for large-scale peer-to-peer systems . in PROCEEDINGS OF THE MIDDLEWARE, 2001.
RUBENSTEIN, D.; SAHU, S. Can unstructured P2P protocols survive flash crowds? IN IEEE/ACM TRANSACTIONS ON NETWORKING, v.13, issue 3, p.501-512, 2005.
SRIPANIDKULCHAI K.; MAGGS, B.; ZHANG, H. An analysis of live streaming workloads on the internet. IN PROCEEDINGS OF THE 4TH ACM SIGCOMM CONFERENCE ON INTERNET MEASUREMENT, p.41-54, 2004.
STADING, T.; MANIATIS, P.; BAKER, M. Peer-to-Peer Caching Schemes to Address Flash Crowds. IN REVISED PAPERS FROM THE FIRST INTERNATIONAL WORKSHOP ON PEER-TO-PEER SYSTEMS, Lecture Notes In Computer Science, v.2429, p.203-213, 2002.
75
STAVROU, A.; RUBENSTEIN, D.; SAHU, S. A lightweight, robust P2P system to handle flash crowds . IN IEEE JOURNAL ON SELECTED AREAS IN COMMUNICATIONS, v.22, issue 1, p.6-17, 2004.
STOICA, I. et al. Chord: A scalable peer-to-peer lookup protocol for internet applications. IEEE/ACM TRANSACTIONS ON NETWORKING, v.11, n.1, p.17–32, 2003.
THOUIN, F.; COATES, M. Video-On-Demand Networks: Design Approaches and Future Challenges . In: IEEE NETWORK, v.21, Issue 2, p.42-48, March-April 2007.
Tribler Streaming Explained . 2009. Disponível em http://tribler.org/test_streaming/pub/tribler_streaming_explained.pdf
WALLACH, D. S. A survey of peer-to-peer security issues . IN INTERNATIONAL SYMPOSIUM ON SOFTWARE SECURITY, p.42–57, 2002.
XIE, S. et al. Coolstreaming: Design, theory, and practice . IEEE TRANSACTIONS ON MULTIMEDIA, v.9, issue 8, p.1661-1671, Dec 2007.
YOUTUBE. Site de conteúdo de video disponibilizado por streaming.2009. Disponível em http://www.youtube.com. Acessado em fev 2009.
ZHAO, B. Y. et al. Tapestry: A resilient global-scale overlay for serv ice deployment . IEEE JOURNAL ON SELECTED AREAS IN COMMUNICATIONS, v.22, n.1, p.41-53, Jan 2004.
APÊNDICE A – Código fonte do módulo Bootstrap #!/usr/bin/python import SocketServer,sys,re,time,thread,threading,os,socket,random import struct, fcntl class Interface_ip: def set_interface(self,ifname): self.ifname = ifname def get_ip_address(self): s = socket.socket(socket.AF_INET, socket.SOCK_DGRAM) return socket.inet_ntoa(fcntl.ioctl( s.fileno(), 0x8915, # SIOCGIFADDR struct.pack('256s', self.ifname[:15]) )[20:24]) Mcache = [] class BootStrapHandler(SocketServer.BaseRequestHandler): def PadMsg(msg): while len(msg) < 1024: msg=msg+' ' return msg def server_bind(self): SocketServer.ThreadingTCPServer.server_bind(self) self.socket.setdefaulttimeout(5) self.run = True def setup(self): print 'BootStrap: ',self.client_address, ' conectou' def handle(self): try: global Mcache global McacheNode #Get command Saida=False while Saida!=True: data = self.request.recv(1024) if data.strip() != '': print 'BootStrap Recebeu: ',data.strip() else: pass if data.strip() == 'REGISTER': #Coloco o peer na lista de peers if Mcache.count(self.client_address[0]) <= 0: Mcache.append(str(self.client_address[0])) self.request.send('OK\r\n') else: pass elif data.strip() == 'REMOVE': data = self.request.recv(1024) while data.strip() != 'FINISH': print data.strip() if Mcache.count(data.strip()) > 0: Mcache.remove(data.strip()) else: print 'ERRO' data = self.request.recv(1024) elif data.strip() == 'LIST': McacheNode = Mcache[:] McacheNode.remove(self.client_address[0]) if Mcache.count(self.client_address[0]) >0: if len(McacheNode) <= 5 and len(McacheNode) > 0: for Ip in McacheNode: self.request.send(str(Ip)+'\r\n') elif len(McacheNode) > 5: peerSelect = [] while len(peerSelect) < 5: peerIp = random.choice(McacheNode) print peerIp
77
if peerSelect.count(peerIp) == 0: peerSelect.append(peerIp) for Ip in peerSelect: self.request.send(str(Ip)+'\r\n') else: IpServer = Interface_ip() IpServer.set_interface('eth0') Ip = IpServer.get_ip_address() self.request.send(str(Ip)+'\r\n') else: pass elif data.strip() == 'EXIT': Saida=True elif data.strip() == '': pass else: pass except : self.finish() def finish(self): print 'BootStrap: ',self.client_address,' desconectou' print repr(McacheNode) print repr(Mcache) def open_bootstrap(): SocketServer.ThreadingTCPServer.allow_reuse_address = 1 BootStrapPort = 7187 print 'BootStrap inicializado na porta: ' + str(BootStrapPort) bootstrap = SocketServer.ThreadingTCPServer(('',BootStrapPort), BootStrapHandler) try: bootstrap.serve_forever() except KeyboardInterrupt: sys.exit(0) def Initialize(): thread.start_new_thread(open_bootstrap,()) time.sleep(1) Initialize() while 1:pass
APÊNDICE B – Código fonte do módulo Servidor de flu xo de vídeo from socket import * import sys,struct,time myHost = '' myPort = 50007 param = sys.argv[1:] N_PEER,BUFFER,LOG = param print N_PEER print BUFFER sockobj = socket(AF_INET, SOCK_STREAM) sockobj.bind((myHost, myPort)) sockobj.listen(int(N_PEER)) video = open('/home/zank/Desktop/pes2009.mpg', 'r') log = open('logs/'+LOG+time.strftime('%Y%m%d%H%M%S')+'.txt','w') Saida=False count = 0 lista = [] payload = int(BUFFER)-24 while len(lista) < int(N_PEER): connection, address = sockobj.accept() print 'Server connected by', address data = connection.recv(1024) print data if data.strip() == 'PLAY': lista.append([address,connection]) else: pass while 1: stream = video.read(payload) if len(stream) == 0: break count = count+1 id = str(count) id = id.rjust(24,'0') data = struct.pack('24s'+str(payload)+'s',id,stream) for sock_obj in lista: try: sock_obj[1].send(data) log.write(str(int(id))+';') log.write(str(len(data))+';') log.write(str(sock_obj[0])+';') log.write(time.strftime('%H:%M:%S')+'\r\n') except: lista.remove(sock_obj) log.close() sockobj.close()
APÊNDICE C – Código fonte do módulo Par #!/usr/bin/python import sys,time,socket,struct param = sys.argv[1:] IP,PACKAGE_SIZE,BUFFER,LOG = param Mcache = [] Buffer = [] PACKAGE_SIZE = int(PACKAGE_SIZE) PAYLOAD = PACKAGE_SIZE- 24 log = open(LOG+time.strftime('%Y%m%d%H%M%S')+'.txt','w') class csnode: sNode = socket.socket(socket.AF_INET, socket.SOCK_STREAM) sNode.connect((IP, 50007)) sNode.send('PLAY') while 1: data = sNode.recv(PACKAGE_SIZE) dataRecv = time.strftime('%H:%M:%S') size_recv = len(data) if size_recv == PACKAGE_SIZE: id,chunk = struct.unpack('24s'+str(PAYLOAD)+'s',data) Buffer.append([id,chunk]) log.write(str(int(id))+';') log.write(str(size_recv)+';') log.write('recv'+dataRecv+';') if len(Buffer) > int(BUFFER): ID,CHUNK = Buffer.pop(0) sys.stdout.write(CHUNK) dataRead = time.strftime('%H:%M:%S') log.write('read'+dataRead+';\r\n') else: log.write('pacotePerdido;') log.write(str(size_recv)+';\r\n') break while len(Buffer) >0: ID,CHUNK = Buffer.pop(0) sys.stdout.write(CHUNK) dataReadBuffer = time.strftime('%H:%M:%S') log.write(str(int(ID))+';') log.write('readBuffer'+dataReadBuffer+';\r\n') sNode.close() node = csnode()
![Impact of Topology on Parallel Video Streaming Impacto da Topologia em Transmissões de Video em Paralelo N. Kamiyama[1], R. Kawahara[1], T. Mori[1], S.](https://static.fdocuments.us/doc/165x107/5706384b1a28abb8238f5d55/impact-of-topology-on-parallel-video-streaming-impacto-da-topologia-em-transmissoes.jpg)
