BRPI0621786A2

BRPI0621786A2 - solicitação de conteúdo entre parcerias com desempenho monitorado

Info

Publication number: BRPI0621786A2
Application number: BRPI0621786-9A
Authority: BR
Inventors: Yang Guo; Saurabh Mathur; Kumar Ramaswamy
Original assignee: Thomson Licensing
Priority date: 2006-06-27
Filing date: 2006-06-27
Publication date: 2011-12-20
Also published as: JP5140666B2; KR20090029741A; CN101480050A; WO2008002295A1; EP2039158A4; US20090177792A1; US8838823B2; EP2039158B1; CN101480050B; JP2009543182A; EP2039158A1; KR101359081B1

Abstract

SOLICìTAçãO DE CONTEúDO ENTRE PARCERIAS COM DESEMPENHO MONITORADO. Descreve-se um método que inclui o recebimento de um sub-clipe com conteúdo principal encadeado, determinando-se um conjunto de sub-clipes com conteúdo procurado, localizando-se um sub-clipe daquele conjunto de sub-clipes com conteúdo procurado e descarregando-se o sub-clipe com conteúdo localizado. Descreve-se um sistema para o fornecimento de solicitação de conteúdo apresentando uma parceria, um servidor e um rastreador. O rastreador podendo se co-localizar com o servidor. A parceria inclui mecanismo para o recebimento de um sub-clipe com conteúdo principal encadeado, mecanismo para a determinação de um conjunto de sub-clipes com conteúdo procurado, mecanismo para a loca- lização de um sub-clipe do conjunto de sub-clipes com conteúdo procurado e mecanismo para o descarregamento do sub-clipe com conteúdo localizado.

Description

"SOLICITAÇÃO EM VÍDEO ENTRE PARCERIAS COM DESEMPENHO MONITO- RADO"

CAMPO DA INVENÇÃO

A presente invenção refere-se a uma rede de trabalho entre parcerias, e em particu- lar, ao fornecimento de serviços de solicitação em vídeo fazendo uso de uma rede de traba- lho entre parcerias que proporciona o descarregamento de vídeo entre parcerias (descarre- gamento de vídeo/dados por parcerias em uma rede de trabalho entre parcerias) levando em conta o desempenho do sistema.

ANTECEDENTES DA INVENÇÃO

Tradicionalmente, o modelo de serviço de servidor/cliente tem sido empregado para o fornecimento de encadeamento de serviço. Um cliente envia uma requisição a um servi- dor, que então, encadeia o conteúdo ao cliente, caso o servidor apresente recursos suficien- tes para executar o que foi requerido pelo cliente, e em havendo uma largura de faixa exten- sa o suficiente ao longo do trajeto entre o servidor e o cliente.

Devido ao recurso de armazenagem e computação limitado no servidor, e a limita- ção de largura de faixa na rede de trabalho conectando o servidor e clientes, a capacidade de escala tem sido uma questão a resolver referente ao encadeamento de serviços entre servidor-cliente. Recentemente, técnicas entre parcerias têm sido introduzidas junto ao en- cadeamento de serviço. Parcerias são implementadas com condições para a capacitação de clientes e servidores, contribuindo no alívio da carga de trabalho imposta ao servidor, e distribuindo as requisições quanto à largura de faixa através da rede de trabalho armaze- nando temporariamente, de forma ativa, o conteúdo e disponibilizando-o junto a outras par- cerias. Estudos têm demonstrado que técnicas entre parcerias melhoram grandemente a capacidade de escala, viabilizando que o sistema venha a servir muito mais usuários.

Têm ocorrido esforços significativos para se endereçar a questão referente à capa- cidade de escala presente no encadeamento do serviço de mídia fazendo uso de uma rede de trabalho entre parcerias. Esses esforços podem ser classificados em duas categorias, basicamente, encadeamento em tempo real entre parcerias e encadeamento armazenado em vídeo ou por solicitações em vídeo entre parcerias. Enquanto ambos serviços almejam fornecer suporte a um amplo número de usuários fazendo uso da tecnologia entre parcerias, enquanto que oferecendo aos usuários boa qualidade visual, eles se deparam com diferen- tes desafios técnicos. No encadeamento em tempo real entre parcerias, o desafio tem sido a minimização do retardo de inicialização sem se sacrificar a capacidade de escala do sis- tema. No serviço de solicitação em vídeo entre parcerias, o desafio compreende se possibili- tar o compartilhamento para usuários sem sincronização.

Esquemas de encadeamento entre parcerias também se distinguem através de di- ferentes técnicas para disseminação de dados. Dois métodos de disseminação de dados têm sido investigados - basicamente, a abordagem com base escalonada e abordagem co- mandada por dados. Na abordagem com base escalonada, as parcerias compõem uma ma- lha ou uma estrutura em cadeia aonde as relações tipo fonte-filiação são constituídas ao longo das parcerias. Uma parceria filiada recebe dados a partir de sua parceria fonte. Em contraste, as parcerias numa abordagem comandada por dados não tem fixadas as relações fonte-filiação. As parcerias buscam pelo dado que está faltando, e recuperam o dado ausen- te aonde este se encontre disponível. Enquanto que uma abordagem com base escalonada é utilizada de maneira ampla em esforços recentes entre parcerias, a abordagem comanda- da por dados está se tornando mais popular, uma vez que ele endereça a questão, quanto à falta de simetria e comportamento aleatório do problema para a largura de faixa, de uma forma mais efetiva.

Enquanto a maior parte dos esforços da técnica anterior exibe uma boa capacidade de escala e apresenta condições de suporte para um número maior de usuários em compa- ração com o modelo de serviço tradicional entre cliente/servidor, os esquemas do estado anterior da técnica apresentam seu melhor desempenho a nível básico, uma vez que as condições para desempenho de suporte do sistema ainda não foram plenamente estudadas.

