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

Transcrição

1 Fundação Universidade Federal do Rio Grande Engenharia de Computação Protocolos de Multicast na Camada de Aplicação para Streaming Felipe Lopes Madruga Rio Grande, 1 de Abril de 2008

2 Fundação Universidade Federal do Rio Grande Engenharia de Computação Protocolos de Multicast na Camada de Aplicação para Streaming Felipe Lopes Madruga Trabalho de Conclusão do Curso de Graduação em Engenharia de Computação submetido à avaliação, como requisito parcial à obtenção do título de Engenheiro de Computação. Orientador(a): Prof. Dr. Nelson Lopes Duarte Filho Rio Grande, 1 de Abril de 2008

3 Este trabalho foi analisado e julgado adequado para a obtenção do título de Engenheiro de Computação e aprovado em sua forma nal pelo orientador. Prof. Dr. Nelson Lopes Duarte Filho Banca Examinadora: Prof. Dr. Nelson Lopes Duarte Filho Departamento de Matemática - FURG Prof a. Dr a. Silvia da Silva Costa Botelho Departamento de Física - FURG Prof. MSc. Celso Luiz Lopes Rodrigues Departamento de Matemática - FURG

4 Dedico esse trabalho aos meus pais.

5 Agradecimentos De forma especial, agradeço à minha família por me apoiar em todos os momentos, tornando mais fácil a conquista do diploma de nível superior. Agradeço ao professor Nelson Lopes Duarte Filho pela orientação, paciência e ajuda. O meu aprendizado com ele foi de extrema importância na minha carreira acadêmica. Agradeço também a minha namorada Aline pelo apoio e principalmente pela ajuda nos momentos difíceis. Finalmente, agradeço aos meus poucos, porém muito bons amigos pelos bons momentos que passamos juntos.

6 Conteúdo Lista de Figuras Lista de Tabelas Lista de Abreviaturas Resumo Abstract iii iv v vii viii 1 Introdução 1 2 Streaming Construção de um Sistema de Streaming Qualidade de Serviço Streaming sobre TCP/UDP Transport Control Protocol (TCP) User Datagram Protocol (UDP) Protocolos Especializados Real-Time Streaming Protocol (RTSP) Real-Time Transport Protocol (RTP) Multicast na Camada de Aplicação Alguns Protocolos de Application-Layer Multicast (ALM) YOID Host Multicast Tree Protocol (HMTP) i

7 CONTEÚDO ii Application-Level Multicast Infrastructure (ALMI) NICE Bayeux CAN-Multicast Narada Comparação entre os Protocolos Apresentados O Protótipo Descrição da Proposta Rede Sobreposta Topologia de Controle Topologia de Dados Implementação do Sistema Funcionamento do Protótipo Experimentos Trabalhos Completos Conclusão 30 Bibliograa 32

8 Lista de Figuras 1.1 Possibilidades de entrega de dados Diagrama representando download Diagrama representando streaming Variações no sistema podem interromper a reprodução da mídia Diagrama de tempo em uma transmissão RTSP Modelo de Referência TCP/IP Tipos de árvores de distribuição Modelo de Camadas do NICE Estrutura de um Content-Addressable Network (CAN) Tipos de registros empregados no sistema Exemplo do processo de entrada Camadas do sistema implementado Tela principal do protótipo iii

9 Lista de Tabelas 3.1 Comparação entre protocolos de ALM Comparação entre arcabouços para programação P2P iv

10 Lista de Abreviaturas ALM Application-Layer Multicast ALMI Application-Level Multicast Infrastructure API Application Program Interface CAN Content-Addressable Network FURG Fundação Universidade Federal do Rio Grande HMTP Host Multicast Tree Protocol HTTP HyperText Transfer Protocol ICMP Internet Control Message Protocol IGMP Internet Group Management Protocol IP Internet Protocol ISP Internet Service Provider JMF Java Media Framework JRE Java Runtime Environment LAN Local Area Network MMS Microsoft Media Streaming P2P Peer-to-Peer RDT RealNetworks Data Transport v

11 LISTA DE TABELAS vi RP Rendezvous Point RTCP Real-Time Control Protocol RTP Real-Time Transport Protocol RTSP Real-Time Streaming Protocol RTT Round-Trip Time TCP Transport Control Protocol UDP User Datagram Protocol WWW World Wide Web

12 Resumo O envio de um uxo contínuo de dados (streaming) para um grupo de computadores da Internet de forma eciente é um problema principalmente devido ao fato da funcionalidade de multicast do protocolo Internet Protocol (IP) ser de difícil utilização e pouca disponibilidade. Uma sugestão para solucionar essa questão é realizar tal função em camadas superiores da pilha de protocolos, sendo tal proposta chamada de multicast na camada de aplicação. Essa alternativa utiliza somente o modelo de comunicação unicast do protocolo IP, deixando todas as questões de criação e manutenção dos grupos para a camada de aplicação. Usando esse modelo de comunicação, foram projetados vários protocolos com diversas peculiaridades. A utilização desse paradigma é uma alternativa viável tanto para baratear os custos de grandes empresas que desejem enviar uxos para um grande número de usuários, quanto para usuários ao redor do mundo, que queiram utilizar os computadores domésticos para formar uma grande estrutura de transmissão. Esse trabalho analisa quais protocolos podem ser ecientes em criar um ambiente propício para streaming, bem como as principais características a serem levadas em conta. Além disso, é proposto um modelo de construção de árvores de distribuição usando uma combinação de técnicas, visando maior descentralização e escalabilidade em relação às propostas atuais. Para demonstrar a funcionalidade foi construído um protótipo para publicação de uxos e transmissão de mídia contínua através de um protocolo Application- Layer Multicast (ALM) e de um sistema Peer-to-Peer (P2P). Palavras-chave: Multicast na camada de aplicação, redes sobrepostas, streaming. vii

13 Abstract The delivery of a continuous data ow (streaming) to a group of computers on the Internet eciently is a problem, mainly due to the diculty of use and the limited availability of the multicast funtionality of the IP protocol. One sugestion to solve this issue is to perform such function in upper layers of the protocol stack, and that proposal is called Application-Layer Multicast. This alternative uses only the unicast communication model from the IP protocol, leaving all the concerns about creation and maintenance of groups to the application layer. Many protocols were designed using this communication model, each one with its own peculiarities. The use of this paradigm is a feasible alternative for both minimize the costs of large companies wishing to send streams to a large number of users, and for users around the world, who want to use home computers to form a large structure of transmission. This work examines which protocols can be eective in creating an environment conducive to streaming, as well as the main features to be taken into account. In addition, it proposes a model of building distribution trees using a combination of techniques, seeking greater decentralization and scalability on the today proposals. Intending to demonstrate the functionality, a prototype was built to perform publication and transmission of streams of continuous media through a Application-Layer Multicast (ALM) protocol and a P2P system. Keywords: Application-Layer Multicast, overlay networks, streaming. viii

