BRPI0001810B1 - Memória cooperativa distribuída para sistema de vod interativo e escalável - Google Patents

Description

Relatório Descritivo da Patente de Invenção "MEMÓRIA COOPERATIVA DISTRIBUÍDA PARA SISTEMA DE VoD INTERATIVO E ESCALÁVEL" CAMPO TÉCNICO

A presente invenção refere-se a um sistema de distribuição eletrônica de video, onde os buffers situados nos clientes são utilizados para oferecer um serviço escalável e com facilidades de operação de videocassete. TÉCNICAS ANTERIORES 0 Serviço de "Video on Demand"(VoD) é uma solução eletrônica para combinar as facilidades de um serviço de videolocadora próximo ao usuário a um equipamento de videocassete, usando para isto uma redé de comunicações de dados de banda larga. Dentre as. vantagens sobre o serviço de videolocadoras tradicionais podemos citar: 1- não existe a necessidade de se ir a locadora para pegar o filme desejado e; 2- sempre se pode assistir o filme desejado, pois não existe a possibilidade de o filme ter sido alugado por outro usuário.

No caso das TVs a cabo e convencionais as vantagens são poder assistir o filme no momento em que se desejar, podendo parar, retroagir ou avançar o filme. Essencialmente, ele é um sistema de videolocadora eletrônico. A arquitetura genérica de um. sistema VoD consiste de 3 partes, conforme a figura 1: Numa ponta está o servidor de VoD 10 onde os filmes são armazenados, no meio a rede de comunicação de dados 20 por onde o fluxo de quadros digitalizados do filme irá transitar e na. outra ponta o cliente 30. O aparelho do cliente pode ser uma TV com caixa de decodificação (similar aos usados pelas TVs a cabo) , um computador pessoal ou uma TV com computador embutido. 0 mecanismo de funcionamento de um sistema VoD é muito simples. 0 cliente solicita eletronicamente o filme escolhido no catálogo da locadora eletrônica , através, por exemplo, de um browser Internet, abrindo uma conexão entre o servidor VoD e seu aparelho. 0 servidor então manda o fluxo de video através da rede para o aparelho do cliente que armazenará os dados em seu buffer até o momento da exibição do filme. Durante a exibição o usuário poderá executar as operações de pause/resume, fast forward o.u rewind, citando apenas as mais utilizadas. Ao acionar estes comandos, eles serão enviados ao servidor que irá providenciar a interrupção do fluxo de video e o seu reinicio no caso de pause/resume ou o envio de quadras futuros ou passados no caso respectivamente de fast forward e rewind. 0 atendimento destas requisições pode ser feito diretamente pelo servidor ou por um módulo especializado neste atendimento. O grande obstáculo para a implantação de sistemas VoD é a falta de escalabilidade destes sistemas. Para cada fluxo de video do servidor é possivel atender apenas um único cliente. Ou seja, se um servidor é capaz de oferecer até 10Q fluxos simultâneos., somente 100 usuários poderão assistir os filmes do servidor, mesmo que o filme seja o mesmo para todos, o que é muito comum, pois as pessoas gostam de ver os filmes em lançamento e no horário que estiverem livres, narmalmente no horário nobre^ Para um milhão de usuários seria necessário um servidor que suportasse um milhão de fluxos simultâneos, o que é economicamente inviável. A questão básica, é escalar o sistema para suportar um grande número de usuários sem precisar crescer a capacidade do servidor linearmente com o número de usuários. Normalmente as soluções propostas escalam o sistema,, mas este deixa de oferecer todas as facilidades de operação de videocassete, por usar não apenas um fluxo por usuário, mas um fluxo multicast. É o que ocorre com as técnicas de Batching, Bridging, Piggybacking que procuram agrupar vários fluxos de video em um único fluxo usando a técnica de multicasting. Uma técnica mais recente de utilização do multicast é o Patching, que ao invés de alocar um canal para toda a duração do filme, aloca apenas alguns minutos, mas usando dois canais, para transmitir dois trechos seguidos de um filme, sendo que enquanto um é exibido, o outro é bufferizado. Terminado a transmissão deste trecho, o servidor tem que alocar mais dois canais para transmitir mais dois trechos do filme. Este esquema dá mais flexibilidade ao sistema, mas todos os fluxos de video continuam saindo de uma única fonte, o servidor.

Para tentar oferecer as operações de videocassete usando multicast com. as técnicas acima mencionadas, aumentou-se o tamanho do buffer no cliente de tal forma que se ele parar e quiser retomar, terá um bom pedaço do filme armazenado localmente, dando um tempo maior para que o servidor possa atender o pedido de play. 0 mesmo acontece para as operações de ff e rw. No entanto a possibilidade de bloqueio é grande, pois o servidor pode estar com todos os recursos ocupados não podendo atender a outras solicitações quando o buffer esvaziar. Uma forma de contornar isto, é sempre manter recursos em reserva no servidor para atender fluxos de emergência, o que nem sempre é suficiente.

Até este ponto ficou claro que toda a pressão de iam. sistema VoD recai, sobre o servidor, que se torna o gargalo do sistema. A solução óbvia, é aumentar a quantidade deles, colocando-os em um só lugar (modelo centralizado) ou distribuindo pela rede, o que aumenta os custos.

Todas estas alternativas mantiveram o foco em aperfeiçoar o servidor para aumentar sua banda passante de saída, aproveitando a possibilidade de se usar o multicast na rede para aumentar o número de usuários por fluxo de vídeo. Para garantir a qualidade do serviço foram acrescentados um buffer em cada ponta da conexão, ou seja, um no servidor para garantir o fluxo que sai do servidor e outra no cliente para permitir a exibição contínua do vídeo sem interrupções devido ao atraso da rede, jitter, retomada após uma pausa, etc.

Todas as soluções anteriormente apresentadas têm como pressuposto uma rede de comunicações de alta velocidade, capaz de suportar a enorme banda passante que o servidor coloca na rede. Estas soluções não se preocuparam em tratar do enlace que liga o servidor à rede de comunicação que também se torna um gargalo. Mesmo que se coloquem vários enlaces de comunicação, estes serão ligados em pontos próximos, o que irá criar um gargalo na rede de comunicações. Mesmo com o uso de multicast, onde o fluxo de saída do servidor atende diversos usuários, a quantidade de fluxos de saída simultâneos é muito grande.