SUMÁRIO DA INVENÇÃO

A presente invenção é direcionada em sentido a um serviço de solicitação em ví- deo entre parcerias com desempenho monitorado. A presente invenção incorpora o descar- regamento entre parcerias junto a um modelo de serviço tradicional de solicitação em vídeo entre servidor-cliente. O descarregamento entre parcerias leva a termo a carga principal de transferência de dados e, dessa forma, reduz de maneira significativa a carga de trabalho imposta ao servidor. O servidor destina a maior parte de seus recursos no provimento de dados urgentes visando atender o requisito por desempenho Percebe-se que o desempenho junto ao cliente na outra extremidade é melhorado. O algoritmo de descarregamento entre parcerias é projetado com o requisito por desempenho em mente.

O serviço de solicitação em vídeo possibilita aos usuários a seleção e observação do conteúdo do vídeo através de uma rede de trabalho sempre que assim o desejarem. A presente invenção inclui um modelo de compartilhamento de vídeo entre parcerias segmen- tado que viabiliza o compartilhamento do conteúdo em um cenário de solicitação em vídeo. A questão do desempenho é endereçada através da incorporação de um algoritmo para descarregamento de dados entre parcerias com desempenho monitorado e com encadea- mento complementar assistido pelo servidor, que de modo coletivo executa um desempenho semelhante ao desempenho oferecido pelo modelo de serviço de servidor - cliente tradicio- nal, mas oferecendo suporte para mais clientes e requisições.

O método e sistema da presente invenção são direcionados em sentido a um servi- ço de solicitação em vídeo entre parcerias fazendo uso de uma abordagem comandada por dados e incorporando um algoritmo de agendamento em tempo real junto ao processo de disseminação de dados entre parcerias melhorando a experiência de visualização do usuá- rio. Deve ser observado que o desempenho do sistema, em particular, o recebimento opor- tuno do vídeo solicitado pelo usuário, significa que a experiência genérica de visualização do usuário é melhorada e a qualidade de vídeo de um modo geral é melhorada. O encadea- mento complementar do servidor e o compartilhamento de dados com desempenho monito- rado do sistema da presente invenção melhora a qualidade de visualização junto ao clien- te/usuário na outra extremidade.

Descreve-se um método para fornecimento de serviço de solicitação em vídeo in- cluindo o recebimento de um sub-clipe de vídeo à frente do encadeamento, determinando um conjunto de sub-clipes de vídeo procurados, localizando aquele sub-clipe de vídeo que é o procurado do conjunto e fazendo o descarregamento do sub-clipe de vídeo localizado. Um sistema para o fornecimento de solicitação em vídeo. Um sistema de fornecimento de solici- tação em vídeo é descrito apresentando uma parceria, um servidor e um rastreador. O ras- treador pode ser co-localizado com o servidor. A parceria inclui mecanismos para recebi- mento de um sub-clipe de vídeo principal encadeado, mecanismos para determinação de um conjunto de sub-clipes de vídeo procurados, mecanismos para a localização um daque- les sub-clipes procurados do conjunto e mecanismo para descarregamento do sub-clipe de vídeo localizado.

BREVE DESCRIÇÃO DOS DESENHOS

A presente invenção é mais bem compreendida através da descrição detalhada a seguir quando lida em conjunto com os desenhos de acompanhamento. Os desenhos inclu- em as figuras a seguir, descritas de forma sucinta abaixo com os números nas figuras re- presentando elementos semelhantes:

A Figura 1 compreende de um diagrama esquemático de uma rede de trabalho en- tre parcerias de acordo com a presente invenção.

A Figura 2 compreende de um diagrama mostrando uma rede de trabalho entre parcerias de acordo com a presente invenção.

A Figura 3 compreende de um fluxograma do processo de controle de admissão a partir do lado do servidor.

A Figura 4 compreende de um fluxograma detalhando o processo de controle de admissão a partir do lado do usuário/cliente.

DESCRIÇÃO DETALHADA DAS MODALIDADES PREFERIDAS

Usuários do serviço de solicitação em vídeo observam diferentes porções do vídeo em qualquer dado momento. De forma a viabilizar o compartilhamento do conteúdo entre usuários e se maximizar a quantidade do conteúdo que é fornecido através de uma rede de trabalho entre parcerias, assume-se que cada usuário possua a capacidade de armazena- gem para armazenamento temporário de uma cópia parcial e/ou completa do conteúdo que tenha sido reproduzido. Esta é uma consideração razoável dado ao rápido aumento da ca- pacidade de armazenagem dos dispositivos de reprodução em vídeo. Deve-se observar que um dispositivo de reprodução de vídeo compreende de qualquer dispositivo capaz de rece- ber e reproduzir de novo o vídeo (armazenado ou em tempo real) incluindo, mas não se limi- tando, aos computadores, laptops, assistentes digitais pessoais (PDAs) e serviços móveis. Uma rede de trabalho entre parcerias não se encontra limitada a uma rede de trabalho co- nectada por fio e pode compreender de uma rede trabalho conectada por fio ou sem fio ou uma rede de trabalho híbrida fazendo emprego tanto das conexões com e sem fio.