14 Capítulo 1 Introdução A transmissão de dados como vídeo e áudio consome uma grande largura de banda em relação a um arquivo de texto, uma imagem ou qualquer documento típico da World Wide Web (WWW). O envio dessas mídias contínuas [Lee, 2005] (que possuem embutidos em si restrições de tempo), sendo elas consumidas antes da recepção de sua última parte, é chamado de streaming e geralmente se dá em uma relação de um transmissor para muitos receptores. Quando há muitos clientes em uma transmissão, a técnica de entrega mais indicada é o multicast. Notadamente, a respeito do consumo de largura de banda, o ideal seria a duplicação de pacotes acontecer nos roteadores, para o tráfego gerado ser o menor possível. Entretanto, a infraestrutura atual da Internet não disponibiliza de maneira satisfatória o serviço de entrega a vários receptores com esse modelo de comunicação. Assim, o que acontece na maioria das vezes é um transmissor ter uma comunicação unicast com cada receptor, gerando um gargalo. Uma outra opção é realizar o roteamento e a construção das árvores de distribuição nos hosts nais. O multicast IP, incumbido de implementar essa funcionalidade na camada de rede, ainda não é totalmente habilitado na Internet. A seguir, apresentamos alguns motivos para isso [Diot et al., 2000]. manutenção custosa de controle de grupos; problemas de segurança; localização de endereços pouco escalável; 1

15 CAPÍTULO 1. INTRODUÇÃO 2 robustez, controle de congestionamento, problemas de controle de uxo; disponibilização lenta por parte dos Internet Service Provider (ISP)s. Para tornar o processo de streaming mais escalável, algumas pesquisas sobre multicast direcionaram-se para camadas superiores [Abad et al., 2004]. Nesses métodos todas as funcionalidades de criação e manutenção dos grupos são feitas pelos hosts nais; por isso, eles são chamados de ALM ou end-host multicast. Com essa solução, podemos mais facilmente contornar os problemas do multicast IP. Desse modo, a tarefa de disponibilização ca muito facilitada por não requerer nenhuma modicação na infraestrutura da Internet existente. Segundo o modelo de referência TCP/IP [Tanenbaum, 2003], a camada inter-redes (implementada através do protocolo IP) é responsável por fazer com que os pacotes injetados em uma rede cheguem ao seu destino. Portanto, realizar multicast na camada de aplicação vai de encontro a teoria que fundamentou a criação desse modelo. Existem algumas desvantagens e vantagens nessa abordagem. A diferença essencial entre o multicast IP e o ALM é que a duplicação dos pacotes no último é feita nos hosts nais. Essa duplicação feita nos hosts gera desperdício de largura de banda, atraso e, portanto, uma queda de performance considerável. Uma vantagem é a utilização de recursos como a capacidade de processamento e armazenamento dos computadores responsáveis pelo roteamento. Bons exemplos que tiram proveito disso são os de distribuição de conteúdo multimídia adaptativos (e.g., transcodicação [J. Youn and Sun, 2000] e codicação em camadas [Lee, 2005]). A gura 1.1 retirada de [Chu et al., 2000] ilustra quatro possibilidades de entrega de dados a partir de um transmissor A para os receptores B, C e D, onde R1 e R2 são roteadores. Na gura identicam-se (a) Ambiente do exemplo; (b) Múltiplos uxos unicast a partir do transmissor; (c) Multicast na camada de rede; (d) Multicast na camada de aplicação. Muitos são os serviços de distribuição de vídeo na Internet. O mais popular atualmente é o youtube [Youtube, 2008]. Sistemas como o youtube são chamados de vídeo sob demanda, pois os vídeos são requisitados e, em seguida, enviados. Existem, portanto, restrições diferentes das de um vídeo ao vivo, digamos, da exibição de um jogo de futebol, por exemplo. Essas diferenças são essenciais para a elaboração do arcabouço que torna

16 CAPÍTULO 1. INTRODUÇÃO 3 Figura 1.1: Possibilidades de entrega de dados. possível sua implementação. Aqui levamos em consideração transmissões que não são sob demanda, ou assíncronas. O desao de construir um protocolo de multicast na camada de aplicação eciente para sistemas de streaming, como rádio e televisão pela Internet, é abordado nesse trabalho. Propomos também uma solução que visa atender primordialmente a dois requisitos desses sistemas: escalabilidade e descentralização. No próximo capítulo são apresentados tópicos sobre streaming, os dados geralmente envolvidos e as questões que caracterizam essa categoria de aplicações. No capítulo 3, são abordados os protocolos utilizados para comunicação em grupo em redes sobrepostas e são discutidos exemplos e características. Após, o capítulo 4 se refere ao protótipo decorrente deste trabalho, bem como questões acerca da sua implementação. Finalmente, são feitas considerações nais sobre ALM e o seu futuro, no capítulo 5.

17 Capítulo 2 Streaming Na Internet, há vários tipos de mídia, como imagens, áudio, texto e vídeo. No contexto deste trabalho, é interessante classicar os tipos de mídia em dois grupos [Lee, 2005]: mídia discreta e mídia contínua. Consideremos um cliente utilizando um navegador para abrir uma página que contém uma imagem. Essa imagem será transferida do servidor web para a máquina cliente em um tempo que depende da largura de banda disponível, e então decodicada e apresentada. Embora seja bom minimizar o tempo da transferência, não existe restrição rígida quanto ao tempo que a imagem vai levar pra ser apresentada e, após concluída a apresentação, o processo está terminado. Isso é um exemplo de mídia discreta. Já na mídia contínua, há requerimentos explícitos de tempo embutidos nos dados. Bons exemplos dessa classe de mídia são áudio e vídeo. Esses dados, em muitos casos, são consumidos à medida em que são recebidos; as próximas partes que vão sendo recebidas são essenciais para a integridade da informação e devem estar disponíveis no cliente assim que forem necessárias para apresentação. Desse modo, o tráfego na rede para uma transmissão desse tipo precisa manter certos parâmetros para proporcionar a integridade de tempo. Variações quanto aos tempos de chegada dos dados, e outros parâmetros, são classicados entre quesitos de qualidade de serviço, tópico exposto em uma seção deste capítulo. A relação temporal entre transferência e consumo desse tipo de dados denota a diferença entre download(mídia discreta) e streaming(mídia contínua). A gura 2.1 mostra um diagrama representando um download, e a gura 2.2 mostra o mesmo no caso de um streaming. Obviamente, é possível realizar um download de um arquivo de áudio ou 4