Uma ideia interessante para contornar este problema é encadear os buffers de clientes formando uma linha de retardo. Com este encadeamento aproveita-se melhor o fluxo que vai para o cliente e passa por seu buffer que, ao invés de ser descartado é repassado a algum cliente que esteja necessitando dele. Como este procedimento pode ser repetido indefinidamente, consegue-se formar longas cadeias de buffer dos clientes por onde o fluxo de vídeo passa. Desta forma a quantidade de informação bufferizada no sistema é muito grande e pode ser aproveitada para gerar novos fluxos usando-se o multicast. A inovação proposta, utiliza o espaço de armazenamento dos. buffers. não apenas, como uma linha de retardo, mas como uma área coletiva de memória e permite que esta seja usada de forma cooperativa peLo sistema Video-on-Demand como um todo, para oferecer facilidades de operações de videocassete, sempre de maneira escalável. 0 sistema de VoD resultante terá as seguintes vantagens: 1- proporcionar o início da exibição dos filmes armazenados na memória coletiva logo após a sua escolha, sem grande espera para encher o buffer do cliente ou espera para cair num slot de transmissão de um sistema multicast; 2- oferecer funcionalidades para ff e rw de forma continua em todo o filme e não só no trecho bufferizado, aliviando o servidor da carga de oferecer um fluxo exclusivo para este tipo de operação; 3- ser escalável ao minimizar a ocupação do servidor na transmissão de filmes já existentes na memória coletiva; 4- tolerância a falhas.. com. a disponibilidade de várias cópias de iam mesmo filme na memória coletiva, permitindo que eventuais falhas na rede ou em clientes sejam corrigidas através de fluxos alternativos dos filmes; 5- qualidade de serviço, pois o mecanismo aqui proposto é capaz de se adaptar dinamicamente às variações de tráfego da rede de distribuição, de forma a garantir a qualidade de serviço.

SUMÁRIO DA INVENÇÃO A presente invenção propõe um novo mecanismo para tornar escalável o serviço de video-on-demand interativo, denominado Memória Cooperativa Distribuída (MCD). A principal característica do mecanismo MCD é permitir a implementação de uma forma simples as funcionalidades de um videocassete com um sistema VoD, aliviando o servidor e os enlaces de comunicação do servidor de carga excessiva de forma a tornar o sistema escalável.

Um cliente ao requisitar um filme, antes de começar a assistí-lo, armazena-o no seu buffer. Se algum outro cliente solicitar um trecho de filme que esteja no buffer ou na área do buffer de trabalho de algum cliente, ele não precisa receber um novo fluxo do servidor, o servidor apenas localiza o cliente que possui o trecho do filme e dependendo do estado do buffer ou da operação de videocassete, o fluxo é repassado através deste cliente ou o conteúdo é mandado sob a forma de rajada para o cliente de destino. Isto vale para qualquer operação de videocassete e pode ser, teoricamente, estendido indefinidamente. 0 esquema anterior funciona bem nas horas de pico (prime time) com os filmes populares, onde a quantidade de filme bufferizada nos clientes do sistema é muito grande. Fora do horários de pico ou para filmes com uma menor demanda há necessidade do cliente cooperar não só quando ele obtém vantagens do sistema (poder fazer operações de videocassete quando assiste a um lançamento no horário de pico) mas também para ajudar o sistema (e consequentemente aos demais usuários) a oferecer estas facilidades aos usuários que assistem a filmes de menor demanda no horário de pico ou mesmo estender a quantidade de filme bufferizada na rede fora do horário de pico.

Para isto, o buffer é aumentado para suportar uma área de trabalho do sistema que será utilizada em proveito do sistema e do usuário, que poderá ter serviços de melhqr qualidade a um baixo custo. Este buffer suplementar adicionado ao cliente tem o objetivo de manter bufferizado na rede, os filmes com menor popularidade ou os filmes populares, mas em horários de menor demanda ou ainda auxiliar no mecanismo de formação de cadeias de buffers. Para isto, será usado um mecanismo de gerência de buffers cooperativos, disponibilizando desta forma a maior quantidade de informação armazenada na rede, poupando o servidor e reduzindo substancialmente seu gargalo de comunicação. Além disso, quando o buffer do cliente não estiver sendo utilizado (por exemplo, ele está vendo um filme transmitido via broadcast) eie pode disponihilizar a área total do seu buffer para o sistema VoD, que por sua vez pode oferecer um serviço melhor.

BREVE DESCRIÇÃO DOS DESENHOS

Estes e outros obj ativos, vantagens e características da invenção ficam mais fáceis de se entender e melhor descritas se a seguinte descrição detalhada for lida conjuntamente com as seguintes figuras: FIG-1 Mostra a arquitetura genérica do sistema. FIG.2 Mostra as divisões conceituais do buffer do cliente. FIG.3 Mostra uma derivação do fluxo. FIG.4 Mostra uma cadeia de buffers. FIG.5 Mostra diversas cadeias de buffer de um mesmo filme, sendo que uma delas se desligou do servidor porque o filme acabou. Apesar da cadeia ter se tornado independente do servidor, ela continua existindo e pode ser usada pelo gerenciador MCD.

DESCRIÇÃO DETALHADA DA INVENÇÃO

Um sistema video-on-demand. é constituído de um servidor 10 conforme a figura 1, que armazena os filmes e uma grande quantidade de clientes 30 e. 40 interconectados por um sistema de distribuição de informação 20. O servidor pode ser constituído de um. ou mais processadores, sendo responsável por enviar corretamente os fluxos de vídeo, receber pedidos de novas conexões e de operações de videocassete, atender a estes pedidos da melhor forma possível, divulgar os filmes e serviços oferecidos, tarifar o uso do serviço e, nesta invenção, gerenciar a Memória Cooperativa Distribuída constituída pelos buffers de recepção dos clientes (parte padrão e suplementar) que estão no sistema.. Obviamente estas funções podem ser distribuídas entre diversos computadores e funcionam de maneira harmônica. O cliente é um aparelho capacitado para receber o fluxo de vídeo e exibi-lo ao usuário do serviço. Além disso, ele se comunica com o servidor para solicitar serviços e operações de videocassete. Como a rede de distribuição de informações pode apresentar uma variação na taxa de entregas dos quadros de vídeo, o cliente possui um buffer padrão de recepção 50 conforme a figura 2, doravante denominado apenas buffer, para compensar esta variância. No caso do fluxo de vídeo usar uma taxa de transmissão constante pelo usa de técnicas de "smaothing", o buffer precisa ser maior ainda. Para diminuir o impacto de operações de videocassete sobre o servidor e também dar uma folga para o sistema dar a resposta a algum pedido no tempo adequado, este mesma buffer é aumentado de tamanho. Quanto maior o buffer, maior a folga para compensar a latência do sistema, também maior é α tempa para enchê-lo. Este tempo pode ser reduzido usando-se uma taxa de transmissão maior até que o buffer atinja o seu nivel mínimo de trabalho, só que isto pode sobrecarregar o servidor.

Como ficou claro, todo aparelho cliente, para viabilizar o sistema, deve ter um buffer no qual ele armazena um trecho do filme que está sendo exibido. Ele não armazena todo o filme por possíveis restrições de direitos autorais dos produtores do filme além dos custos envolvidos. Conclusão, o aparelho do cliente precisa de um buffer para usar os serviços do sistema video-on-demand, logo ele também pode compartilhar seu buffer com os outros usuários, afinal isto não vai aumentar os custos do usuário para adquirir um aparelho cliente do sistema além de ter um serviço de melhor qualidade a um mesmo custo. Além disso, ele pode disponibilizar um pequeno buffer suplementar para uso do sistema. Apenas um buffer suplementam pode não resolver os problemas do sistema, mas se somarmos a área de buffer suplementar de todos os usuários do sistema vamos ter uma imensa área de trabalho que o sistema pode aproveitar para, por exemplo, armazenar o trecho inicial dos filmes mais vistos, que assim podem ser carregados rapidamente nos buffers dos clientes que querem assistir este filme, evitando a demora para encher o buffer até o seu nivel mínimo de trabalho. Uma vez que é- possível encadear os buffers e usar o buffer suplementar em proveito do sistema, o desafio neste ponto é como gerenciar estes buffers de forma que eles cooperem entre si de forma eficiente numa rede de distribuição sujeita a imprevistos na transmissão tais como: atrasar ou adiantar o envio de quadros, buffers da cadeia podem sair do ar, além do jitter normal da rede.