No método e aparelhagem de solicitação em vídeo entre parcerias segmentadas da presente invenção, um clipe de vídeo é dividido em segmentos múltiplos de iguais compri- mentos, denominados de sub-clipes. O tempo de reprodução do início do sub-clipe é defini- do como o prazo limite deste sub-clipe. Os sub-clipes principais são encadeados junto ao dispositivo de reprodução de vídeo de modo que os usuários possam inicializar a reprodu- ção de modo imediato. É estabelecida uma rede de trabalho entre parcerias entre usuários de forma a se pré-buscar os dados dos sub-clipes posteriores. De acordo com o esquema de monitoração do desempenho do sistema da presente invenção, o dado de um sub-clipe tem de ser pré-buscado antes de seu prazo limite. Uma vez que a reprodução de um sub- clipe tenha se iniciado, não se permite o descarregamento entre parcerias daquele sub- clipe, uma vez que o dado recém descarregado pode ser desatualizado. O encadeamento complementar a partir do servidor original é iniciado a partir deste ponto em diante para um melhor desempenho do sistema. O encadeamento complementar é descrito abaixo.

Utiliza-se um exemplo para se ilustrar como a solicitação em vídeo entre parcerias segmentadas da presente invenção presta serviço as requisições que chegam. Neste e- xemplo, assume-se que os usuários sejam capazes de armazenarem temporariamente toda a cópia do vídeo. A mesma técnica se aplica mesmo se somente uma porção da cópia de vídeo é armazenada na memória temporariamente. Assume-se ainda que o servidor somen- te encadeia o primeiro sub-clipe e os dados dos sub-clipes seguintes são descarregados fazendo-se uso da rede de trabalho entre parcerias. O algoritmo para se computar o número de sub-clipes encadeados será apresentado e descrito abaixo.

Com referência agora a Figura 1, o usuário/cliente 1 procede a uma solicita- ção/requisição por vídeo a partir do servidor no tempo ti. Imediatamente, o servidor enca- deia o sub-clipe 1 (o primeiro sub-clipe de vídeo) junto ao cliente 1, de forma que o cliente 1 possa prontamente dar início a reprodução. Simultaneamente, é feita uma tentativa de se localizar uma parceria, apresentando/armazenando temporariamente, o sub-clipe 2 no inte- rior da rede de trabalho entre parcerias. Neste momento, a única parceria na rede de traba- lho entre parcerias, apresentando/armazenando temporariamente o sub-clipe 2 é o servidor, que pode se comportar como uma parceria. Tanto o cliente 1 como o servidor (pelo menos) são membros da rede de trabalho entre parcerias. No tempo t2, o cliente 1 encontra-se re- produzindo de novo o sub-clipe 1, enquanto que o sub-clipe 2 é descarregado (não encade- ado) a partir do servidor. O usuário/cliente 2 executa uma solicitação/requisição pelo mesmo vídeo a partir do servidor, e dá início imediato a reprodução do sub-clipe 1, que foi encadea- do a partir do servidor ao cliente 2. Tanto o servidor como o cliente 1 dão início ao descarre- gamento (não encadeado) do sub-clipe 2 junto ao cliente 2. Neste momento, o servidor, o cliente 1, e o cliente 2 são parcerias na rede de trabalho entre parcerias. No tempo t3, o cli- ente 3 faz uma solicitação/requisição pelo mesmo vídeo a partir do servidor e dá início ime- diato a reprodução do sub-clipe 1, que foi encadeado a partir do servidor. Nesta oportunida- de, o cliente 1 está reproduzindo de novo o sub-clipe 3, descarregando os dados/vídeo do sub-clipe 4. O cliente 2 está reproduzindo o sub-clipe 2 e descarregando o sub-clipe 3. Nes- ta altura, o servidor, o cliente 1, o cliente 2 e o cliente 3 (pelo menos) apresentam-se como membros da rede de trabalho entre parcerias. O cliente 3 pode descarregar o sub-clipe 2 a partir do servidor, do cliente 1, e do cliente 2. Conforme o tempo vá passando, a reprodução do vídeo de parceria prossegue. O descarregamento entre parcerias pré-busca os dados do sub-clipe que se seguem ao sub-clipe sendo presentemente reproduzido, conforme mostra- do na Figura 1 com o tempo corrente U- No tempo t5, o cliente 1 terá já terminado a reprodu- ção do vídeo e deixado o sistema. O cliente 2 irá reproduzir de novo o último sub-clipe e o cliente 3 irá reproduzir de novo o sub-clipe 4 e descarregar o sub-clipe 5. O servidor e o se- gundo cliente são parcerias na rede de trabalho entre parcerias para finalidades de descar- regamento do sub-clipe 5. Finalmente, o cliente 2 terá deixado também o sistema após a conclusão da reprodução do vídeo. O cliente 3 encontra-se assistindo/reproduzido o sub- clipe 5 e irá deixar o sistema ao final do sub-clipe 5.

A Figura 2 compreende um diagrama mostrando uma rede de trabalho entre parce- rias de acordo com a presente invenção. O servidor 205 possui toda a cópia do vídeo e po- de encadear os sub-clipes ou comportar-se como uma parceria e descarregar os sub-clipes junto as outras parcerias 210 na rede de trabalho entre parcerias. Uma vez que uma parce- ria 210 faça a solicitação/requisição de vídeo a partir do servidor 205, esta já terá se unido a rede de trabalho entre parcerias e poderá então descarregar os sub-clipes posteriores das outras parcerias 210 e/ou descarregar os sub-clipes junto a outras parcerias 210. Os sub- clipes são encadeados somente a partir do servidor 205. Normalmente, somente os sub- clipes principais são encadeados a partir do servidor 205 para uma parceria 210 solicitan- do/requisitando vídeo, com os sub-clipes restantes sendo descarregados do servidor 205 ou de outra parceria 210. Caso, contudo, a taxa de descarregamento não seja suficiente para a parceria receber o sub-clipe descarregado antes do prazo limite, então, é possível se enca- dear um sub-clipe posterior a partir do servidor para a parceria. O rastreador 215 pode ser implementado na forma de uma entidade em separado ou pode ser implementado como parte do servidor 205. Caso o rastreador 215 seja implementado na forma de uma entidade separada, então, ocorre a sinalização entre o servidor 205 e o rastreador 215, que mantém a monitoração das parcerias na rede de trabalho entre parcerias conforme elas se unam e deixem a rede de trabalho entre parcerias. O rastreador monitora também quais parcerias na rede de trabalho entre parcerias que tenham descarregado os sub-clipes e a condição atual das várias parcerias ( se uma parceria possui sub-clipes que estejam disponíveis para descarregamento através de uma outra parceria e quais sub-clipes são necessários de se- rem descarregados por cada parceria). Uma vez que uma parceria tenha recebido um sub- clipe, o sub-clipe é interpretado como estando disponível para descarregamento através daquela parceria para outras parcerias que estejam necessitando daquele sub-clipe. As li- nhas de direção de fluxo com setas duplas indicam o descarregamento do sub-clipe. As li- nhas de fluxo com setas simples indicam o encadeamento do sub-clipe (somente o servidor podendo ser encadeado). As linhas de fluxo sombreadas/pontilhadas indicam a sinalização.