18 CAPÍTULO 2. STREAMING 5 vídeo. Porém, em alguns casos, é melhor consumir os dados enquanto eles são recebidos, reduzindo drasticamente o atraso do início da reprodução. Figura 2.1: Diagrama representando download. Figura 2.2: Diagrama representando streaming. Este trabalho trata da construção de um arcabouço para realizar streaming sobre uma rede sobreposta (overlay). Tendo isso em vista, as próximas seções discorrem a respeito das questões envolvidas com esse tipo de aplicação.

19 CAPÍTULO 2. STREAMING Construção de um Sistema de Streaming Uma das preocupações que devemos ter ao construir um sistema de streaming é que os fragmentos de dados sejam entregues ao cliente a tempo de manter a continuidade da apresentação da mídia. É preciso estabelecer em que momento a reprodução deve iniciar depois que o processo de streaming começou. Uma vez que é iniciada a exposição dos dados, o momento de reprodução de todos os outros fragmentos será xado. Quanto maior for o atraso para o início da reprodução, maior será o tempo para realizar a transferência dos dados. Entretanto, não se pode atrasar demais o início da reprodução, o que é uma métrica importante de desempenho. Além disso, a performance de um sistema de streaming possui diversas variações devidas à performance de cada componente individual do sistema. Os principais fatores que podem causar variações são, no servidor, o processo de compressão de dados, a passagem dos dados comprimidos ao buer de memória do servidor, a preparação dos pacotes e o envio destes. No cliente, a eciência do sistema pode variar principalmente por causa do processo de decodicação. Quaisquer dessas variações podem fazer com que os dados cheguem muito atrasados para a reprodução, ocasionando uma perda da continuidade, conforme é ilustrado na gura 2.3 [Lee, 2005]. Figura 2.3: Variações no sistema podem interromper a reprodução da mídia. Como a mídia contínua geralmente gera uma grande quantidade de dados para armazenamento e transferência, ao projetarmos um sistema de streaming é preciso

20 CAPÍTULO 2. STREAMING 7 conseguir eciência nos seus vários subsistemas para determinar a eciência do serviço como um todo. Atualmente, apesar dos avanços tecnológicos, o custo de servir mídia de alta qualidade (como os emergentes vídeos de alta denição) é ainda bastante substancial. Também é desejável que o sistema seja escalável - que suporte um crescimento em larga escala no número de usuários sem queda exagerada em performance. E que sobreviva a falhas, o que pode ser conseguido introduzindo redundância de hardware e mecanismos de tolerância a falhas. 2.2 Qualidade de Serviço Segundo [Marchese, 2007], do ponto de vista da rede, qualidade de serviço é a habilidade que um elemento de rede (e.g., uma aplicação, um host ou um roteador) tem de ter alguma garantia de que o tráfego e o serviço solicitados satisfarão suas necessidades. Dentre as métricas de qualidade de serviço, podem-se citar 1. taxa de perda de pacotes: tendo em vista que a Internet é interconectada através do protocolo IP, que não provê garantia de entrega, dados transmitidos às vezes não chegam ao destinatário. Por exemplo, um roteador com a la de chegada congestionada pode simplesmente descartar os pacotes que chegam. Esse quesito está relacionado a isso. 2. throughput (largura de banda): reete a quantidade de dados que a rede é capaz de entregar durante um intervalo de tempo. Uma maior largura de banda normalmente causa melhoras em outros parâmetros de qualidade de serviço. 3. taxas de erros de pacotes: mede a taxa de pacotes que chegam no receptor com inconsistências, assim denotando problemas de transmissão. 4. jitter: é a variação do atraso entre os pacotes. É alto quando, em uma seqüência de pacotes enviados, o intervalo de chegada varia muito. 5. atraso: dimensiona o tempo que os pacotes levam desde a saída do transmissor até a chegada no receptor.

21 CAPÍTULO 2. STREAMING 8 6. skew: trata-se de um parâmetro exclusivo das transmissões de multimídia, que é a disparidade das taxas de uxos diferentes que compõe o mesmo objeto a ser reproduzido. Um exemplo é quando um vídeo com áudio está sendo transmitido e o áudio está chegando corretamente, porém o vídeo está atrasado. É evidente que cada tipo de aplicação possui suas restrições e é sensível a quesitos diferentes. Conforme discutido na seção anterior, as aplicações de streaming são sensíveis a todas as citadas. Entretanto, pouco atraso não é muito importante para transmissões sob demanda e é essencial para transmissões ao vivo. Atualmente, na Internet, no caso do protocolo IPv4, não se utilizam os mecanismos que proveriam garantia de qualidade de serviço, por uma série de razões. Desse modo, essas métricas podem ser medidas ou estimadas, geralmente sem haver qualquer garantia por parte dos ISPs. A largura de banda, para usuários comuns com conexão ADSL, por exemplo, não é garantida devido aos algoritmos empregados, havendo cobranças de grandes taxas para se obter tal garantia. 2.3 Streaming sobre TCP/UDP Nesta seção, trataremos sobre o uso dos protocolos de Internet existentes para aplicações de streaming. A camada de transporte utilizada na Internet suporta o TCP e o UDP, principalmente TCP Como o TCP já possui controle de erro, de uxo e de congestionamento embutidos, o desenvolvimento de uma aplicação de streaming para esse protocolo ca um tanto simples. O TCP protege a aplicação das complexidades de gerenciar o tráfego pela Internet. O streaming sobre HTTP/TCP tem muitas vantagens óbvias: o provedor de serviços não precisará investir em caros servidores de mídia especializados; a sua operação é simplicada, visto que o tráfego é tratado da mesma forma que o tráfego da WWW (assim, ele passa de forma transparente por rewalls e gateways); o amplo suporte para HTTP aumenta a compatibilidade com as aplicações do cliente. Contudo, a desvantagem