ESTRUTURA DE DADOS 0 buffer do cliente é dividido em partes com objetivos administrativos e seus limites são indicados por ponteiros. 0 buffer pode ser implementado de forma circular, evitando a necessidade de se fazer deslocamentos de avanços ou recúos de frames dentro do buffer, apenas movimentos de ponteiros. 0 buffer é dividido em duas partes, a parte padrão e a suplementar. A parte padrão que é que corretamente existe no cliente será chamada apenas de buffer e é descrita a seguir. O primeiro ponteiro indica o inicio do trecho do video armazenado no buffer 51 (fig.2),conforme os quadros de vídeo são descartados o ponteiro é atualizado. 0 segundo ponteiro indica a. posição corrente de leitura 52, que pode coincidir com o ponteiro de início do trecho 51 quando não houver quadros já lidos. Os quadros que estão entre estes dois ponteiros podem ser utilizados para dar uma folga na operação de rewind (recúo do vídeo). 0 terceiro ponteiro indica a posição corrente de escrita 53 dos frames que estão sendo recebidos. A diferença entre os ponteiros de posição corrente de leitura 52 e posição corrente de escrita 53 indica o espaço existente para armazenar os frames necessários para dar uma folga na operação de fast forward (avanço do vídeo). 0 quarto ponteiro indica o nível mínimo de trabalho 56, necessário para garantir que não faltem quadros de leitura devido a atrasos na rede, também para compensar a latência para atender pedidos de fast forward e reinicio de exibição após uma pausa. A distância entre o quarto ponteiro e q ponteiro de pas.ição corrente de leitura 52 é fixo e os dois ponteiros são atualizados simultaneamente. Quando o ponteiro de posição corrente de escrita 53 está abaixo do nível mínimo de trabalho, é gerado uma chamada de falha de vídeo futura que irá contatar o gerenciador da MCD, que irá providenciar um.novo fluxo para recompletar o nível mínimo. 0 quinto ponteiro indica o nível máximo de trabalho 54 e o ponteiro de posição corrente de escrita 53 nunca deve ultrapassá-lo, sob o risco da haver avexflow. A distância entre o quinto ponteiro e o ponteiro de posição corrente de leitura 52 também é fixo, sendo que os dois ponteiros são atualizados simultaneamente. Quando o ponteiro de posição corrente, de escrita. 53 está. acima, do nível máximo de trabalho, é gerado uma chamada de pré-overflow que irá contatar o gerenciador da MCD que irá diminuir a taxa de transmissão para este cliente, ou na impossibilidade disto, providenciar outro fluxo e uma taxa menor a partir do último quadro recebido, ou um outro fluxo após um pequeno intervalo de tempo, o suficiente para esvaziar o buffer abaixo do nivel de pré-overflow e iniciar a transmissão de um fluxo navo ou reciclado. Um fluxo reciclado é aquele que é reaproveitado de algum buffer cooperado. Um fluxo novo é aquele exclusivamente gerado pelo servidor para atender uma requisição. 0 cliente também tem. um. ponteiro que indica o objeto (aparelho ou servidor) que está lhe mandando o fluxo, bem como os objeto (s) (aparelho (s) ) para os quais manda o fluxo transformando a cadeia numa lista encadeada.

Além disso, cada cliente mantém uma tabela 60, sempre atualizada, com os frames que possui no seu buffer e ponteiros para as suas respectivas posições no buffer. A parte suplementar é gerenciada de forma distinta da padrão. Enquanto a política de utilixação da parte padrão dá toda a prioridade para a exibição do filme que o usuário escolheu, na parte suplementar, a política de uso privilegia seu uso em proveito do sistema como um todo, podendo em muitos caao.s ser usado em proveito do cliente que está fornecendo, se isto for interessante para o sistema VoD. A parte suplementar 70 (fig. 2) pode ser usada de forma dinâmica ou estática. Em ambos os casos possui um ponteiro indicando o objeto que o antecede, bem como q(s) objeto(s)que o sucedem gerando uma lista encadeada.

Ela é usada de forma dinâmica quando faz as vezes de um buffer de retardo, para permitir a interligação de duas cadeias separadas por um pequeno, trecho de filme, que não pode ser bufferizado para ser entregue a outra cadeia, que de outra forma teria que buscar este fluxo no servidor. Obviamente este buffer de retardo pode ser aumentado iigando-se os buffers suplementares em cadeia. Coma neate caso ele é só um buffer de retardo, ele possui um indicador de nivel máximo de trabalho 80 (fig. 2) que se atingido, deve fazer com que os quadros a serem enviados o sejam numa taxa maior para esvaziar o buffer. e permitir o armazenamento dos quadros que estão chegando.

Quando se armazena um trecho de filme numa cadeia de buffers suplementares, por exemplo o seu trecho inicial, para ser mandado para outros buffers evitando um "burst" no servidor para encher mais rápido o buffer de destino, está se fazendo o uso desta parte suplementar de forma estática. Estática porque não existe um fluxo passando pela parte suplementar. Como não existe um fluxo, o trecho que está na parte suplementar não é descartado, logo ele pode ser usado para completar o buffer de outro cliente. Este trecho de filme armazenado pode ser replicado em diversas cadeias suplementares de forma distribuída pela rede, diminuindo desta forma o tráfego na rede e aumentando a disponibilidade deste trecho. O gerenciador da MCD mantém 2 tabelas para administrar a parte padrão, uma com informações dos clientes que estão assistindo ao video, uma com a numeração dos frames do video ou uma outra unidade qualquer que indexe os trechos de filmes e os ponteiros para a posição de memória em que eles estão armazenados. 0 filme pode estar todo em memória, primária (RAM), ou em_ secundária (disco rígido) ou parte em primária e parte em secundária.. A tabela de informações do cliente mantém o identificador do cliente, o tamanho do espaço destinado para rawind, o nivel mínima a máximo de_ trabalha da_ parte padrão, isto, é claro, pode ser simplificado e eliminado, se o buffer for padronizado para todos os clientes, mas isto diminui a flexibilidade. Possui também um campo que é um ponteiro para o próximo cliente e para o cliente anterior, para controlar o encadeamento dos buffers e um campo com o quadro inicial e final que está no buffer usado quando o cliente está em pause. Esta tabela mantém também o instante aproximada em_ que o cliente começou a. assistir o filme segundo o relógio do servidor. Existem vários algoritmos de conhecimento público para estimar este tempo, sendo o mais simples, marcar o tempo em que o pedido foi transmitido e ao receber a resposta regiatrar o tampa. A diferença entre estes dois tempos dá o tempo de ida e volta da mensagem, logo dividindo por dois obtém-se o tempo de latência da rede até este cliente. Como o servidor regiatra o tempo em que ele começou a transmitir um fluxo e a quantidade de bytes que ele está transmitindo, ele consegue calcular quando o buffer do cliente atingiu o nível mínimo de trabalho e por conseguinte começou a assistir o filme. Caso o cliente interrompa a exibição do filme por qualquer motivo, ao recomeçar a exibição ele envia uma notificação ao servidor, que registra o tempo da chegada desta notificação e subtrai dele o tempo de transmissão e o tempo de filme já exibido para o cliente, atualizando o tempo de início de visualização do filme. Este tempo agora é um tempo virtual, uma vez que é o tempo em que ele deveria ter começado a assistir o filme para que estivesse visualizando a cena atual. Esta será a referência da tempo utilizado pela servidor para. saber quais frames estão no buffer do cliente. 0 tempo de inicio de visualização do filme é zero se o cliente ainda não começou a visualizar o filme, ou seja, ainda está enchendo o seu buffer para atingir o nível mínimo de trabalho. Esta tabela também armazena o estado da parte suplementar de cada cliente e possui ponteiros que indicam o encadeamento destes suplementos. 0 servidor possui também . listas para. controle, uma lista de suplementos livres, outras com suplementos que armazenam trechos de filmes, outro dos que servem de buffer de retardo, outro com os buffers cujos clientes não estão utilizando o buffer e portanto disponibilizaram, todo ele para proveito do sistema (aumentou a parte suplementar com a área da parte padrão).