A Figura 3 compreende um fluxograma do processo de controle de admissão a par- tir do lado do servidor. Uma nova solicitação/requisição por vídeo é feita ao servidor. Medi- ante a chegada de nova requisição no servidor, o processo de controle de admissão 305 é convocado e atua com base nos dados estatísticos acumulados. Caso a requisição seja admitida em 310, computa-se em 315, o número de sub-clipes principais que deverão ser encadeados, diretamente, a partir do servidor. Denomina-se como Ν, o número de sub- clipes encadeados (principais). O servidor dá início ao encadeamento dos principais sub- clipes para requisição junto ao cliente/usuário em 320 e, retorna o valor de N junto à requisi- ção de usuário/cliente em 325. Caso a solicitação/requisição não seja admitida, o número de sub-clipes principais é inicializado/restaurado em 330.

A Figura 4 compreende um fluxograma detalhando o processo de controle de ad- missão a partir do lado do usuário/cliente. No lado do usuário/cliente, uma vez que o cliente receba a resposta a partir do servidor, uma verificação é feita para determinar se a solicita- ção/requisição foi aceita através da avaliação do valor de N ( o número principal de sub- clipes a serem encadeados ao cliente a partir do servidor) em 405. Caso o valor de N seja maior do que zero, então a solicitação/requisição foi aceita, e o usuário começa a receber os N sub-clipes encadeados em 410. Deve-se observar que o estabelecimento de N = -1 no lado do servidor, e o teste para N > 0 no lado do usuário/cliente compreende uma implemen- tação possível. O teste de admissão de requisição pode ser implementado, por exemplo, por meio de um sinalizador ou qualquer outro meio adequado. O número do sub-clipe corrente, N0, é ajustado como N+1 ( o sub-clipe a seguir - o sub-clipe a ser descarregado) em 415. Um teste é então realizado em 420 para determinar se existem mais sub-clipes à serem descarregados. Caso tanto a solicitação quanto a requisição não tenha sido admitida ou todos os sub-clipes do vídeo tenham sido recebidos pelo usuário, então encerra-se o pro- cesso. No ínterim, uma parceria inclusa na rede de trabalho entre parcerias apresentan- do/armazenando temporariamente o sub-clipe de número (N+1) é localizada e dá-se o início do carregamento do sub-clipe de número (N+1) junto à parceria necessitando do sub-clipe de número (N+1) em 425. Caso seja determinado que o prazo limite, d, para o descarrega- mento (medido em função do tempo presente, t) não tenha chegado em 430, então o des- carregamento prossegue por 435. Caso seja determinado que o prazo limite, d, tenha sido alcançado ( conforme medição em função do tempo presente, t) em 430, então o dado veto- rial que estava faltando é preparado em 440. Resultando que, o dado vetorial que estava faltando é ligeiramente preparado antes do prazo limite, ou quando se determina que o des- carregamento não pode ser finalizado antes do prazo limite, d. Caso o descarregamento não possa ser finalizado antes do prazo limite, então é realizado um teste para se determinar se é necessário um encadeamento complementar em 445. O encadeamento complementar será descrito em maiores detalhes adiante. No ínterim, o contador de sub-clipe corrente é incrementado em 455. Caso se faça necessário o encadeamento complementar para se garantir que o desempenho do sistema seja satisfatório (chegada dos sub-clipes pelo usuá- rio antes dos prazos limites), então convoca-se o encadeamento complementar em 450. Conforme se atinge o prazo limite d, completa-se a descarga o sub-clipe de número (N+1), e o usuário dá início a reprodução do sub-clipe de número (N+1) e localiza-se uma parceria no interior da rede de trabalho entre parcerias apresentando/armazenando temporariamente o sub-clipe a seguir, dando início ao processo de descarregamento do sub-clipe.

Em seguida, descreve-se a computação do número de sub-clipes a serem encade- ados pelo servidor.

Juntamente com a solicitação/requisição, o cliente/usuário indica junto ao servidor a largura de faixa de conexão rebaixada estimada. Acredita-se que os usuários possam ter melhor conhecimento de suas próprias larguras de faixas de conexão rebaixada. No início do encadeamento de vídeo pelo servidor, a largura de faixa de conexão rebaixada é consu- mida tanto pelo encadeamento como pelo descarregamento entre parcerias. Assumindo-se que os sub-clipes n, são encadeados pelo servidor para o usuário i, a cópia do sub-clipe de número (ni+1) tem de ser descarregada antes de seu prazo limite, ou seja, L*n, onde L re- presenta a duração de um sub-clipe. Representando rplayback como a taxa de reprodução de vídeo e rdownlink como a largura de faixa de conexão rebaixada, (downlink - rplayback)niL >Lrp,ay. back- "n" deve ser um número inteiro (encadeia-se somente sub-clipes completos), daí,