22 CAPÍTULO 2. STREAMING 9 do streaming HTTP/TCP é a performance. Ao nível da aplicação, o servidor não está projetado para entregar dados de maneira sensível ao tempo. Portanto, se ele estiver sobrecarregado, pode não conseguir sustentar uma reprodução de mídia suave, estável. No nível do transporte, as características do TCP foram desenvolvidas para aplicações genéricas. Não há suporte para aplicações com sensibilidade de tempo e de largura de banda, como é o caso do streaming de mídia. Além do mais, o mecanismo de controle do TCP força a entrega dos dados sem erros (incorrendo em retransmissões de pacotes) e na seqüência exata em que foram enviados. Conseqüentemente, se o dado retransmitido chegar depois do momento correto da reprodução, tornar-se-á inútil e será descartado pelo receptor. Para piorar, o algoritmo de controle de congestionamento do TCP interpretará a perda de pacote como um indício de congestionamento na rede e então diminuirá sua taxa de transmissão como meio de reduzir a janela de congestionamento. Essa diminuição afetará o streaming de mídia, atrasando a transmissão dos dados, podendo fazer com que eles cheguem após o momento em que são necessários para a exibição UDP O UDP, por outro lado, não sofre dos problemas do TCP. É um protocolo mais simples, que transfere datagramas sem controle de uxo, de congestionamento ou de erro. Por isso, o UDP não introduz atraso adicional como o TCP. Dessa forma, o UDP se torna adequado para transmissão de dados de mídia sensível ao tempo. Entretanto, no streaming de mídia, às vezes é necessário fazer um controle de uxo para reagir ao congestionamento da rede e às perdas de pacotes. A questão é que, quando estão sendo utilizadas essas funções, os requerimentos de tempo e largura de banda da mídia devem ser levados em conta. Isso pode ser feito construindo-se uma outra camada com um protocolo de streaming acima do UDP, onde o protocolo de streaming cuida das questões especícas e o UDP só é usado para entregar mensagens de controle e os dados.

23 CAPÍTULO 2. STREAMING Protocolos Especializados Ao longo dos anos, inúmeros protocolos de streaming foram desenvolvidos tanto para companhias comerciais quanto para a comunidade da Internet. Exemplos de alguns protocolos proprietários desenvolvidos são o Microsoft Media Streaming (MMS) e o RealNetworks Data Transport (RDT). O MMS usa o TCP/IP para troca de mensagens de controle e pode enviar dados de mídia sobre UDP ou TCP. A comunidade da Internet desenvolveu protocolos para streaming de forma aberta. Fazem parte desses protocolos o RTSP e o RTP, sobre os quais as subseções seguintes discorrem RTSP O RTSP é um protocolo da camada de aplicação desenvolvido para controlar a transmissão de dados de mídia (por exemplo, play, pause e seek) com informação de tempo embutida, bem como áudio e vídeo. Como é independente do protocolo da camada inferior, o RTSP pode ser transportado sobre TCP, UDP ou outros protocolos de transporte. A sintaxe do RTSP tem muita semelhança com HTTP/1.1, simplicando a implementação e organização; todavia, difere do HTTP em muitos aspectos importantes. Diferentemente do HTTP, o RTSP é um protocolo ciente do estado, requerendo ao host a manutenção da informação do estado da sessão de streaming através de múltiplas solicitações RTSP. Outra diferença é que ambos servidor RTSP e cliente podem emitir requisições RTSP. Por último, os dados de mídia são entregues fora da banda, isto é, usando um protocolo separado, como o RTP. Em uma aplicação típica de streaming, o cliente primeiro obterá um arquivo de apresentação de descrição (por exemplo, através da web usando HTTP) - ver a gura 2.4. Esse arquivo descreve uma ou mais apresentações, cada uma composta de um ou mais uxos de mídia sincronizados. O arquivo de apresentação de descrição também contém propriedades dos uxos de mídia, como formato de codicação, para possibilitar que o cliente selecione e prepare a reprodução da mídia. Cada uxo de mídia controlável é identicado por um URL RTSP separado, que é similar ao URL HTTP que identica o servidor que está hospedando o uxo de mídia e o caminho lógico identicando o uxo

24 CAPÍTULO 2. STREAMING 11 de mídia. Figura 2.4: Diagrama de tempo em uma transmissão RTSP RTP O RTP foi projetado para transportar dados em aplicações de tempo real como áudio e videoconferências. O protocolo foi projetado para ser independente do protocolo da camada inferior, o qual basicamente transporta os pacotes RTP. Na Internet, os pacotes RTP são freqüentemente transportados sobre datagramas UDP, que provêem multiplexação de uxos RTP no mesmo host (usando diferentes números de portas UDP para diferentes uxos). O RTP também suporta transporte de dados sobre redes unicast e multicast. Um protocolo de controle - RTP Control Protocol (RTCP) - é denido como parte do padrão para prover funções de controle como sincronização, relatório de estatísticas de recepção, monitoramento de participantes, entre outros. Vale notar que RTP/RTCP sozinhos não provêem controle de qualidade de serviço/garantia ou realizam alocação de recursos de rede. Os protocolos foram projetados para dar o arcabouço necessário, como os campos de cabeçalho (números seqüenciais,

25 CAPÍTULO 2. STREAMING 12 identicação de payload, etc.) no RTCP, para os desenvolvedores implementarem seus próprios mecanismos de qualidade de serviço, que provavelmente são especícos da rede e da aplicação em questão. Comumente os protocolos RTP/RTCP são extendidos e integrados às aplicações ao invés de existirem como protocolos de transporte de propósito geral como o UDP e o TCP.

26 Capítulo 3 Multicast na Camada de Aplicação A maioria das redes de computadores, visando a diminuição da complexidade de projeto, é estruturada de modo a possuir várias camadas ou níveis [Tanenbaum, 2003] com funções bem denidas. O modelo de referência que indica a hierarquia de protocolos da Internet é o TCP/IP (vide gura 3.1). As funções da camada Internet ou inter-redes, implementadas através dos protocolos IP, Internet Group Management Protocol (IGMP) e Internet Control Message Protocol (ICMP), são endereçamento, roteamento, controle de envio e recepção. Contudo, as transmissões do tipo um-para-muitos ou multicast através da camada inter-redes não é sucientemente habilitada na Internet devido a vários motivos [Diot et al., 2000]. Assim, muitas pesquisas estão voltadas para a implementação dessa funcionalidade na camada de aplicação, chamando-se essa alternativa de multicast na camada de aplicação - ALM. Em [Lao et al., 2005] encontra-se uma discussão sobre em que camada a função de multicast deve ser implementada. Figura 3.1: Modelo de Referência TCP/IP. Há uma série de vantagens em realizar esse serviço nos hosts nais ao invés de 13