FUNCIONAMENTO 0 funcionamento será. explicado usando-se um único filme em um único servidor, uma vez que isto simplifica o entendimento do mecanismo, no entanto, este mecanismo pode ser usado com diversos filmes em um mesmo servidor, um filme em diversos servidores, ou. mesmo diversos filmes em diversos servidores, sendo que estes servidores podem estar num cluster de forma centralizada ou distribuídos pela rede. Além disso, o mecanismo proposto funciona com fluxo de vídeo constante Q.u variável e com quadros de vídeo de tamanho constante ou variável, sendo que vídeo o pode estar comprimido ou não, podendo ser usado com qualquer padrão de compressão de vídeo, tais como, MPEG1, MPGE2 e MJPEG, bem como suportar desde baixa, qualidade de. vídeo, até um. padrão de alta definição como o HDTV, ainda a unidade de gerência aqui descrita como quadro de video pode ser um conjunto de quadros, ou mesmo um hyte do fluxo de video .

Um cliente ao solicitar um video, através do aparelho cliente, envia um. pedido ao gerente M.CD que irá providenciar um fluxo do video do servidor ou da cadeia para α buffer do aparelho cliente. Como não existe outro fluxo deste filme (é o primeiro pedido), e também supondo que não esteja bufferizado nos_ suplementos, quem. vai fornecê-lo é o servidor. Quando o buffer atingir o seu nivel mínimo de trabalho α aparelho inicia a exibição do vídeo. Até este ponto o funcionamento é semelhante aos demais sistemas de video-on-demand. Se o trecho já estiver bufferizado nos suplementos, a carga para atingir o nível mínimo de trabalho pode. ser acelerada, pois cada cadeia de suplementos que possui o referido trecho pode mandar o seu conteúdo em paralelo e o servidor só manda α fluxo do trecho restante, conforme explicado mais adiante.

Ao chegar um novo pedido de video, o gerenciador de MCD consulta a sua tabela com informações do cliente, verifica que existe um cliente cujo bufher possui trecho inicial do filme 120 (fig.3) e estima que seu espaço disponível no buffer para rewind não foi total mente preenchido, podendo inclusive estar vazio se o filme não começou a ser exibido.,, dando portanto tempo para o cliente que pediu o filme 130 (fig.3), receba ordem do gerenciador da MCD, ou simplesmente gerente MCD 100 (fig.3) Λ para se conectar com o aparelho do cliente, que tem o trecho bufferizado e pedir que mande um fluxo de vídeo (raj.ada) do conteúdo de seu buffer. Como o espaço de rewind estava suficientemente vazia, quando o cliente começou a enviar o fluxo, tem-se certeza que nenhum byte do início do filme foi descartado.

Ao fluxo que alimentava o buffer 120 (fig.3) é feita uma derivação multicast para fornecer este fluxo também para o buffer: L3Q (fig. 3) . Esta pracedimento de derivação se aplica também para outros trechos do video e não apenas ao inicio, bem como em qualquer ponto da cadeia, isto é, na figura 3 o servidor 110 pode ser um buffer da cadeia. A verificação de que existe um cliente cujp buffer possui o trecho inicial do filme, é feita da seguinte forma: Primeiro eie verifica se o trecho inicial está bufferizado na parte suplementar, senão ele consulta uma tabela de clientes, ã procura dos que já começaram a receber o fluxo, mas ainda não começaram a ver o filme ou de clientes que já começaram a ver q filme, mas o tempo de iniciação do filme menos o tempo que o relógio do servidor esta marcando, é menor que o tempo de filme arma senado no espaço de rewind, mais o tempo para o outro cliente receber esta informação do servidor, fazer a conexão e α buffer que esta cooperando iniciar o envio do fluxo. Isto é preciso, para que nenhum byte sequer, do primeiro frame seja descartado, antes que o fluxo reaproveitado seja mandado para o destino. Q tempo de fi 1 ms armazenado no espaço de rewind, pode ser obtido da tabela de filmes, uma vez que no tempo (t) o quadro (q.) é quem esta sendo exibido. Soma-se o tamanho dos quadros anteriores o (q) até chegar ao tamanho do espaço de rewind, ou menos que isso se for atingido o inicio do filme. Como os frames são exibidos a uma taxa fixa, basta dividir o número de quadros por esta taxa, para se obter o tempo de filme armazenado no espaço de rewind.

Este procedimento pode ser repetido indefinidamente, gerando uma cadeia de clientes interligados por um. fluxo de video continuo. Como é difícil garantir os atrasos na rede, pode ser que este fluxo continuo, se torne muito baixo em alguns pontos da rede, vindo a esvaziar muito algum buffer e em outros gerando overflow.. Para isto exi.at.em- oa pont.eix.oa de nível mínimo e máximo de trabalho. 0 trecho do filme que está entre estes dois ponteiros, age como um elástico que dá maior flexibilidade ao sistema. Outro problema é a defasagem que pode ocorrer entre o tempo de i n í cio de exibição, armazenado no servidor e o tempo correto, dado pelo tempo atual do filme no cliente menos o tempo real. Como os buffers estão interligados por uma cadeia, se houver erro na designação do buffer, baata xepasaax eate pedida paxa. o huffer anterior ou posterior, caso o trecho pedido esteja atrás ou à frente, respectivamente.

Caso o trecho, inicial esteja armazenado na parte suplementar, é possível diminuir o tempo de espera de enchimento de buffer sem onerar o servidor. Para isso o conteúdo do trecho inicial tem que estar numa seqüê.ncia de suplementos e o filme a. sex enviado, mandado de forma paralela para o buffer destino. Concomitantemente o .fluxo que deve seguir α trecho ini ciaj é providenciado pelo gerente MCD. Caso a demanda deste trecho inicial seja muito grande, esta sequência de suplementos que armazenam o trecho inicial pode estar replicada em diversos pontos da rede. Caso o trecho inicial não esteja, nos suplementos, o gerente MCD localiza o buffer da cadeia que tem o trecho inicial, o seu conteúdo é mandado com uma taxa de transmissão alta para o buffer destino, o fluxo que está saindo do servidor para. o buffer origem, também é mandado para o buffer destino, usando-se multicast. 0 concatenamento do fluxo no buffer destino é simples, o gerenciador de MCD sabe a partir de que ponto o servidor passou. a. fazer multicast para o huffer destino, logo. ele dá ordens para o buffer origem mandar o seu conteúdo até este ponto.