n1= [r playback /(rdownlink ~ rplayback)] (Equação 1)

Descreveu-se acima, o serviço de solicitação em vídeo entre parcerias segmentado

da presente invenção que incorpora o descarregamento entre parcerias na forma de serviço tradicional de solicitação em vídeo entre cliente-servidor. O descarregamento entre parceri- as faz a condução da maior parte da carga de transferência de vídeo/dados, e, dessa ma- neira, reduz, de modo significativo a carga de trabalho imposta ao servidor. Em contraste ao descarregamento convencional de arquivo entre parcerias, aonde o objetivo é o de se ma- ximizar a atuação geral do sistema, o descarregamento entre parcerias da presente inven- ção leva em conta o desempenho do sistema (chegada de sub-clipes ao/pelo usuário antes de seus prazos limites) e objetiva atingir os prazos limites dos sub-clipes. O descarregamen- to entre parcerias para um único sub-clipe é descrito a seguir. Então, descrever-se-á, agora, como se coordenar o descarregamento entre parcerias ao longo de múltiplos sub-clipes de maneira a se alcançar a tempo oportuno o fornecimento de dados/vídeo junto a todos usuá- rios.

A presente invenção faz uso do descarregamento entre parcerias acionado por da- dos intercambiando os dados do sub-clipe entre os usuários. Os sub-clipes da presente in- venção são divididos em blocos de igual tamanho com os usuários descarregando os blocos a partir de múltiplos usuários, simultaneamente. Os blocos são, ainda, sub-divididos em sub- blocos para viabilizar o direcionamento das requisições, de maneira a reduzir a sinalização excedente. Para cada sub-clipe correspondente existe um componente central denominado de um sub-rastreador monitorando os usuários participando, naquele instante, no descarre- gamento entre parcerias de um sub-clipe particular. O sub-rastreador recebe atualizações dos usuários, de maneira periódica, bem como, quando os usuários se unem ou deixam o sub-clipe da rede de trabalho entre parcerias.

Parcerias em uma rede de trabalho entre parcerias são classificadas em duas cate- gorias: inicializadores e descarregadores. Inicializadores são os usuários que não tenham uma cópia parcial/completa do sub-clipe e encontram-se desejosos de servir/carregar o sub- clipe para outros. Os inicializadores não descarregam o dado do sub-clipe que eles (os inici- alizadores) encontram-se carregando junto a outras parcerias, devido que eles (os inicializa- dores) já tem o dado. Descarregadores compreendem os usuários que ainda se encontram descarregando o dado, mas ao mesmo tempo encontram-se desejosos de servirem os blo- cos que eles já possuam junto a outros servidores. Quando um novo usuário dá início ao descarregamento de um sub-clipe, o usuário contata o sub-rastreador correspondente para obtenção de uma lista de usuários, presentes naquele instante, na rede de trabalho entre parcerias (tanto inicializadores como descarregadores) que possuam o sub-clipe (ou uma porção do sub-clipe) e que se encontrem desejosos de carregar o sub-clipe. O novo usuário tenta, então estabelecer conexões com os usuários na lista, e daí tornando-se vizinho.

As parcerias executam um algoritmo distribuído de maneira individual para determi- nar a quais usuários a parceria deve servir/carregar o dado. Vários fatores são considerados no processo de seleção de modo a se maximizar a chance de que a maioria (número máxi- mo) dos usuários venha a receber o dado do sub-clipe antes de seus respectivos prazos limites expirarem.

Assumindo-se que um usuário é escolhido para receber o dado de um vizinho (par- ceria), e o vizinho tenha a opção de escolha de vários blocos dos quais poderia descarregar. O vizinho/parceria faz uso de uma política de primeiro local menos propenso (LRF) quanto à seleção de qual bloco a ser descarregado. A parceria procede à seleção de descarga de um bloco menos re-aplicado entre os seus vizinhos. O objetivo é o de maximizar a diversidade de conteúdo no sistema, ou seja, tornar o número de réplicas de cada bloco tão igual quanto o possível. Isto torna improvável que o sistema venha a ser obstruído caso os blocos menos propensos sejam difíceis de se encontrar. No caso de que o usuário possua todos os dados que o vizinho já tenha, o vizinho seleciona um outro usuário ao qual servir/descarregar o dado.

Redes de trabalho entre parcerias convencionais são designadas para distribuição de um único arquivo. Na presente invenção, um clipe de vídeo é dividido em múltiplos sub- clipes, aonde cada sub-clipe é distribuído fazendo-se uso de uma rede de trabalho entre parcerias. Contudo, no método esquemático da presente invenção, um usuário pode unir-se a múltiplas redes de trabalho entre parcerias, de maneira simultânea. Por exemplo, na Figu- ra 1, o cliente 3 no tempo U encontra-se reproduzindo o sub-clipe 2. O cliente 3 terá finaliza- do o descarregamento do sub-clipe 2 e se encontrará descarregando o sub-clipe 3. Assim, o cliente 3 participa em três redes de trabalho entre parcerias, para os sub-clipes 1,2, e 3, res- pectivamente. O cliente 3 compreende de um inicializador em uma rede de trabalho entre parcerias para o sub-clipe 1, e um inicializador em (outra) rede de trabalho entre parcerias para o sub-clipe 2, e de um descarregador para ainda uma outra rede de trabalho entre par- cerias para o sub-clipe 3. O cliente 1 e o cliente 2 compreendem os inicializadores do cliente 3 para o sub-clipe 3. No tempo U o cliente 2 encontra-se descarregando o sub-clipe 4, e o cliente 1 compreende o inicializador para o sub-clipe 4 para o cliente 2. Finalmente, no tem- po U, o cliente 1 encontra-se descarregando o sub-clipe 5, e o servidor original representa o único inicializador para o cliente 1 para o sub-clipe 5. O cliente 3 não será capaz de servir ao cliente 1 e 2.