27 CAPÍTULO 3. MULTICAST NA CAMADA DE APLICAÇÃO 14 nos roteadores. Entre elas estão a utilização da capacidade de processamento e de armazenamento muito maiores. Outro fator signicativo é que, de acordo com os argumentos de sistemas m-a-m [Saltzer et al., 1984], funcionalidades mais complexas devem ser implementadas em camadas superiores. Isso se justica porque são mais difíceis de serem feitas em camadas mais baixas, e serviços complexos implementados em camadas inferiores e usados por poucas aplicações trazem queda de desempenho, até naquelas que não usam o serviço. Muitas são as propostas para esse tipo de protocolo [Francis, 2000], [Pendarakis et al., 2001], [Zhang et al., 2002], [Banerjee et al., 2002], [Castro et al., 2002b], [Zhuang et al., 2001], [Ratnasamy et al., 2001] e [Chu et al., 2000]. 3.1 Alguns Protocolos de ALM As propostas de ALM até hoje implementadas caracterizam-se por organizar os membros dos grupos em duas topologias: topologia de controle e topologia de dados. A topologia de controle trata de reparar as partições de grupo que acontecem de modo "ingrato"(quando um nó sai de um grupo sem informar através de mensagens de controle). Já a topologia de dados indica o caminho e todas as questões acerca de como um pacote sai do transmissor e chega a todos os componentes do grupo. Existem vários trabalhos no sentido de comparar os protocolos que implementam ALM [Li and Shin, 2002], [Banerjee and Bhattacharjee, 2002], [El-Sayed, 2004]. A classicação mais encontrada chama de árvore-primeiro as propostas que denem a topologia de dados antes da topologia de controle e malha-primeiro as que fazem o inverso. Ainda existem muitas abordagens alternativas às anteriores, chamadas implícitas. Além disso, na grande maioria dos protocolos ALM existe a gura chamada Rendezvous Point (RP) (que pode ser traduzido como "ponto de encontro"), cuja função normalmente é coordenar o mecanismo de entrada de novos nós no sistema. As árvores de distribuição utilizadas em algoritmos de multicast podem ser classicadas como árvores compartilhadas: são aquelas em que qualquer nó pode enviar mensagens através com o objetivo de alcançar os outros nós. árvores de fonte especíca: a árvore é formulada de modo que a raiz sempre

28 CAPÍTULO 3. MULTICAST NA CAMADA DE APLICAÇÃO 15 seja a mesma, ou seja, os dados sempre partem de um dado nó e somente dele. Vamos considerar o seguinte exemplo, um grupo multicast com os nós X, Y e Z como receptores, sendo X e Z transmissores também. O painel 1 da gura 3.2 mostra como seria uma árvore compartilhada pelos membros do grupo. Já o painel 2, apresenta como seriam as duas árvores de fonte especíca para as transmissões tendo X e Z como transmissores. Figura 3.2: Tipos de árvores de distribuição. Nas próximas subseções são expostos alguns exemplos com uma breve descrição de seu funcionamento. E, no m desta seção, há uma breve comparação entre eles YOID O protocolo Yoid [Francis, 2000] cria, em primeiro lugar, a árvore de distribuição dos dados, exercendo controle direto sobre a escolha de membros vizinhos na árvore e grau de saída dos nós. Esse controle contrasta com a abordagem chamada de malha-primeiro, que possui um controle indireto sobre esses aspectos. Nos esquemas em que a topologia de dados é construída primeiro, é criada uma árvore compartilhada, e cada nó entrante deve procurar o seu pai dentre os nós já pertencentes à árvore. Cada nó da árvore tem um grau de saída limite que restringe o número de lhos que ele pode ter. No processo de entrada, o futuro membro do grupo consulta o RP e recebe em troca uma lista de participantes do grupo. Um componente do grupo é um possível pai caso ele 1. seja escolhido como pai por algum critério relevante, não cause a formação de um laço na árvore (isso se refere ao caso de um nó que está entrando novamente na árvore e já possui lhos);

29 CAPÍTULO 3. MULTICAST NA CAMADA DE APLICAÇÃO possa ter mais um lho sem exceder o seu limite de grau de saída. Se nenhum possível pai é obtido na lista, em [Francis, 2000] são mostradas algumas propostas para achar outro pai em potencial. No caso de serem encontrados mais de um pai em potencial, o melhor, segundo alguma métrica, será o escolhido. O Yoid é um conjunto de protocolos para distribuição de conteúdo muito geral. Por ser uma proposta tão abrangente e tentando resolver tantos aspectos, não há necessidade descrevê-lo por completo. Alguns autores [El-Sayed, 2004] chegam a armar que seu interesse é histórico HMTP Em [Zhang et al., 2002], é proposto o HMTP, um protocolo do tipo árvore-primeiro que se assemelha em alguns aspectos ao Yoid. A entrada de um nó na árvore compartilhada segue a seguinte sequência de passos: 1. Descobrir a raiz da árvore consultando o RP; 2. Começando pela raiz, percorrer cada nível da árvore procurando um possível pai que esteja próximo de si. Caso encontre um nó próximo mas que não seja um possível pai, passa ao próximo nível e continua a procurar. Esse processo faz com que a árvore de distribuição tenda a car balanceada por altura. Além disso, o atraso médio em relação à saída dos pacotes da raiz ca propenso a ser menor. A especicação indica que os participantes do grupo mantêm informações sobre os membros no caminho deles até a raiz. Dessa forma, periodicamente eles tentam achar um pai melhor na árvore, reiniciando o processo de entrada a partir de um nó aleatoriamente escolhido. O problema da formação de laços é tratado com um algoritmo distribuído de detecção de laços ao invés de evitá-los. Esse protocolo não cria explicitamente uma malha. Entretanto, de tempos em tempos, os componentes apanham informações sobre outros integrantes do grupo. Esse conhecimento diminui o problema do único ponto de falha causado pela necessidade do RP e ajuda a recuperação devido a partições.