Caso o f 1 uxo. se rompa_ por algum_ motiva, o conteúdo do buffer irá sendo gradualmente consumido pela exibição do video até atingir o seu nivel mínimo. Neste momento, será gerada uma chamada que irá notificar o gerenciador MC D que. providenciará- um. fluxo para eate buffer, vindo de outro buffer ou vindo do servidor. 0 cliente sabe qual o último quadro recebido, logo ele solicita ao MCD o quadro seguinte. Em qualquer caso, o espaço de buffer entre, o ponteiro, de Leitura e o ponteiro de nivel mínimo, deve ser suficiente para armazenar um trecho de vídeo que dure o tempo para notificar o gerente MCD, tratar a notificação e enviar as ordens a todos os elementos envolvidos no estabelecimento ou derivação de um novo fluxo.

Na operação de pause, se o cliente que solicitar for o último de uma cadeia de buffers 240 (fig.4), ele simpLesmente envia uma notificação, ao gerente MCD, que irá ordenar o elemento anterior da cadeia 230 (fig.4), que pare de enviar o fluxo a partir de uma dada posição de memória no buffer. 0 que foi enviado é o suficiente para encher o buffer até o fim do. buffer 55. (.fig^2_) . Se o ciiente for um elemento do meio da cadeia 220 (fig.4), o procedimento é o mesmo, exceto que o elemento do meio da cadeia continua a mandar tudo o que está em seu buffer para o cliente à sua frente 230 (fig.4), dando uma folga de tempo maior para o gerente MCD realizar as ações necessárias para enviar um novo fluxo de vídeo ao 230 (fig.4). 0 cliente informa ao gerente MCD sobre o quadro inicial e final do trecho que está em seu buffer, para que este possa usar este trecho se for necessário.

Quando da operação de resume (reiniciar a exibição), o cliente notifica o gerente MCD e começa a exibir o video. com. o que existe em. seu buffer, dando tempo para o gerente MCD ordenar todas as ações necessárias para mandar um fluxo de video a partir do byte seguinte ao que existe armazenado no buffer do cliente. Este fluxo pode vir de uma. outra, cadeia de bu.fi.era ou pode. ser um. fluxo novo vindo do servidor, caso o trecho pedido não se encontre em alguma cadeia já estabelecida.

Para o servidor não ficar guardando mais um estado, ou seja, o do último, quadro mandado, para o cliente, este manda junto com a notificação de resume o último quadro que está em seu buffer, facilitando o trabalho do gerente MCD. 0 gerente MCD então verifica qual o buffer cliente que pode fornecer um fluxo, a partir daquele quadro. Sabendo o número do quadro é possível calcular o tempo de filme até aquele ponto. De posse desta informação, o gerente MCD consulta a sua tabela de clientes e computa a diferença entre o relógio atuai do computador e o tempo de filme decorrido aproximadamente no espaço de rewind e forward, este último dado pelo nível mínimo de trabalho, que estão na mesma tabela. 0 tempo de filme no espaço de forward acima definido é calculada de forma análoga, ao espaço de rewind anteriormente. calculado.. Ou seja, agora o gerente MCD possui o limite inferior e superior de tempo em que o filme deveria ter começado para possuir tal quadro em seu. buffer. El.e acrescenta um_ tempo, delta ao limite inferior como margem de segurança, para ter certeza que o trecho não foi descartado do buffer. Ao limite superior não é preciso acrescentar uma margem de segurança, pois mais quadros sempre estão chegando. C.om isto, ele procura um cliente que tenha começado a ver o filme com aquele tempo de inicialização e pede que este mande um fluxo para o cliente que notificou o resume. Caso tal cliente não exista, ele cria um novo fluxo a partir do servidor. É importante observar que o conteúdo de um buffer pode ser calculado usando-se a taxa média de transmissão do fluxo, neste caso, divide-se o tamanho do buffer pela taxa média obtendo-se o tempo médio de filme armazenado no buffer ou em qualquer uma de suas subdivisões dados pelos ponteiros anteriormente definidos. Com o tempo de filme armazenado no buffer e o quadro atual exibido pode-se estimar os quadros à frente e à ré armazenado no buffer.

As operações de fast forward e rewind podem ser implementadas de duas. formas: avançando ou recuando até um determinado ponto do filme e exibindo o filme de forma normal a partir deste ponto, avançando qu recuando de forma rápida exibindo o filme a uma velocidade maior para o cliente.

Com MCD é possível implementar as duas políticas. Se for para avançar ou recuar minutos, utilizando-se a taxa média de transmissão do fluxo calcula-se quantos quadros à frente ou à ré é necessário requisitar, mandando o pedido de fast forward/rewind para o gerente MCD. Caso o trecho necessário para encher o buffer esteja numa cadeia de buffers já existente, α buffer do. cliente que está com o trecho manda o trecho numa rajada, o suficiente para encher o buffer de destino e começar a exibição normal e ao mesmo tempo o gerente MCD providencia um fluxo para abastecer este buffer, que pode ser q mesmo que abastece o buffer que mandou a rajada. Caso o trecho necessário não esteja em nenhuma cadeia de buffers, o gerente MCD irá providenciar mais um fluxo do servidor a partir do ponto pedido pelo cliente. Como a latência do servidor é grande, o tempo necessário para atender o pedido pode ser maior. Isto pode ser contornado alocando uma banda passante de emergência no servidor para atender estes casos. Neste caso o servidor manda uma rajada, o suficiente para encher o buffer do cliente e após passa a transmitir normalmente. A. rajada é feita com a banda passante de emergência, que é reservada no servidor para atender casos excepcionais. Como a rajada dura poucos segundos o recurso banda passante de emergência é rapidamente liberado. 0 cliente, neste último caso, em média espera menos para ter seu pedido atendido do que se fizesse esta mesma operação com um videocassete. Isto porque um videocassete normal também possui uma latência para rebobinar o filme até o ponto desejado e se considerarmos que o cliente pode estar no começo do filme e quer avançar até o final do filme, isto pode levar alguns minutos, o que não ocorre usando-se a MCD, pois o acesso não. precisa ser sequencial. É importante ressaltar que a MCD tem um melhor desempenho quando existem várias cadeias de buffers (fig.5), ou seja, ele é mais apropriado para ser usado em filmes muito populares (hot videos) e em horários de pico de utilização do serviço. Isto não quer dizer que ele não possa, ser usado em situações ou filmes de pouca demanda, embora nestes casos a sua influência no desempenho e escalabilidade do sistema seja pouca ou nenhuma.