Na rede de trabalho entre parcerias com desempenho monitorado da presente in- venção para provimento de vídeo a partir de uma demanda por serviço, um usuário pode se unir junto a múltiplas redes de trabalho entre parcerias (um usuário pode se unir a uma dife- rente rede de trabalho entre parcerias para cada sub-clipe). Entretanto, o número total de carregamentos deverá compreender de um pequeno número, de modo a se evitar a degra- dação do desempenho através de ter-se um amplo número de conexões TCP em aberto. A questão, então, torna-se em como se fazer a seleção do carregamento das parcerias ao longo de múltiplas redes de trabalho entre parcerias, de modo que o desempenho geral, ou seja, que possa se ter a oportunidade de se maximizar a que todos os usuários restabele- çam o conteúdo/sub-clipes antes de seus, respectivos, prazos limites. Em seguida, apresen- ta-se uma lista de fatores chaves que se acredita afetar o desempenho do sistema.

1. O quão urgente se faz o prazo limite. Quanto mais estreito seja o prazo limite, mais alta a prioridade ao descarregador.

2. Encontra-se o descarregamento dentro do prazo? Todos os usuários devem ser tratados de modo idêntico. O descarregamento deve ser executado de forma proporcional ao tempo gasto pelas parcerias no sistema uma vez que tenha tido início o descarregamen- to.

3. Quantos inicializadores em potencial se apresentam disponíveis? Assumindo-se que os usuários se afastam imediatamente após a conclusão da reprodução do vídeo em parceria, o número de inicializadores disponíveis é diferente para diferentes sub-clipes em tempos diferentes. Por exemplo, o número de inicializadores para o sub-clipe 2 para o clien- te 4 na Figura 1 é maior do que o referente ao sub-clipe 3. Isto se dá devido ao inicializador do sub-clipe 3 também representar o inicializador do sub-clipe 2. Não obstante, o inicializa- dor para o sub-clipe 2 pode não ser o inicializador para o sub-clipe 3, uma vez que o iniciali- zador poderia deixar o sistema após a conclusão da reprodução. Em regra, caso o processo

de entrada do cliente seja um processo Poisson com taxa de entrada média Niseed = λ (Lvi- deo - iL) (Equação 2), onde Niseed representa o número médio de inicializadores para o sub-clipe i, Lvideo representa a extensão de vídeo, e L representa a extensão do sub-clipe.

4. A alta velocidade de carregamento melhora o funcionamento do sistema e, deve, portanto, ter a preferência.

S representa o tamanho do sub-clipe, enquanto que t representa o tempo corrente. Considerando que χ seja o tempo quando o usuário j inicia o descarregamento do k- ésimo sub-clipe, e ç (t) seja a quantidade de conteúdo restaurado no tempo t. Ainda, consi- derando que seja o prazo limite para o usuário j do k-ésimo sub-clipe. Por fim, definin- do-se pkj como sendo o indicador de progresso de descarregamento para oj'-ésimo cliente referente ao k-ésimo sub-clipe. Assim, Pj =S(xkj -t)/[Skj(t)xkj - dkj)] (Equação 3).

O valor de Pkj reflete o progresso do descarregamento. Ou seja, pk indica se o descarregamento do vídeo/dados encontra-se dentro do prazo. S/ (skj ~ dkj] ) compreende a taxa de descarregamento requerida de modo a se restaurar o sub-clipe a tempo (através do prazo limite do sub-clipe). (χk -1) representa o tempo decorrido, e χk (t) / (χk -1) é a taxa de descarregamento obtida até o momento. O indicador do progresso do descarregamento compreende a razão da taxa de descarregamento requerida e a taxa de descarregamento alcançada. Caso pk = 1, o descarregamento encontra-se perfeitamente dentro do prazo. Caso pk <1, os espaços de descarregamento encontram-se atrasados, e caso pk> 1, o des- carregamento encontra-se adiantado.

Agora, irá se discutir a métrica empregada para determinação de qual vizinho uma parceria deve enviar o dado. Considerando que wkij representa o peso de carregamento para a parceria i a servir/descarregar o dado para a y-ésima parceria para o k-ésimo sub- clipe. Quanto maior o valor de wkij, mais provavelmente a parceria i escolherá servir a par- ceria j. Considerando que wkij seja: wkij = <formula>formula see original document page 12</formula> (Equação 4). O numerador é rij que representa a taxa/velocidade de carregamento de uma parceria i para uma parce- ria j. Intuitivamente, uma velocidade mais alta/elevada de carregamento se melhora o fun- cionamento geral do sistema. Portanto, uma taxa de carregamento maior é mais bem-vinda. Isto leva ao fator 4 acima.