30 CAPÍTULO 3. MULTICAST NA CAMADA DE APLICAÇÃO ALMI Um protocolo totalmente centralizado proposto é o ALMI [Pendarakis et al., 2001]. Nesse protocolo, um programa executado em um lugar acessível por todos os membros grupo controla a sessão de multicast. Pode-se armar que o sistema é composto de um controlador de sessão e de múltiplos membros da sessão. Os participantes das seções são organizados em uma árvore compartilhada para a troca de dados, enquanto mensagens de controle são trocadas entre cada membro e o controlador da sessão. As árvores de distribuição são construídas pelo controlador, sendo elas formadas com base em medições feitas por alguns membros e enviadas ao controlador, como Round-Trip Time (RTT), por exemplo NICE O protocolo NICE [Banerjee et al., 2002] foi desenvolvido visando aplicações onde as transmissões de dados sejam com baixo consumo de largura de banda e para um grande conjunto de destinatários. A topologia de controle é constituída de maneria a tomar uma forma hierárquica, o que dene implicitamente o caminho de dados para um grupo de maneira escalável. A hierarquia é essencial para a escalabilidade, visto que os membros da camada mais baixa (a maioria dos membros) mantêm informações sobre o estado de um número constante de nós, e os das superiores, de O(logN) membros. As informações sobre os nós vizinhos são detalhadas, enquanto as que dizem respeito aos outros nós do grupo são limitadas. A criação da hierarquia é feita atribuindo membros a diferentes camadas, conforme ilustrado na gura 3.3 [Banerjee et al., 2002]. Os nós de cada camada são divididos em clusters. Cada cluster tem um líder. Todos os nós pertencem à camada mais baixa, e os líderes pertencem também à camada imediatamente superior àquela onde ele é líder de um cluster. Essas denições fazem com que as topologias de dados em um cluster sejam sempre em estrela, criando um gargalo em uma aplicação que requer alta largura de banda. A localização dos nós dentro dos grupos da hierarquia é feita considerando como métrica de distância o atraso entre os hosts. Assim, os nós mais próximos se encontram

31 CAPÍTULO 3. MULTICAST NA CAMADA DE APLICAÇÃO 18 Figura 3.3: Modelo de Camadas do NICE. na mesma parte da hierarquia, fazendo com que as árvores de distribuição tenham um menor atraso médio Bayeux O esquema de multicast na camada de aplicação chamado Bayeux [Zhuang et al., 2001] é estruturado em cima de um sistema de busca para redes P2P chamado Tapestry. O roteamento de mensagens é todo feito pelo sistema Tapestry. Portanto, são utilizados os seus algoritmos. Cada nó possui um identicador e consigo uma tabela para mapeamento de mensagens baseada nos identicadores dos nós. Mesmo sem entrar em detalhes sobre a transmissão de uma mensagem, ca claro que uma mensagem destinada a um nó pode passar por uma série de nós que não estão interessados em recebê-la. Assim, para atividades que utilizam alta largura de banda, como streaming, esse sistema é inadequado CAN-Multicast Conforme o mostrado em [Ratnasamy et al., 2000], uma rede endereçável por conteúdo (CAN) é uma rede overlay que implementa uma tabela de hash distribuída sobre uma rede geogracamente distribuída, como a Internet. O CAN baseia-se na construção de um espaço n-dimensional, onde cada host toma conta de uma porção de mesma dimensão. Para exemplicar, consideremos um exemplo bidimensional no painel 0 da gura 3.4, retirada de [Li and Shin, 2002]. Em [Ratnasamy et al., 2001] é formulada uma proposta de ALM usando a estrutura do CAN. A topologia de dados é formada intuitivamente de acordo com a localização

32 CAPÍTULO 3. MULTICAST NA CAMADA DE APLICAÇÃO 19 Figura 3.4: Estrutura de um CAN. dos nós no sistema de coordenadas, conforme é exposto no painel 1 da gura 3.4, ou seja, cada nó é responsável por distribuir mensagens para os seus vizinhos. As duplicações de pacotes são evitadas com uma cache de pacotes já enviados. O procedimento de entrada é ilustrado nos painéis 2 e 3 da gura 3.4. O nó Z (nó que deseja entrar no CAN) consulta o RP para achar pelo menos um nó que já é membro (nó Y). O nó Z procura um ponto aleatório no espaço de coordenadas através do nó X. O dono desse espaço (nó Y) divide-o em dois. Uma das metades passa a pertencer ao nó Y, e a outra, ao nó Z Narada Sendo um dos pioneiros na tarefa de realizar multicast nos hosts nais, o protocolo Narada [Chu et al., 2000] é um protocolo do tipo malha-primeiro. Quando um nó quer se tornar um membro da malha, ele obtém uma lista dos nós que já fazem parte da rede com o RP - que mantém informações sobre o estado de todos os membros que entraram no grupo. Então, o nó seleciona aleatoriamente um subconjunto desses nós e tenta se tornar vizinho deles, sendo bem sucedido quando pelo menos um o aceita como vizinho. Depois de começar a fazer parte da malha, o membros passam a trocar mensagens de manutenção e atualização. Quando um membro entra ou sai do grupo, a informação é propagada ao longo da malha. Assim, cada membro possui informações sobre todos aqueles que compõem o grupo. O número de mensagens de controle é dado por uma função que pertence a O(N 2 ), onde N é o número de participantes do grupo. Isso faz com que o protocolo Narada seja pouco eciente para grupos grandes. Para a construção da árvore de abrangência ao longo do grafo, os hosts executam um

33 CAPÍTULO 3. MULTICAST NA CAMADA DE APLICAÇÃO 20 protocolo de roteamento achando os caminhos unicast. Assim, o caminho de entrega de dados e sua qualidade dependem da qualidade das arestas (links) da malha. 3.2 Comparação entre os Protocolos Apresentados A respeito dos protocolos brevemente discutidos, foi formulada a tabela 3.2. A tabela mostra alguns quesitos relevantes no que se refere a protocolos de multicast na camada de aplicação, e principalmente ao tratado neste trabalho. Protocolo Tipo Árvore Comp. do Grau de Saída Caminho Máximo ALMI centralizado compartilhada ilimitado limitado NARADA malha-primeiro fonte especíca ilimitado ilimitado Bayeux malha-primeiro fonte especíca O(logN) O(logN) CAN-Multicast malha-primeiro fonte especíca O(dN 1/d ) constante HMTP/Yoid árvore-primeiro compartilhada ilimitado O(maxgrau) NICE árvore-primeiro fonte especíca O(logN) O(logN) Tabela 3.1: Comparação entre protocolos de ALM. Alguns dos protocolos acima citados não satisfazem os requisitos para realizar tarefas de grande consumo de largura de banda. Porém, isso é evidente, tendo em vista que muitos deles não foram projetados visando tal atividade. De acordo com as características de cada um deles, pode-se decidir se ele é apropriado ou não para determinada tarefa. Entretando, apesar do protocolo HMTP ser de árvore compartilhada, o que não é um fator desejado em um sistema de streaming com uma fonte especíca, fazendo da raiz a única fonte de dados, ele se mostra mais eciente que os demais citados em uma série de características [Proença, 2006]. O controle do grau de saída dos nós e do mecanismo de entrada na árvore de distribuição é fator indispensável para o tipo de aplicação tratado nesse trabalho.