Para suportar um fast forward/rewind com visualização rápida, da filme, é preciso que o filme esteja na situação descrita no parágrafo anterior, ou seja, ser popular. Se ele não estiver, o servidor é que terá que arcar com o ônus de sustentar uma alta taxa de transmissão, que para isto deve ter uma boa banda passante de reserva. Isto pode ser contornado por uma tarifação diferenciada, inibindo o cliente de usar este recurso em filmes raramente vistos num horário de grande demanda ou só disponibilizar o ff/rw discreto. Caso. haja suplementos não utilizados no sistema, eles também podem ser utilizados para armazenar trechos de filmes com pouca demanda de forma estática, ou seja, ao invés de simplesmente descartar o fluxo, bufferizar os trechos a serem descartados, estendendo os benefícios da MCD para fora do horário de pico e para filmes de menor demanda. Obviamente, caso o sistema precise do espaço suplementar para atividades mais nobres, a prioridade de descarte de conteúdo será o dos que estão armazenando os trechos acima citados.

Para filmes de grande demanda em horários de pico, podem existir diversas, cadeias de buffers distintas, todas de um mesmo filme e de comprimentos diversos, formando uma arborescência (figura 5). Desta forma é possível que todo o filme esteja bufferizado nos buffers dos clientes e que um trecho qualquer pode estar bufferizado diversas vezes em diversas cadeias de buffers (figura 5) . Neste cenário, um fast forward ou rewind é executado buscando-se os trechos do filme a uma velocidade maior nos diversos buffers espalhadas pela rede. À medida que um buffer origem é esvaziado, o gerente MCD já tem outro buffer origem designado para mandar o trecho seguinte do filme a uma alta velocidade e assim sucessivamente até o cliente cessar a. operação ou. o filme chegar ao fim ou começo. Este procedimento pode ser feito sem utilizar uma taxa muito grande de transmissão se o conteúdo dos buffers for transmitido em paralelo para o destino. No caso de um ff numa cadeia de buffers., .... o. buffer seguinte a ser esvaziado é o buffer que está à ré do buffer que está sendo esvaziado e assim sucessivamente até chegar ao servidor, usando para isto, os ponteiros da tabela de clientes que controlam o encadeamento dos buffers.. Neste ponto o gerente MCD procura outro buffer com o trecho seguinte do filme. Como o gerente MCD procura o trecho do filme no buffer já foi explicitado anteriormente. Caso não encontre nenhum buffer com o conteúdo desejado, ele manda o servidor dar rajadas deste conteúdo, avançando o filme até encontrar algum buffer com este conteúdo, mandando a rajada deste buffer então. A política do gerente MCD é sempre que possível, solicitar a cooperação dos buffers padrões e utilizar os suplementos quando esta cooperação não for possível, só em último caso recorrer ao servidor. Caso o cliente pare a operação, para dar um resume, ele já tem bufferizado parte do filme que foi mandado em rajadas curtas (do tamanho do buffer origem) e a operação de resume é igual a operação de resume após uma pausa, Uma outra maneira de se implementar a Memória Cooperativa Distribuída (MCD), é com o uso da abordagem distribuída de gerenciamento. Neste caso, o pedido de um novo fluxo a partir de um quadro (q) do filme, seria mandado em forma de multicast para todos os clientes que fizessem parte de um mesmo grupo, o grupo que esta assistindo a um mesmo filme. Os clientes que possuíssem este quadro informariam ao solicitante e este escolhería um, a partir do qual recebería um fluxo ou uma rajada de vídeo, neste último caso quando for avanço ou recúo rápido com visualização. Caso nenhum cliente tivesse este trecho bufferizado, ou seja, se após um tempo pré determinado ninguém respondesse, o cliente solicitaria um fluxo ou rajada ao servidor, No caso de rajada, cada rajada é suficiente apenas para encher o buffer e novo multicast deve ser lançado para o grupo para verificar se algum cliente possui o trecho seguinte em buffer. Este procedimento visa poupar o servidor. Os clientes sabem os quadros que possuem no buffer porque mantém uma tabela 60 (fig,2)com esta informação.

No entanto, a manutenção de grupos deste tipo é complexa e pode gerar muito tráfego de controle na rede, por isso implementamos um método que aproveita a topologia das cadeias de buffer para evitar requisições seguidas ao gerente MCD, que pode se tornar o gargalo do sistema .

Neste sistema, o cliente é inteligente e pode tomar algumas ações independentemente do gerente MCD, devendo no entanto informar o gerente MCD de seu estado final e os buffers que recebem seu fluxo para que recebam de outra fonte, podendo para isto localizar a fonte apropriada e informar as buffers destinos e o gerente MCD para fins de controle da memória.

Este sistema usa os ponteiros que apontam para o buffer origem e destino para caminhar pela árvore de hulfers (fig.4), sendo que um percurso da raiz. da árvore (servidor ou buffer que está com o último trecho do filme) até a folha é o que convencionamos chamar de cadeia 210,220,230 e 240 (fig.4). Para caminhar pela árvore o cliente manda mensagens pela cadeia usando os. ponteiros (endereços dos clientes à frente ou à ré). Para caminhár adiante um cliente utiliza-se do endereço de seu ponteiro à frente. Para andar dois clientes adiante, utilizando o seu ponteiro de à frente, ele pergunta ao cliente da frente para onde aponta o seu ponteiro à frente e assim ele pode se comunicar com o cliente que está dois enlaces adiante. Este procedimento é repetido até ele chegar ao fim de uma cadeia. O caminho à ré e à frente, obviamente, podem ser conjugados para que o cliente possa andar pela árvore, não só longitudinalmente como transversalmente. A utilização que o cliente faz desta estrutura funciona da seguinte maneira: Pause: se algum buffer depender do seu fluxo, ele anda em direção à raiz, até encontrar um nó que derive um fluxo diferente do daquele que ele veio e caminha em direção a folha, até encontrar um nó que tenha um fluxo de saida próximo ao seu, então ele informa, qs huffers que dependem do seu fluxo para receberem deste novo nó. Caso os fluxos tenham uma pequena defasagem, o buffer que solicitou pause solicita os suplementos necessários ao gerente MCD, o multicast é- ampliado passando, a enviar α fluxo também para a cadeia de suplementos solicitada, que irá enviar o fluxo retardado para os buffers dependentes deste fluxo, que também já estarão prontos para receber este fluxo, avisados pelo buffer que quer fazer pause. O fluxo nunca vai estar atrasado, pois se ele estiver basta andar um nó em direção à raiz e o algoritmo sempre faz esta escolha. Caso o retardo necessário seja muito grande, um novo fluxo poderá ser. estabelecido com o servidor. Outra alternativa é se este procedimento não achar o novo nó nas suas vizinhanças, ou seja, num raio de poucos passos na árvore, solicitar este nó para o gerente MCD, que possui uma tabela com informações dos buffers clientes, isto porque o grau de complexidade deste problema é muito grande, quando se utiliza apenas informações locais, podendo em alguns casos não encontrar a solução, ou seja, depois de muito tempo ele vai descobrir, que o novo nó não existe e portanto o fluxo deve vir do servidor, enquanto o gerente MCD tem esta informação quase que de forma imediata. O objetivo de se utilizar este procedimento distribuído, é evitar sobrecarregar o gerente MCD, s.e. localmente este problema puder ser resolvido e só repassar esta operação quando isto não for possível.

Ao fazer qualquer uma das operações seguintes, o cliente deve providenciar a substituição do fluxo que transmite, como na operação de pause, executando em seguida as operações abaixo.