Ocorrem três termos no denominador da Equação (4). Conforme definido na Equa- ção (3), pj é o indicador de progresso e um pequeno valor seu indica que a parceria j en- contra-se atrasada. Contudo, deve ser dada alta prioridade a parceria j de acordo com o fator 2 acima. O valor de (dkj -t) representa o tempo do prazo limite. Quanto menor o valor de {(dkj -t), mais reduzido fica o prazo limite de acordo com o fator 1. Prioridade deve ser dada junto à requisição com o prazo limite mais reduzido. Finalmente, todos os sub-clipes k, k E{k| dti < t} da parceria i compreendem inicializadores ao tempo t. Contudo, a requisição por um sub-clipe diferente apresenta um número diferente de inicializadores, conforme mos- trado pela Equação (2). A prioridade deve ser dada a uma requisição de usuário apresen- tando o menor número de inicializadores. Quanto maior o tempo transcorrido, mais iniciali- zadores encontram-se disponíveis em referência para esta requisição, justificando o último termo no denominador (em acordo com o fator 3).

Conforme discutido acima, embora sejam tomados cuidados extras quanto ao en- dereçamento de questões referentes ao desempenho (chegada oportuna dos sub-clipes a atenção ou pelo usuário), alguns dados podem ainda estar faltando na altura de se encerrar o prazo limite(ou proximamente antes do prazo limite) quando se encerra o descarregamen- to entre parcerias. Como fazer uso do servidor para encadear o dado que falta de maneira a melhorar o desempenho de reprodução do vídeo em parceria é o que será descrito na se- qüência. Denominamos a isto do encadeamento complementar. Conforme vá se aproximan- do do prazo limite, o cliente em parceria prepara um dado vetorial que esteja faltando Vmis. sing, que compreende de um mapa de bit que emprega um primeiro sinalizador, por exemplo "1" para indicar que foi recebido um bloco, com um segundo sinalizador, por exemplo "0", para indicar que um bloco encontra-se ainda faltando. O dado vetorial que está faltando é enviado para o servidor (sinalizado) em conjunto com o prazo limite para o sub-clipe chegar até ao usuário. O servidor inicia o encadeamento referente ao dado que está perdido con- forme vá se aproximando o prazo limite, de maneira que o vídeo/dado que está faltando possa ser preenchido a tempo para a reprodução do vídeo em parceria.

O servidor da presente invenção é responsável por-três coisas, (i) servir os sub- clipes iniciais/principais para fornecer suporte imediato de reprodução (via encadeamento); (ii) proporcionar encadeamento complementar para melhorar a qualidade visual para os u- suários (assegurando que os sub-clipes cheguem até ao usuário antes do prazo limite para cada sub-clipe), e (iii) servir como um inicializador no descarregamento de vídeo/dado entre parcerias. As tarefas 1 e 2 apresentam uma prioridade mais elevada do que a tarefa 3.

Deve-se compreender que a presente invenção pode ser implementada em vários formatos de hardware, software, firmware, em processadores para finalidades especiais, ou através de uma combinação dos mesmos. Preferencialmente, a presente invenção é imple- mentada como uma combinação de hardware com software. Mais ainda, o software é im- plementado, preferencialmente, na forma de um programa de aplicação personificado de modo tangível em um dispositivo de armazenagem de programas. O programa de aplicação pode ser carregado e executado, através de uma máquina compreendendo qualquer arqui- tetura adequada. Preferencialmente, a máquina é implementada em uma plataforma de computador possuindo hardware, tal como uma ou mais unidades de processamento central (CPU), uma memória de acesso aleatório (RAM), e interfaces com entrada/saída. A plata- forma de computador inclui também um sistema operacional e código para micro-instruções. Os vários processos e funções aqui descritos podem tanto compreender parte do código de micro-instruções como parte do programa de aplicação (ou uma combinação dos mesmos), sendo executados via o sistema operacional. Ainda, vários outros dispositivos periféricos podem ser conectados à plataforma do computador, tal como um dispositivo de armazena- mento de dados adicional e uma impressora.

Deve-se compreender ainda que, devido a alguns componentes do sistema consti- tuinte e as etapas dos métodos descritos nas figuras de acompanhamento serem preferen- cialmente implementados no software, as conexões atuais entre os componentes do sistema (ou entre as etapas do processo) podem diferir, dependendo da maneira pela qual a presen- te invenção é programada. Através dos ensinamentos prestados pelo presente relatório, um técnico especialista na área será capaz de contemplar essas e outras implementações configurações semelhantes da presente invenção.

Claims

1. Método, CARACTERIZADO pelo fato de compreender: recebimento de um sub-clipe com conteúdo principal encadeado; determinação de um conjunto de sub-clipes com conteúdo procurado; localização de um sub-clipe do referido conjunto de sub-clipes com conteúdo procu- rado; e descarregamento de referido sub-clipe com conteúdo localizado.

2. Método, de acordo com a reivindicação 1, CARACTERIZADO pelo fato de com- preender ainda a requisição de um unidade de conteúdo.

3. Método, de acordo com a reivindicação 1, CARACTERIZADO pelo fato de com- preender ainda conexão a uma rede de trabalho entre parcerias para obtenção de referido sub-clipe com conteúdo localizado.

4. Método, de acordo com a reivindicação 1, CARACTERIZADO pelo fato de com- preender ainda: cálculo de um prazo limite para o descarregamento de referido sub-clipe com con- teúdo localizado; determinação de se o referido prazo limite para o descarregamento de referido sub- clipe com conteúdo localizado será satisfeito; e descarregamento de referido sub-clipe com conteúdo localizado caso o referido prazo limite para o referido sub-clipe com conteúdo localizado seja satisfeito.

5. Método, de acordo com a reivindicação 4, CARACTERIZADO pelo fato de com- preender ainda: preparação de um dado vetorial que esteja faltando caso o referido prazo limite pa- ra descarregamento de referido sub-clipe com conteúdo localizado seja excedido; e convocar o encadeamento complementar para os blocos de referido sub-clipe com conteúdo localizado pelo qual o referido prazo limite venha a ser excedido.

6. Método, de acordo com a reivindicação 1, CARACTERIZADO pelo fato de com- preender ainda: segmentação dos blocos dos sub-clipes com conteúdo procurado em sub-blocos; direcionamento das requisições para os referidos sub-blocos; e encaminhamento da referida condição atual.

7. Método, de acordo com a reivindicação 6, CARACTERIZADO pela referida con- dição atual incluir condição atual de descarregamento, condição atual de participação em rede de trabalho entre parcerias e condição atual de conteúdo com armazenamento tempo- rário.

8. Método, de acordo com a reivindicação 1, CARACTERIZADO pelo fato da referi- da etapa de localização compreender ainda: sinalização de um sub-rastreador para determinar uma localização e condição atual de referidos sub-clipes com conteúdo procurado; e selecionar a referida localização a partir de onde se proceder a requisição de refe- ridos sub-clipes com conteúdo localizado.

9. Método, de acordo com a reivindicação 8, CARACTERIZADO pela referida etapa de seleção ser baseada no primeiro esquema menos provável.

10. Método, de acordo com a reivindicação 4, CARACTERIZADO pelo fato de compreender ainda cálculo de um indicador de progresso de descarregamento.

11. Método, de acordo com a reivindicação 10, CARACTERIZADO pelo referido in- dicador de progresso de descarregamento compreender de uma razão entre a taxa de des- carregamento requisitada pela taxa de descarregamento alcançada.

12. Método, de acordo com a reivindicação 4, CARACTERIZADO pelo fato de compreender ainda cálculo de um peso de carregamento.

13. Método, de acordo com a reivindicação 1, CARACTERIZADO pelo fato de compreender ainda: estabelecimento de um indicador quanto ao próximo sub-clipe com conteúdo pro- curado.

14. Método, de acordo com a reivindicação 13, CARACTERIZADO pelo fato de compreender ainda a incrementação de referido indicador.

15. Método, de acordo com a reivindicação 13, CARACTERIZADO pelo fato de compreender conexão junto a uma rede de trabalho entre parcerias para obtenção de referi- do próximo sub-clipe com conteúdo procurado.

16. Método, CARACTERIZADO pelo fato de referido método compreender: recebimento de uma requisição por uma unidade de conteúdo; desempenhar controle de admissão; segmentar a referida unidade de conteúdo em uma pluralidade de sub-clipes com conteúdo; calcular um número principal de sub-clipes com conteúdo a serem encadeados; e encadear os referidos sub-clipes com conteúdo principal.

17. Método, de acordo com a reivindicação 16, CARACTERIZADO pelo fato de compreender ainda o descarregamento dos restantes sub-clipes com conteúdo.

18. Método, de acordo com a reivindicação 16, CARACTERIZADO pelos referidos sub-clipes com conteúdo serem de igual tamanho.

19. Sistema, CARACTERIZADO pelo fato de compreender: um servidor; uma parceria; e um rastreador.

20. Sistema, de acordo com a reivindicação 19, CARACTERIZADO pelo fato do re- ferido rastreador e do referido servidor poderem ser co-localizados.

21. Sistema, de acordo com a reivindicação 19, CARACTERIZADO pelo fato do re- ferido servidor ser um inicializador.

22. Sistema, de acordo com a reivindicação 19, CARACTERIZADO pela referida parceria ser um descarregador.

23. Sistema, de acordo com a reivindicação 19, CARACTERIZADO pela referida parceria compreender ainda de: mecanismo para o recebimento de um sub-clipe com conteúdo principal encadea- do; mecanismo para a determinação de um conjunto de sub-clipes com conteúdo pro- curado; mecanismo para a localização de um sub-clipe do referido conjunto de sub-clipes com conteúdo procurado; e mecanismo para o descarregamento de referido sub-clipe com conteúdo localizado.

24. Sistema, de acordo com a reivindicação 23, CARACTERIZADO pela referida parceria compreender de mecanismo para a requisição de uma unidade de conteúdo.

25. Sistema, de acordo com a reivindicação 23, CARACTERIZADO pela referida parceria compreender ainda de mecanismo para conexão junto a uma rede de trabalho en- tre parcerias para obtenção de referido sub-clipe com conteúdo localizado.

26. Sistema, de acordo com a reivindicação 23, CARACTERIZADO pela referida parceria compreender ainda: mecanismo para o cálculo de um prazo limite para descarregamento de referido sub-clipe com conteúdo localizado; mecanismo para a determinação de se o referido prazo limite para o descarrega- mento de referido sub-clipe com conteúdo localizado será satisfeito; e mecanismo para o prosseguimento do descarregamento de referido sub-clipe com conteúdo localizado caso o referido prazo limite para o referido sub-clipe com conteúdo loca- lizado seja satisfeito.

27. Sistema, de acordo com a reivindicação 23, CARACTERIZADO pela referida parceria compreender ainda de: mecanismo para a preparação de um dado vetorial que esteja faltando, caso o refe- rido prazo limite para o descarregamento de referido sub-clipe com conteúdo localizado seja excedido; e mecanismo para convocação de encadeamento complementar para os blocos de referido sub-clipe com conteúdo localizado cujos referidos prazos limites foram excedidos.

28. Sistema, de acordo com a reivindicação 23, CARACTERIZADO pelo fato da re- ferida parceria compreender ainda de: mecanismo para a segmentação de blocos de sub-clipes com conteúdo procurado em sub-blocos; mecanismo para o direcionamento de requisições para os referidos sub-blocos; e mecanismo para encaminhamento de referida condição atual.

29. Sistema, de acordo com a reivindicação 23, CARACTERIZADO pelo referido mecanismo de localização compreender ainda: mecanismo para sinalização de um sub-rastreador para a determinação de uma lo- calização e condição atual de referidos sub-clipes com conteúdo procurado; e mecanismo para a seleção de referida localização a partir de onde se possa fazer uma requisição dos referidos sub-clipes com conteúdo localizado.