34 Capítulo 4 O Protótipo Levando em consideração as pesquisas realizadas, propõe-se uma solução para o problema de realizar streaming sobre uma rede overlay usando um protocolo ALM. Além de criar uma solução que combina uma série de técnicas, foi projetado um protótipo que traz à tona questões de implementação de um sistema distribuído e demonstra satisfatoriamente a funcionalidade deste tipo de aplicação. O presente capítulo discorre a respeito da proposta e de sua materialização através da elaboração de um sistema distribuído. Também são discutidos alguns trabalhos de cunho semelhante ao abordado neste documento. 4.1 Descrição da Proposta As idéias principais da proposta são a solução de forma descentralizada de algumas questões e a utilização de tecnologias P2P presentes em redes de compartilhamento de arquivos. Os hosts do sistema utilizam uma rede P2P para buscar uxos que estejam disponíveis e participantes de alguma árvore de distribuição, de forma semelhante ao feito em [Jiang et al., 2003]. O sistema serve somente para a busca e registro dos uxos e participantes, respondendo assim pelas funções normalmente desempenhadas pelo RP, mas indo além ao publicar os uxos e servir como mecanismo de busca por estes. Em [Proença, 2006], é mostrado através de experimentos que o protocolo HMTP tem muitos aspectos positivos. Entretanto, o processo de entrada com busca de um pai próximo por nível é extremamente lento para grupos muito grandes. A construção da topologia 21

35 CAPÍTULO 4. O PROTÓTIPO 22 de dados proposta aqui é mais escalável, pois as medições de atraso são feitas para um número constante de hosts, só que não alcança necessariamente uma árvore tão boa como a referente a topologia de dados do HMTP Rede Sobreposta O sistema proposto é construído sobre uma rede sobreposta que possua pelo menos estas funcionalidades: inserção e remoção de registros (uxos publicados ou usuários que estão participando recebendo alguma transmissão) e busca de ambos tipos de registro. Toda a formulação é feita independente de como essa camada de software é implementada. Os registros são dos formatos expostos na gura 4.1. O painel 1 da gura mostra os registros referentes aos uxos, sendo ele composto por uma cadeia de caracteres identicando o uxo, um identicador global e um registro de usuário referente à raiz da árvore. Aquele tipo de registro referente a usuário que não é raiz, mostrado no painel 2, tem um campo com o identicador do uxo ao qual ele pertence, o nível da árvore ao qual ele pertence, o número de uxos que ele ainda está disposto a prover, e outro com seu endereço IP e uma porta para ser usada na topologia de controle. Figura 4.1: Tipos de registros empregados no sistema Topologia de Controle Esta parte do programa cuida das questões de manutenção e recuperação da estrutura que torna o processo de streaming possível. Dentre as funções desempenhadas aqui, podese mencionar a recuperação da árvore quando um nó sai do sistema, detecção de falhas

36 CAPÍTULO 4. O PROTÓTIPO 23 de participantes do sistema e descobrimento de laços na árvore quando um host entra novamente no sistema. Descobrimento de Falhas Os nós considerados vizinhos são o pai e os lhos de cada nó, ou seja, cada nó tem informações somente sobre esses nós. Para detectar falhas, os vizinhos trocam mensagens conhecidas como "batidas de coração", que servem somente para vericar o estado dos vizinhos. Eventualmente, se algum nó não estiver respondendo, seu registro é removido do banco de registros, para manter a consistência. Esse mecanismo poderia não ser necessário, no caso das transmissões serem orientadas a conexões, pois assim as falhas provavelmente seriam detectadas no nível de transporte. Porém, podem existir casos em que falhas não sejam descobertas assim. Uma grande parte da árvore pode falhar ou sair de maneira ingrata (sem executar os procedimentos necessários) simultaneamente, por exemplo. Para esses casos, quando um nó tenta conectar-se a ele e não consegue, no processo de entrada, ele pode informar ao sistema que cuida dos registros a falha do membro que estava inacessível. Detecção de Laços Escolheu-se não realizar a prevenção de formação de laços. Assim, periodicamente e sempre que algum nó entra no sistema pela segunda vez possuindo algum lho, é efetuada a vericação dos caminhos da árvore. A vericação é feita enviando-se uma mensagem com um número aleatório ao longo da árvore. Quando essa mensagem passa pelos nós eles a armazenam em uma tabela por um certo tempo e sempre antes de armazenar eles vericam se já não a tinham recebido. No caso de possuírem esse número na tabela, eles param de propagar a mensagem e repetem o processo de entrada. Nas vericações periódicas, essa mensagem parte da raiz da árvore e, quando é feita a vericação por reinserção na árvore, parte do nó entrante.

37 CAPÍTULO 4. O PROTÓTIPO Topologia de Dados O processo de entrada na árvore de distribuição é feito após pesquisas na rede sobreposta. Para melhor compreensão, o algoritmo de entrada é exibido a seguir como uma seqüência de passos. 1. O nó entrante realiza uma consulta para descobrir o identicador global do uxo ao qual ele pretende participar; 2. A partir deste identicador, ele obtém uma lista dos k membros mais altos da árvore e os ordena de acordo com a sua altura na árvore; 3. Seguindo essa ordem, são feitas medições de atraso m a m; 4. Caso seja vericado um valor de atraso em relação a algum host abaixo de uma constante determinada previamente, esse é escolhido como pai; 5. Se dentre os k nós da lista obtida nenhum tiver um atraso menor do que o valor estabelecido, o mais próximo, segundo essa métrica, é selecionado como pai; 6. No caso da tentativa de entrada falhar (por uma inconsistência nos registros, por exemplo), o processo se repete. Vamos considerar o exemplo a seguir (gura 4.2), onde o nó Z quer entrar na árvore (painel 1). Primeiro ele resgata uma lista com os quatro nós mais altos da árvore com uxos disponíveis (C, D, E e X), mostrado no painel 2, e realiza medições de atraso com eles (painel 3). O nó X é o escolhido por ter um atraso em relação a Z menor do que os outros. Finalmente, o nó Z tenta se tornar lho do nó X e obtém sucesso (painel 4). Diferente do HMTP, o algoritmo de entrada não é executado periodicamente para melhorar as qualidades da árvore. Em uma transmissão de uxo, isso poderia acarretar em perda na qualidade da reprodução. Desse modo, esse novo chamamento da função de entrada só é feito no caso de falha ou saída do nó pai, ou de algum nó no caminho até a raiz da árvore de distribuição.