Fast-forward contínuo: fazer um ff neste esquema é o mesmo que andar pela árvore em direção à raiz, solicitando o conteúdo , dos buffers_. que encontra, pela caminha, que pode ser mandado seqüencialmente com uma taxa de transmissão mais alta ou em paralelo, uma vez que o cliente irá consumir estes dados a uma taxa maior. Como o conteúdo dos buffers varia dinamicamente e a La.tênc.ia da rede varia fazendo com que seja difícil sincronizar os pedidos de envio de forma exata, o buffer que ira receber estes fluxos poderá receber pequenos trechos repetidos que deverão ser descartadas.. Caso. o trecho não. esteja bufferLzada na rede, o gerente MCD providenciará um fluxo de servidor.

Rewind contínuo: o rewind é o contrário do ff, deve-se caminhar pela árvore em direção às folhas, solicitando os trechos dos filmes que estão nestes nós de forma igual ao ff. A dificuldade de se andar em direção às folhas é que existem diversos caminhos, uns mais longos e outros mais curtos, o ideal é pegar o caminho mais longo, ou seja, o caminha que contém mais trechos do filme bufferizados de forma que o cliente possa fazer esta operação de forma contínua no maior espaço de tempo possível. Somente com informações locais a complexidade deste problema é muito grande^ por isso em rewind muito Longos o servidor, que possui as informações de todos os nós, consegue fazer o caminho inverso, isto é, ele descobre o nó que esta no ponto mais perto do início do filme, fazendo uma busca na tabela que pode estar indexada po.r uma lista do filme, anda em direção à raiz até chegar ao nó que solicitou o rewind e envia a informação desta cadeia para o nó poder fazer o rewind. Caso a cadeia esteja interrompida em algum ponto, o servidor é quem . deve fornecer o trecho do filme correspondente à interrupção.

Fast forward, rewind discreto e resume: basta caminhar pela árvore de forma análoga às operações acima descritas até descobrir o buffer. que contém o trecho desejado, diferindo apenas que o conteúdo dos buffers encontrados pelo caminho não precisam ser transmitidos para o nó que está executando a operação, apenas o conteúdo final para encher o buffer destino até o seu nível mínimo de trabalho.

Os mecanismos descritos acima, do jeito que estão se aplicam bem a redes de comunicação com topologias fortemente ligadas, ou seja, praticamente todo mundo se comunica com todo mundo por canais físicos. Só que esta topologia é economicamente inviável. 0 que existe de fato são topologias mais esparsas, que normalmente consiste de uma dorsal de alta capacidade e desta dorsal derivam os enlaces locais até os clientes. Obviamente a dorsal não precisa ser única, podendo ter várias redundâncias para efeito de aumento de desempenho entre pontos críticos e para uma maior confiabilidade da infra-estrutura de comunicação. A capacidade de transmissão da dorsal é limitada, e se comparada à capacidade de transmissão de um comutador local é de cerca de algumas ordens de grandeza menor. Ou seja, construir uma árvore de buffers aleatoriamente pode. facilmente congestionar o backbone, basta sempre colocar buffers vizinhos na árvore em pontos opostos fisicamente na rede. Não que isto seja proibido, mas deve ser minimizado ao máximo. Isto é feito colocando-se ramos inteiros da árvore em um mesmo comutador, ou seja, a comunicação entre estes nós se dá dentro do barramento de comutação, que tem uma topologia muito próxima ou igual a de uma rede fortemente ligada. Para otimizar a construção desta árvore, o MCD .mantém uma tabela em que os clientes estão agrupados segundo a sua proximidade física e a busca de um nó com o trecho requerido é sempre buscado nesta ordem., dos mais próximos para os mais distantes. Esta tabela é imprescindível quando os endereços dos clientes não tiverem nenhuma relação com a sua localização (endereçamento horizontal), como os endereços IP. Se os sistemasL de endereçamento dos clientes ditar a sua localização (endereçamento vertical ou hierárquico) como os endereços telefônicos, o próprio endereço já fornece a informação de localidade, bastando o servidor ter uma tabela de distâncias entre as localidades.

Embora esclarecimentos ilustrativos da presente invenção tenham sido mostrados e descritos, existe a possibilidade de se fazer uma grande quantidade de modificações, mudanças e substituições pelos entendidos na arte e em certas circunstâncias, algumas funcionalidades da invenção podem ser empregadas sem o correspondente uso de outras funcionalidades. Portanto, é preciso que fique claro que os. esclarecimentos à respeito da invenção foram dados como um exemplo de sua utilização e não como uma limitação.

Claims (15)

1- MEMÓRIA COOPERATIVA DISTRIBUÍDA PARA SISTEMA DE VoD INTERATIVO E ESCALÁVEL caracterizado por gerenciar de forma centralizada o conteúdo dos buffers do cliente de um sistema de Video-on-Demand, compreendendo um gerenciador de MCD (Figura 3 - 100) que irá receber requisições e notificações dos clientes, mantendo uma tabela com informações destes clientes para calcular os quadros que estão nos buffers do clientes, um gerenciador de MCD que ao receber um pedido ou notificação irá atualizar a tabela de clientes, clientes que irão cooperar com o gerente MCD, disponibilizando trechos de filme que estão no seu buffer e irão obedecer aos pedidos do gerente MCD para mandar um ou mais fluxos para outros clientes, na velocidade de transmissão e quantidade de quadros especificados pelo gerente MCD, clientes que irão notificar o gerente MCD sempre que alguma operação for realizada e algo de anormal ocorrer, como o nível do buffer estar abaixo (Figura 2 -56) ou acima do nível de trabalho (Figura 2 - 54), clientes que tem sempre disponíveis uma tabela (Figura 2-60) com os quadros que estão em seu buffer e sua posição no buffer, com o objetivo de poder atender aos pedidos do gerente MCD, clientes que irão disponibilizar um buffer suplementar (Figura 2 - 70) para uso do sistema de VoD.

2- "MEMÓRIA COOPERATIVA DISTRIBUÍDA PARA SISTEMA DE VoD INTERATIVO E ESCALÁVEL" caracterizado por um gerenciamento distribuído do conteúdo dos buffers dos clientes de um sistema de Video-on-Demand, compreendendo, um cliente que coopere com o grupo que está assistindo ao mesmo filme enviando requisições de quadros por multicast (Figura 4) quando necessitar, um cliente que coopere com o grupo que está assistindo ao mesmo filme que ao receber requisições de quadros por multicast e o tiver em seu buffer, os envie ao requerente, o uso do multicast dentro do grupo que está assistindo ao mesmo filme, para solicitar um fluxo de video a partir de determinado quadro, o envio deste fluxo por um buffer do cliente.

3- MEMÓRIA COOPERATIVA DISTRIBUÍDA PARA SISTEMA DE VoD INTERATIVO E ESCALÁVEL caracterizado por um gerenciamento distribuído do conteúdo dos buffers dos clientes de um sistema de Vídeo-on-Demand, compreendendo, um cliente que saiba de onde vem o fluxo que ele está recebendo e para onde vai o fluxo que ele está enviando tanto em reação ao buffer padrão (Figura 2 - 50), como ao suplementar (Figura 2 - 70), um cliente que saiba se comunicar com outro cliente, para perguntar para onde ele está mandando o fluxo ou de quem está recebendo o fluxo, um cliente inteligente que utilizando as capacidades descritas anteriormente, saiba caminhar pela árvore de cadeias (Figura 5) , a fim de localizar o trecho necessário à consecução de uma operação, evitando que as operações descritas anteriormente sejam solicitadas ao gerente MCD para que este não fique sobrecarregado, um cliente que ao realizar as operações de videocassete utilizando a árvore de cadeias (Figura 5), mantenha o gerente MCD informado do estado final resultante da operação.

4- MEMÓRIA COOPERATIVA DISTRIBUÍDA PARA SISTEMA DE VoD INTERATIVO E ESCALÁVEL, de acordo com uma das reivindicações de 1 a 3, caracterizado por um acesso rápido a trechos de filme para avanço e recúo rápido, com visualização dos filmes usando-se os buffers dos clientes, compreendendo, envio de trechos do filme necessários a exibição acelerada do filme (rewind ou forward), através de rajadas ou em paralelo enviadas pelos buffers clientes, a forma do gerenciador de MCD descobrir os buffers que possuem os trechos solicitados, qual seja, calculando através do tempo de inicialização do filme os quadros que estão no buffer, utilizando para isto a tabela do filme, para obter o tamanho dos quadros que compõe o trecho do filme que pode caber no buffer do cliente, a forma do gerenciador de MCD descobrir os buffers que possuem os trechos solicitados, qual seja, calculando através do tempo de inicialização do filme os quadros que estão no buffer, utilizando para isto a taxa de transmissão média do fluxo de video, uma maneira rápida de descobrir o buffer seguinte, para mandar a rajada através do uso da cadeia de buffers, ou seja, se um buffer mandou todo o seu conteúdo e o que vem a seguir vem de outro buffer, ele verifica na tabela o buffer seguinte e concatena a transmissão de todas as rajadas ou transmite o seu conteúdo em paralelo, a utilização dos suplementos para armazenar trechos de filmes de forma estática ou dinâmica para fazer acesso rápido.

5- MEMÓRIA COOPERATIVA DISTRIBUÍDA PARA SISTEMA DE VoD INTERATIVO E ESCALÁVEL, de acordo com uma das reivindicações de 1 a 3, caracterizado por permitir a implementação de funcionalidades de videocassete num sistema de Video-on-Demand economicamente escalável, compreendendo um cliente que, no pause, se for último da cadeia, notifique o gerente MCD para que este cesse o fluxo, quando o buffer atingir o seu nível máximo de trabalho e atualize a tabela de clientes, com o frame inicial e final em seu buffer, para que este trecho possa ser utilizado por outros clientes quando necessário, no pause se estiver no meio da cadeia, notificar o gerente MCD para que este providencie um novo fluxo, para o(s) cliente (s) que está (estão) à frente e enquanto o MCD toma providências para isso continuar mandando o que resta no seu buffer para o(s) cliente (s) que está (estão) à frente, no resume, notificar o gerente MCD para que este providencie um fluxo para ele e enquanto isso, ir consumindo o conteúdo do seu buffer, ficar preparado para receber uma rajada com o trecho do filme que falta entre o conteúdo do seu buffer e o fluxo de video que irá receber, no fast forward e rewind, notifique o gerente MCD para que providencie as rajadas com os trechos de filmes necessários para a exibição rápida, no fast forward e rewind sem exibição, notifique o gerente MCD para que este providencie um fluxo a partir do quadro pedido.

6- MEMÓRIA COOPERATIVA DISTRIBUÍDA PARA SISTEMA DE VoD INTERATIVO E ESCALÁVEL, de acordo com uma das reivindicações de 1 a 5, caracterizado por contornar o problema de um buffer da cadeia sair do ar sem avisar, sendo ainda que quando um buffer fica abaixo do seu nível mínimo de trabalho, ele notifica o gerente MCD para que este providencie uma outra fonte de fluxo.

7- MEMÓRIA COOPERATIVA DISTRIBUÍDA PARA SISTEMA DE VoD INTERATIVO E ESCALÁVEL, de acordo com uma das reivindicações de 1 a 5, caracterizado por aumentar a margem de segurança , para garantir a qualidade de apresentação do vídeo sem paradas na exibição, compreendendo que quando um buffer fica abaixo do seu nível mínimo de trabalho, ele notifica o gerente MCD para que este providencie outra fonte de fluxo.

8- MEMÓRIA COOPERATIVA DISTRIBUÍDA PARA SISTEMA DE VoD INTERATIVO E ESCALÁVEL, de acordo com uma das reivindicações de 1 a 5, caracterizado por construir uma árvore de cadeias que minimize o tráfego na dorsal da rede de comunicações, compreendendo uma tabela no gerente MCD com as informações de localidade, um gerente MCD que use as informações de localidade para construir uma árvore que minimize o tráfego pela dorsal.

9- MEMÓRIA COOPERATIVA DISTRIBUÍDA PARA SISTEMA DE VoD INTERATIVO E ESCALÁVEL, de acordo com uma das reivindicações de 1 a 5, caracterizado por servidores distribuídos ou com servidores em clusters.

10- MEMÓRIA COOPERATIVA DISTRIBUÍDA PARA SISTEMA DE VoD INTERATIVO E ESCALÁVEL, de acordo com uma das reivindicações de 1 a 5, caracterizado por usar fluxos distintos para um mesmo trecho de vídeo para cada cliente ou utilizar um único fluxo de vídeo distribuído para vários clientes.

11- MEMÓRIA COOPERATIVA DISTRIBUÍDA PARA SISTEMA DE VoD INTERATIVO E ESCALÁVEL, de acordo com uma das reivindicações de 1 a 5, caracterizado por utilizar fluxos de vídeo com taxa de transmissão constante ou fluxo de vídeo com taxa de transmissão variável.

12- MEMÓRIA COOPERATIVA DISTRIBUÍDA PARA SISTEMA DE VoD INTERATIVO E ESCALÁVEL, de acordo com uma das reivindicações de 1 a 5, caracterizado por utilizar quadros com tamanho constante ou variável.

13- MEMÓRIA COOPERATIVA DISTRIBUÍDA PARA SISTEMA DE VoD INTERATIVO E ESCALÁVEL, de acordo com uma das reivindicações de 1 a 5, caracterizado por usar apenas o buffer padrão ou usar apenas o buffer suplementar.

14- MEMÓRIA COOPERATIVA DISTRIBUÍDA PARA SISTEMA DE VoD INTERATIVO E ESCALÁVEL, de acordo com uma das reivindicações de 1 a 5, caracterizado por usar um fluxo de vídeo comprimido ou sem compressão, protegido por criptografia ou sem proteção criptográfica, podendo usar desde video de baixa qualidade até um padrão de alta definição.

15- MEMÓRIA COOPERATIVA DISTRIBUÍDA PARA SISTEMA DE VoD INTERATIVO E ESCALÁVEL, de acordo com uma das reivindicações de 1 a 5, caracterizado por utilizar como unidade de fluxo de video, um quadro de video, um conjunto de quadros de video, um subquadro de video ou mesmo um byte do fluxo de video.