38 CAPÍTULO 4. O PROTÓTIPO 25 Figura 4.2: Exemplo do processo de entrada. 4.2 Implementação do Sistema A implementação da proposta para o cliente pode ser apresentada por um diagrama em camadas, ilustrado na gura 4.3. Na gura, o nome "Mecanismo de Busca"se refere à escolha feita para juntar as informações a respeito dos nós e recuperá-las. Para a camada mais inferior, que dá suporte às buscas descentralizadas, existem muitos arcabouços disponibilizados para realizar essas funções sem se preocupar com os detalhes de sua programação. Dentre vários, podemos citar como relevantes [Francesquini and Reverbel, 2007]: JXTA [Gong, 2002]: O projeto JXTA é uma estrutura criada para suportar aplicações P2P usando Java. Compõe-se de um conjunto de protocolos abertos que habilitam dispositivos conectados para se comunicar e colaborar. Promete realizar buscas de hosts e recursos em redes diferentes e prover comunicação segura entre eles. FreePastry [Castro et al., 2002a]: trata-se de uma implementação livre do sistema Pastry [Rowstron and Druschel, 2001] com a intenção de disponibilizar

39 CAPÍTULO 4. O PROTÓTIPO 26 Figura 4.3: Camadas do sistema implementado. aplicações na Internet. O Pastry foi desenvolvido para trazer um esquema de busca distribuída de objetos escalável para sistemas P2P. Bamboo [Bamboo, 2008]: é uma estrutura para construção de aplicações P2P que utiliza tabelas de hash distribuídas para tratar inserção, remoção e recuperação de pares chave-valor. As tabelas de hash desse tipo mapeiam colaborativamente pares chave-valor. A tabela 4.2, retirada de [Francesquini and Reverbel, 2007], visa mostrar os recursos que essas estruturas de programação oferecem. JXTA FreePastry Bamboo Troca de Mensagens Busca Exata Busca Aproximada Comunicação em Grupo Armazenamento Distribuído Autenticação de Usuários Tabela 4.1: Comparação entre arcabouços para programação P2P. Apesar da utilização desses sistemas ser viável, resolveu-se implementar o arcabouço por questões de aprendizado. Fez-se um mecanismo de indexação central no estilo daquele

40 CAPÍTULO 4. O PROTÓTIPO 27 envolvido no pioneiro Napster [Yang and Garcia-Molina, 2001]. Os algoritmos que concebem a topologia de controle, assim como o mecanismo de busca, foram desenvolvidos utilizando programação de Sockets em Java. Para todo o desenvolvimento que lidou com mídia, foi utilizado um Application Program Interface (API) chamado Java Media Framework (JMF). Esse API foi desenvolvido pela Sun MicroSystems em conjunto com a IBM para conceder muitas funções relativas a áudio e vídeo [Microsystems, 2008]. Entre essas funções estão codicação, decodicação, transcodicação, multiplexação, demultiplexação, captação dos dados de dispositivos e serviços de streaming. A topologia de dados foi desenvolvida a partir das funções do JMF que implementam o protocolo RTP. As simulações foram feitas somente com arquivos de áudio sendo transmitidos. No entanto, o sistema foi desenvolvido de forma que, com poucas modicações, as transmissões possam envolver mais de um uxo, como uma transmissão de um vídeo que utiliza normalmente um canal de vídeo e um de áudio. Essa mudança, assim como a mudança do sistema de busca, é facilmente realizável devido à construção em camadas e utilizando uma abordagem orientada a objetos. Além disso, utilizar Java tornou o sistema multi-plataforma, bastando a instalação do Java Runtime Environment (JRE) e JMF para o sistema operacional desejado. 4.3 Funcionamento do Protótipo Visando demonstrar as funcionalidades implementadas, nesta seção é exibida a interface gráca (ilustrada na gura 4.4) e são explicadas as funções desempenhadas pelos componentes grácos. A seguir, são descritas as funções dos botões. Buscar: Faz uma busca no sistema P2P e exibe o resultado na tabela para que o usuário possa selecioná-lo a m de participar da transmissão. Participar: Esse botão faz com que o usuário execute o procedimento de entrada na árvore de distribuição do uxo selecionado. Deixar Grupo: Realiza o procedimento de saída do grupo. Fazendo com que seus lhos tenham de chamar novamente o procedimento de entrada.

41 CAPÍTULO 4. O PROTÓTIPO 28 Iniciar Transmissão: Com este botão é possível cadastrar um uxo no sistema. Esse uxo pode ser tanto um arquivo de áudio com uma codicação suportada pelo JMF instalado na máquina, quanto a captação de um microfone. Figura 4.4: Tela principal do protótipo. 4.4 Experimentos Com a intenção de testar e analisar o funcionamento do protótipo, foram feitos alguns experimentos. Para executar os experimentos, utilizou-se dois ambientes: um envolvendo cinco computadores em uma Local Area Network (LAN) e outro com três computadores conectados através da Internet, cada um com capacidades de acesso diferentes em relação à largura de banda. Nos dois ambientes, o protótipo funcionou sem trazer perdas na qualidade do áudio recebido, usando-se diferentes congurações nas árvores de distribuição. Os algoritmos de controle foram testados separadamente. Assim, puderam ser feitos testes com várias instâncias de um programa no mesmo computador. Isso pode ser feito pois a topologia de controle não depende muito das questões relacionadas ao atraso e à largura de banda, que devem ser levados em consideração nos testes relacionados à topologia de dados. Os resultados foram satisfatórios quanto a recuperação de falhas e na detecção de laços.