BRPI0806326A2

BRPI0806326A2 - sistema e método para combinar modos puxar e empurrar

Info

Publication number: BRPI0806326A2
Application number: BRPI0806326-5A
Authority: BR
Inventors: Eric Gautier; Willem Lubbers; Francois Gerard
Original assignee: Thomson Licensing
Priority date: 2007-01-12
Filing date: 2008-01-11
Publication date: 2011-09-06
Also published as: CA2675057A1; US9100376B2; US20100011088A1; RU2009130739A; MX2009007438A; EP2103083A1; JP2015172954A; JP5785689B2; EP2103083B1; CN101584190A; CN101584190B; RU2454820C2; JP5951071B2; KR101606940B1; EP1944944A1; ZA200904569B; JP2010515988A; WO2008084096A1; KR20090101489A; CA2675057C

Abstract

SISTEMA E MéTODO PARA COMBINAR MODOS PUXAR E EMPURRAR. A presente invenção diz respeito a um método para transferir conteúdo usando uma combinação de modos empurrar e puxar. Em um Sistema de Comunicação (10) que compreende um primeiro terminal (1), pelo menos um segundo terminal (2) e um servidor de conteúdo (5, 8), a invenção diz respeito a um método para transferir conteúdo que compreende, no nível do primeiro terminal, as etapas de transferir conteúdo tanto em um modo puxar do servidor de conteúdo ou do pelo menos segundo terminal quanto em um modo em- purrar do servidor de conteúdo, e comutar continuamente entre os modos para continuar a transferência de conteúdo.

Description

"SISTEMA E MÉTODO PARA COMBINAR MODOS PUXAR E EMPURRAR" A presente invenção diz respeito, no geral, a transferência de conteúdo e, em parti- cular, ao uso de uma combinação de métodos de puxar e empurrar.

Esta seção visa introduzir o leitor a vários aspectos da tecnologia, que podem estar relacionados a vários aspectos da presente invenção que são descritos e/ou reivindicados a seguir. Acredita-se que esta discussão seja útil para fornecer ao leitor informação de fundo para facilitar um melhor entendimento dos vários aspectos da presente invenção. Dessa maneira, entende-se que estas declarações devem ser lidas a esta luz, e não como admis- sões da tecnologia anterior.

Uma distribuição de conteúdo entre um servidor e múltiplos receptores exige confi- gurar uma conexão ponto a ponto entre o servidor e cada receptor ou uma conexão multi- pontos. A conexão ponto a ponto permite distribuir o conteúdo em um dispositivo de difusão ponto a ponto a cada receptor e fornecer uma distribuição robusta. Doravante, este é cha- mado de modo puxar e, usualmente, clientes são iniciadores ativos. Entretanto, com um significativo número de receptores, ele exige um pesado gerenciamento de todas as cone- xões. Ele também pode aumentar significativamente o tráfego na rede. A distribuição por difusão seletiva fornece menor carga na rede com uma distribuição menos robusta. Dora- vante, este é chamado de modo empurrar.

Um operador de serviço que gerencia o servidor não pode predizer precisamente o comportamento dos receptores. Em uma sessão de distribuição de conteúdo no modo em- purrar, receptores podem ser excluídos da completa ou parcial transferência de conteúdo pelos seguintes motivos: receptores são desativados durante a distribuição no modo empur- rar; receptores são ativados quando a distribuição no modo empurrar está em andamento; toda a largura de banda reservada não está disponível para a distribuição no modo empur- rar, por exemplo, o usuário STB está assistindo a um programa enquanto está gravando um outro; receptores estão com falta de espaço de armazenamento no momento da distribuição no modo empurrar; receptores estão usando toda a capacidade da CPU no momento da distribuição no modo empurrar; redes não podem gerenciar o tráfego por difusão seletiva; etc. A fim de otimizar a largura de banda, o operador pode precisar escolher manter a ses- são no modo empurrar ou pará-la. Parar a sessão no modo empurrar permite que o opera- dor libere a rede em relação a uma grande quantidade de tráfego e que os receptores que perderam conteúdo possam recuperá-lo usando um modo de recuperação. Um método de recuperação foi definido no pedido de patente EP 06291464.3. Por outro lado, no modo pu- xar, o operador pode precisar enfrentar picos de demandas de conteúdo. Então, pode ser mais eficiente para o operador otimizar o uso da largura de banda da rede e o atraso de im- plementação pela difusão seletiva deste conteúdo no modo empurrar em vez de usar o mo- do puxar. A presente invenção diz respeito a um método para comutar eficientemente entre o modo puxar e o modo empurrar.

Com esta finalidade, a invenção diz respeito a um método para transferir conteúdo, em um sistema de comunicação que compreende um primeiro terminal, pelo menos um se- gundo terminal e um servidor de conteúdo. O método compreende, no nível do primeiro ter- minal, as etapas de transferir conteúdo tanto em um modo puxar do servidor de conteúdo quanto do pelo menos segundo terminal quanto em um modo empurrar do servidor de con- teúdo, e de comutar ininterruptamente entre os modos para continuar a transferência de conteúdo.

Neste contexto, ininterruptamente significa que o terminal comuta continuamente de um modo para o outro modo, sem precisar solicitar nenhuma informação adicional.

De acordo com uma modalidade, o método compreende as etapas de transferir conteúdo em um modo empurrar, e de continuar transferindo o conteúdo em um modo puxar quando o modo empurrar parar no servidor de conteúdo.

Quando o operador parar a sessão no modo empurrar, o terminal continua a trans- ferência sem muita interrupção. Ele adquiriu informação suficiente durante a sessão no mo- do empurrar para comutar para a transferência no modo puxar e gerenciá-la.

De acordo com uma outra modalidade, o método compreende as etapas de transfe- rir conteúdo em um modo puxar, e de continuar transferindo o conteúdo em um modo em- purrar quando o modo empurrar começar no servidor de conteúdo.

De acordo com uma modalidade, o método compreende as etapas de receber o conteúdo no modo empurrar em uma distribuição de sessão de acordo com o protocolo FLUTE, e de receber informação em uma Tabela de Distribuição de Arquivo, FDT, durante a distribuição de sessão que permite comutar para um modo puxar.

A FDT compreende informação adicional necessária para comutar ininterruptamen- te para o modo puxar. Quando o modo empurrar para, o terminal não precisa recuperar ne- nhuma informação adicional. Ele já recebeu informação relevante com a FDT para comutar para o modo puxar.

De acordo com uma modalidade, o método compreende as etapas de verificar a in- tegridade da instância da FDT, de indicar para um servidor de indexação se a instância da FDT foi recebida com sucesso ou não, e de indicar ao servidor de indexação se o arquivo associado com a instância da FDT foi recebido com sucesso ou não.

De acordo com uma modalidade, o método compreende, durante a detecção de uma instância da FDT que foi corrompida, as etapas de esperar pelo fim da distribuição do arquivo, e de realizar uma reparação na instância da FDT em um modo puxar.

De acordo com uma modalidade, o método compreende, durante a detecção de uma FDT completa corrompida, as etapas de esperar pelo fim da distribuição de sessão, e de realizar uma reparação na FDT completa em um modo puxar.

De acordo com uma modalidade, o método compreende as etapas de receber o conteúdo no modo puxar de acordo com um protocolo ponto a ponto, e de receber arquivo de metainformação ponto a ponto que compreende informação que permite comutar para um modo empurrar.

A presente invenção também diz respeito a um terminal que compreende dispositi- vo para transferir conteúdo em um modo empurrar, dispositivo para transferir conteúdo no modo puxar, e dispositivo para comutar ininterruptamente de um modo para o outro modo.

Um outro objetivo da invenção é um produto de programa de computador que com- preende instruções em código de programa para executar as etapas do processo de acordo com a invenção quando este programa for executado em um computador. Por "produto de programa de computador" entende-se um suporte de programa de computador que pode consistir não somente em um espaço de armazenamento que contém o programa, tais como um disquete ou um cassete, mas também em um sinal, tais como um sinal elétrico ou ótico.

Certos aspectos de escopo comensurável com as modalidades divulgadas são a- presentados a seguir. Entende-se que estes aspectos são apresentados meramente para fornecer ao leitor um sumário de certas formas que a invenção pode tomar, e que não pre- tende-se que estes aspectos limitem o escopo da invenção. De fato, a invenção pode a- branger uma variedade de aspectos que pode não ser apresentada a seguir.

A invenção será mais bem entendida e ilustrada por meio da seguinte modalidade e exemplos de execução, de nenhuma maneira limitantes, em relação aos desenhos anexos, nos quais:

- a figura 1 é um diagrama de blocos de um sistema em conformidade com a moda- lidade;

- a figura 2 representa um terminal de acordo com a modalidade;

- a figura 3 é um fluxograma que ilustra o modo puxar; e

- a figura 4 é um fluxograma que ilustra uma combinação dos modos empurrar e puxar.

Nas figuras 1 e 2, os blocos representados são entidades puramente funcionais, que não correspondem necessariamente a entidades fisicamente separadas. A saber, elas podem ser desenvolvidas na forma de software ou ser implementadas em um ou diversos circuitos integrados.

A figura 1 representa a arquitetura do sistema de comunicação 10 de acordo com a modalidade para distribuir de conteúdo. Os terminais 1,2,3 compreendem aplicações clien- tes. Em particular, eles compreendem a função de um conversor de sinal de freqüência (STB). A seguir, na modalidade, o terminal é um STB, mas a modalidade não é limitada a tais terminais. Ela é aplicável a um dispositivo que compreende uma aplicação cliente para transferir dados a partir de um servidor de conteúdo.

O terminal também compreende dispositivo para transferir conteúdo em um modo empurrar e dispositivo para transferir conteúdo em um modo puxar. Ele realiza as funções de puxar e empurrar da forma descrita a seguir.

O sistema compreende um servidor de conteúdo no modo empurrar 5 e um servidor de conteúdo no modo puxar 8. O servidor de conteúdo no modo puxar é adaptado para dis- tribuir o conteúdo em um modo puxar. Ele compreende dispositivo para estabelecer uma conexão ponto a ponto com múltiplos clientes. O servidor de conteúdo no modo empurrar é adaptado para distribuir o conteúdo em um modo empurrar. Certamente, estes servidores podem ser incluídos no mesmo dispositivo.

O papel do Servidor de Indexação 6 é colocar STBs pares em relação uns com os outros para completar o reparo ou a recuperação do conteúdo. O papel do Servidor de Inde- xação é colocar pares que precisam recuperar arquivos, ou partes de arquivos, em relação com pares que podem fornecer a informação ausente. O Servidor de Indexação não arma- zena nenhum arquivo de conteúdo, ele age como um índice centralizado para armazenar informação sobre a localização dos arquivos. O protocolo do modo puxar exige que o Servi- dor de Indexação seja mantido informado, por cada STB, sobre o estado de transferência do conteúdo. De acordo com a modalidade, o sistema compreende somente um Servidor de Indexação. Uma rede pode ter diversos Servidores de Indexação para otimizar o acesso, por exemplo, por região geográfica ou por tipo de conteúdo. O mesmo Servidor de Indexação é usado em um ambiente do modo empurrar, bem como em um ambiente do modo puxar.

O servidor de descoberta de serviço 7, doravante apontado como SD&S, é adapta- do para realizar o mecanismo de descoberta e seleção de serviço, da forma indicada no padrão ETSI TS 102 034 V1.2.1 (2006-09) Difusão de Vídeo Digital (DVB), Serviços DVB com Base no Transporte de MPEG-2 em Redes com Base em IP.

De acordo com a modalidade, o mesmo servidor SD&S é usado no ambiente do modo EMPURRAR bem como no ambiente do modo PUXAR.

A figura 2 representa os blocos de construção de um terminal de acordo com a mo- dalidade. O terminal compreende dispositivo de armazenamento 1.1, dispositivo de comuni- cação 1.2, dispositivo de processamento 1.3 e um barramento interno 1.4. Pretende-se que o dispositivo de armazenamento armazene um programa que permite que o terminal transfi- ra o arquivo em um modo empurrar ou em um modo puxar. Assim, o terminal compreende dispositivo de transferência no modo empurrar 1.6 e dispositivo de transferência no modo puxar 1.5. Ele compreende dispositivo para comutar 1.7 de um modo para o outro modo.

O método de puxar é agora descrito. Ele é baseado em uma estratégia ponto a ponto, apontada como P2P.

A fim de realizar um método de puxar, primeiro, o terminal realiza a fase de desço- berta do endereço do Servidor de Indexação. Um STB encontra conteúdo para transferência pela navegação de um catálogo de conteúdo disponível para transferência. O endereço do catálogo é encontrado usando o Registro do Guia de Conteúdo de Banda Larga da DVB-IP, da forma especificada no ETSI TS 102 034 V1.2.1 (2006-09) e no ETSI TS 102 539 V1.1.1, Difusão de Vídeo Digital (DVB)1 Transporte de informação do Guia de Conteúdo de Banda Larga (BCG) por Protocolo da Internet (IP), que descreve o transporte e sinalização de guias de conteúdo no contexto da DVB-IP. O terminal encontra o endereço de um Servidor de In- dexação no catálogo. Certamente, o endereço do Servidor de Indexação pode ser encontra- do por outros meios, tal como um registro que oferece transferência de conteúdo que é dis- tribuído pela sinalização DVB-IP / SD&S.

Para melhorar a capacidade de transferir grandes conteúdos, cada arquivo de con- teúdo é dividido em blocos menores. Então, os pares podem receber e verificar os blocos de conteúdo e, então, trocar estes blocos antes de receber o conteúdo de forma completa ou parcial. Um código de dispersão é calculado em cada bloco. A metainformação, da forma indicada na tabela 1, é armazenada como um arquivo no Servidor de Conteúdo. A metain- formação compreende toda a informação necessária para realizar uma troca de arquivo em ponto a ponto. A operação de dispersão pode ser feita pelo servidor de conteúdo.

A seguinte tabela representa a metainformação de conteúdo de acordo com a mo- dalidade. Os campos TSI e TOI são definidos no protocolo FLUTE. Eles são opcionais. Eles são aqui usados para suportar comutação ininterrupta entre os modos puxar e empurrar. Os campos Content-Block-Length, Content-Block-Digests, File-Name, File-Length, File-Digest1 File-Block-Length e File-Block-Digests são a metainformação mínima necessária para um protocolo P2P.

<table>table see original document page 6</column></row><table> <table>table see original document page 7</column></row><table>

Tabela 1

O campo Meta-Info-Digest pode ser usado para transmitir uma assinatura RSA para permitir a autenticação do arquivo de metainformação.

Então, o método para transferir arquivo é como segue, da forma descrita na figura 3.

Etapa S1. O STB 1 transmite uma solicitação de um conteúdo escolhido ao Servi- dor de Indexação.

Etapa S2. O Servidor de Indexação responde ao STB com o endereço de um STB 2 par que pode fornecer a metainformação do conteúdo. Certamente, o Servidor de Indexação pode fornecer o endereço de diversos pares.

O STB 1 inicia uma conexão com o par indicado, Etapa S3. Ele recupera o arquivo de metainformação na Etapa S4, verifica sua integridade na Etapa S5, armazena este arqui- vo e notifica o Servidor de Indexação sobre a recepção da metainformação, Etapa S6. O STB 1 mantém este arquivo na memória até que o conteúdo associado com ele seja apaga- do.

Com este arquivo de metainformação, o STB pode solicitar qualquer faixa de bytes de um bloco dos outros pares e verificar a integridade dos dados recebidos. Depois que o STB receber o arquivo de metainformação, ele pode transferir um ou mais arquivos ou blo- cos dos um ou mais arquivos.

O STB solicita um bloco do Servidor de Indexação. Etapa 7. Certamente, o STB pode solicitar diversos blocos ao mesmo tempo. Ele transmite o número do bloco e o identi- ficador do arquivo (este pode ser o nome do arquivo). O ID do arquivo é necessário quando diversos arquivos são transferidos de forma concorrente.

O Servidor de Indexação retorna um endereço de um par que pode fornecer o bloco do conteúdo, Etapa 8.

O STB inicia uma conexão com o(s) par(s) indicado(s), Etapa 9, recupera o(s) blo- co(s) de conteúdo, Etapa 10, e verifica sua(s) integridade(s), Etapa 11.

O STB indica o estado da transferência do bloco, em termos de sucesso ou falha, ao Servidor de Indexação, Etapa 12.

O cliente pode transmitir novas solicitações por outros blocos ao Servidor de Inde- xação até que ele tenha transferido o conteúdo completo.

Usando a informação dada nos relatórios que ele recebe dos STBs, o Servidor de Indexação atualiza continuamente sua base de dados. Em um dado momento, ele pode co- locar um STB que precisa de recuperação de dados em relação com um STB par que pode fornecer a informação ausente.

Graças aos campos TSI e TOI, o terminal pode comutar ininterruptamente para o modo empurrar para transferir o arquivo.

Na figura 3, o par que fornece o bloco do conteúdo é o mesmo par que fornece a metainformação do conteúdo. Certamente, este pode ser um outro par.

Além do mais, o Servidor de Indexação pode retornar o endereço de mais de um par que podem fornecer o bloco do conteúdo. Então, o STB possivelmente conectará em mais de um par.

Um Servidor de Indexação pode ter informação de que o arquivo de conteúdo ou de metainformação solicitado não pode ser fornecido por nenhum dos STBs pares.

Neste caso, ele pode fornecer o endereço de um Servidor de Conteúdo que pode distribuir o conteúdo diretamente. A fim de evitar a sobrecarga do Servidor de Conteúdo com solicitações por conteúdo, o Servidor de Indexação pode servir somente um grupo de STBs pares. Ele coloca o outro STB em espera e, posteriormente, indica a eles os endereços do grupo de STBs pares que transferiram o conteúdo com sucesso.

Alternativamente, o Servidor de Indexação pode endereçar a solicitação para um outro Servidor de Indexação ou para um "Super" Servidor de Indexação. Se ele encontrar a informação solicitada, o Servidor de Indexação pode armazenar a informação na sua base de dados e responder positivamente ao STB.

Um Servidor de Indexação pode fornecer diversos endereços para o mesmo conte- údo. O conteúdo pode ser propagado em diversos STBs pares, isto é, nenhum dos STBs pares tem a íntegra do conteúdo, mas o conteúdo total pode ser construído a partir dos con- teúdos parciais residentes nos STBs pares. O Servidor de Indexação também pode indicar STBs pares alternativos que podem fornecer o conteúdo solicitado como um todo ou parci- almente, para dar ao STB a oportunidade de recuperar conteúdo de um outro par se ele descobrir que a velocidade de transferência é muito baixa ou se o par se comprovar indis- ponível. Por outro lado, um Servidor de Indexação pode ser alimentado com algoritmos que permitem uma inteligente seleção de par, por exemplo, com base em estatísticas sobre o número de transferências com sucesso a partir de um par.

O método para distribuição no modo empurrar é agora descrito. A distribuição no modo empurrar é baseada na Distribuição de Arquivo em Protocolo de Transporte Unidire- cional, apontado como FLUTE, da forma especificada no RFC 3926. A distribuição no modo empurrar compreende um mecanismo de recuperação que usa o mecanismo ponto a ponto supradescrito.

O protocolo FLUTE define a transmissão de objetos por difusão seletiva e as tabe- las de descritor associadas. Ele define uma Tabela de Distribuição de Arquivo, apontada como FDT, que contém informação dos arquivos que precisam ser transmitidos na sessão atual. O protocolo FLUTE transmite a FDT do servidor de conteúdo em um modo de difusão seletiva para todos os STBs. FLUTE define diversos modos de transmissão, tais como uma FDT completa seguida por múltiplos arquivos ou séries de instâncias de FDT (FDTs inter- mediárias) seguidas por seus arquivos associados. Este último é especialmente adequado para a transmissão de enormes arquivos de vídeo. Ele permite que um receptor possa veri- ficar se um objeto, ou um arquivo, foi corretamente recebido antes de o fim da sessão ser alcançado. O primeiro modo de transmissão é bastante conveniente em um ambiente em que pequenos arquivos são transmitidos. Uma FDT completa é construída a partir de todas as instâncias de FDT da mesma sessão.

De acordo com a modalidade, a FDT do FLUTE compreende a metainformação Ponto a Ponto específica (que compreende comprimento do bloco e dispersão do bloco), da forma indicada na seguinte Tabela 2. Então, é possível, durante uma transferência de con- teúdo, comutar ininterruptamente de um protocolo para o outro. De fato, os receptores que não transferiram o conteúdo de forma completa ou total no fim de uma sessão no modo em- purrar em difusão seletiva FLUTE podem comutar ininterruptamente para o modo puxar Ponto a Ponto e transferir os blocos ausentes graças à informação na FDT que permite que eles conheçam exatamente os blocos de conteúdo ausentes. Similarmente, um receptor que começou a transferir conteúdo por meio do modo puxar Ponto a Ponto pode comutar ininter- ruptamente para um modo empurrar usando a FDT, que dá ao receptor a informação neces- sária para recuperar os blocos ausentes do arquivo com o modo empurrar.

A seguinte tabela representa a Tabela de Distribuição de Arquivo do FLUTE, inclu- indo metainformação P2P de acordo com a modalidade.

<table>table see original document page 9</column></row><table> <table>table see original document page 10</column></row><table> <table>table see original document page 11</column></row><table>

Tabela 2

Os campos Content-Block-Length1 Content-Block-Digests, File-Name, File-Length1 File-Digest1 File-Block-Length e File-Block-Digests são a metainformação mínima necessária para um protocolo P2P. Um arquivo é cortado em diversos blocos.

O campo CompIete-FDT-Digest pode ser usado para transmitir uma assinatura RSA para permitir a autenticação da FDT completa.

A fim de transferir conteúdo com um método de empurrar, um cliente realiza uma fase de descoberta de sessão de transferência de conteúdo no modo empurrar. Um STB cliente assina em uma oferta de transferência no modo empurrar. Como parte da assinatura, ele obtém o endereço de distribuição onde a sinalização do serviço é transmitida pelo servi- dor SD&S por meio do mecanismo DVB-IP / SD&S. Então, o STB monitora o endereço de difusão seletiva dedicado. Ele descobre um registro que oferece transferência de conteúdo DVB-IP.

Neste registro que oferece transferência de conteúdo, ele descobre a data / hora de começo e de fim da sessão de transferência de conteúdo, bem como outras informações, tais como os endereços e portas de difusão seletiva nos quais o conteúdo é distribuído e o endereço do Servidor de Indexação do qual ele depende. O arquivo do registro SD&S de acordo com a modalidade é indicado na seguinte Tabela 3.

<table>table see original document page 11</column></row><table> <table>table see original document page 12</column></row><table> <table>table see original document page 13</column></row><table>

Tabela 3

O campo AnnouncementDigest pode ser usado para transmitir uma assinatura RSA para permitir autenticação do anúncio.

Da forma ilustrada na figura 4, usando a informação adquirida na fase de descober- ta, um STB monitora o endereço de difusão seletiva no qual o conteúdo da sessão no modo empurrará distribuído, etapa S'1.

Cada instância da FDT contém diversos códigos de dispersão que permitem a veri- ficação de sua própria integridade e da integridade dos blocos do arquivo associado com ela. Esta informação corresponde ao arquivo de metainformação, da forma descrita para o modo puxar. Como para o modo puxar, o STB armazena o arquivo de metainformação, en- quanto ele mantém o conteúdo associado. Então, o arquivo pode ser subseqüentemente usado para servir pares no modo puxar.

O STB detecta quando a distribuição de um arquivo termina por meio do indicador "End-Of-Transmission-File" do protocolo FLUTE. A partir deste momento, cada STB pode verificar a integridade da instância da FDT, etapas S'2, S'3. Depois desta verificação, cada STB transmite uma mensagem ao Servidor de Indexação que indica se ele recebeu a ins- tância da FDT1 etapas S'4, S'5.

Então, se a verificação da integridade da instância da FDT tiver sucesso, o STB ve- rifica a integridade dos blocos do arquivo associado com a instância da FDT (etapa S'6, S'7) e transmite um relatório para o Servidor de Indexação em relação ao arquivo associado, etapas S'8, S'9. Este relatório contém informação sobre os blocos que foram corretamente recebidos, bem como sobre o identificador do arquivo. O Servidor de Indexação armazena esta informação e atualiza sua base de dados. Para a parte destes arquivos que está ausen- te, um STB realiza uma recuperação de arquivo, da forma descrita a seguir.

Se a verificação de integridade da instância da FDT falhar, uma instância da FDT corrompida não permite que o STB verifique a integridade dos blocos do arquivo associado com ela, em virtude de esta informação estar contida na instância da FDT. O STB armazena o arquivo que segue a FDT corrompida e espera pela detecção do fim da distribuição do arquivo para começar uma reparação da instância da FDT, da forma descrita a seguir. Os pacotes FLUTE que contêm um bloco incluem um identificador chamado TOI, que é exclusi- vo para cada arquivo. Um FDT também contém este identificador, que permite relacionar blocos com um arquivo.

A última instância da FDT da sessão também contém um código de dispersão cal- culado sobre o total de todas as instâncias da FDT que são parte da sessão. Isto permite a verificação da integridade da FDT completa e o conhecimento se as instâncias da FDT es- tão ausentes. Isto pode ser usado para detectar o caso em que uma instância da FDT é dis- tribuída somente por um pacote FLUTE, e este pacote for solto.

O STB detecta quando uma sessão termina, por meio de uma hora / data de fim de sessão que é incluída no registro de sinalização da sessão ou por meio do indicador "End- Of-Session" fornecido no cabeçalho do pacote FLUTE.

Portanto, cada STB verifica a integridade da FDT completa, que é a soma de todas as instâncias da FDT recebidas. Então, ele verifica se a FDT completa está corrompida ou se alguma das instâncias da FDT está ausente. Se a FDT completa não estiver corrompida, ainda pode ser necessário ativar um processo de recuperação para alguns arquivos, depen- dendo do seus estados de recepção. Por outro lado, se for descoberto que a FDT completa está corrompida, um STB transmite uma mensagem para o Servidor de Indexação indicando uma solicitação por uma FDT completa, depois do que, ele verifica se um processo de recu- peração é necessário para arquivos corrompidos.

Conteúdo do modo empurrar que estava ausente ou danificado pode ser recupera- do em uma fase do modo puxar normal, da forma supradescrita.

Se uma verificação de integridade na FDT completa ou em uma instância da FDT falhar a etapa S'10, então o STB transmite uma mensagem ao Servidor de Indexação indi- cando uma solicitação por uma FDT completa (respectivamente, uma instância da FDT, da forma ilustrada na figura 4).

Já que não supõe-se que o Servidor de Indexação tenha nenhum conhecimento do FLUTE1 o seguinte se aplica para permitir a recuperação de uma FDT completa (respecti- vamente, uma instância da FDT):

O STB mantém a FDT completa e instâncias da FDT na memória por um certo pe- ríodo, em particular, até a transferência dos novos conteúdos em uma nova sessão. Ele re- lata a correta recepção desta FDT completa (respectivamente, a instância da FDT) ao Ser- vidor de Indexação.

O STB que tem uma FDT completa corrompida (respectivamente, uma instância da FDT corrompida), pode interrogar o Servidor de Indexação (etapa S'11), que fornece ende- reços dos pares que podem transmitir uma versão não corrompida, etapas S'12, S'13.

O STB pode recuperar uma FDT completa não corrompida (respectivamente, uma instância da FDT não corrompida), etapas S'14, S'15, S'16, S'17, com seu valor de disper- são. Ele verifica sua integridade. Ele analisa a FDT completa para identificar quais arquivos da sessão no modo empurrar ele perdeu ou para reparar a instância da FDT corrompida. Então, ele verifica a integridade do arquivo associado. Se o STB detectar um arquivo ausen- te, ele começa uma recuperação de arquivo em relação ao arquivo ausente. Se o STB de- tectar um arquivo corrompido, ele começa uma recuperação de bloco.

Usando a informação dada nos relatórios que ele recebe dos STBs, o Servidor de Indexação atualiza continuamente sua base de dados. Em qualquer dado momento, ele po- de colocar o STB que precisa da recuperação de dados em relação com um STB par que pode fornecer a informação ausente.

Graças à duração da sessão dada pelo anúncio da sessão no registro SD&S, um STB sabe se ele perdeu uma sessão no modo empurrar. Um STB que perdeu uma sessão no modo empurrar pode interrogar o Servidor de Indexação em relação a uma FDT comple- ta, com o nome de arquivo "FDT", e prosseguir com uma recuperação de arquivo em relação aos arquivos ausentes.

Um STB que conecta quando uma sessão de distribuição de arquivo está em an- damento ainda pode adquirir uma parte do conteúdo da sessão de difusão seletiva FLUTE. Para obter os arquivos ausentes na sessão FLUTE, ele espera pelo fim da sessão para rea- lizar uma recuperação de FDT "completa" e para obter os arquivos ausentes dos pares.

Em um ambiente de transferência de arquivo de vídeo, a combinação dos métodos de puxar e empurrar fornece melhor modelo de distribuição. Uma política de distribuição pode ser como segue. Filmes que são relativamente populares podem ser propostos no mo- do empurrar, enquanto outros filmes que são menos demandados podem ser propostos no modo puxar. Quando o conjunto de filmes no modo empurrar for substituído por um novo conjunto, o conjunto antigo ingressa no conjunto de filmes disponível no modo puxar. Por outro lado, o Servidor de Indexação pode indicar ao Servidor de Conteúdo que é interessante comutar o modo de distribuição de alguns filmes do modo puxar para o modo empurrar, ou vice-versa, de acordo com as estatísticas das demandas que os Servidores de Indexação podem reunir.

Para uma entidade de monitoramento ou de gerenciamento, Servidores de Indexa- ção oferecem a possibilidade de coletar estatísticas sobre a atividade de recuperação de arquivo. Esta informação é usada por um operador para monitorar ou para adaptar a estra- tégia de distribuição dinamicamente. Este último pode consistir no planejamento de uma sessão extra da distribuição no modo empurrar ou na adição de FEC. Outras ações podem incluir mudar a largura de banda alocada para transferência da distribuição do arquivo.

Aqui, a referência a "uma modalidade" ou "umas modalidades" significa que um re- curso, estrutura ou característica em particular descritos em conjunto com a modalidade podem ser incluídos em pelo menos uma implementação da invenção. As aparições da fra- se "em uma modalidade" em vários locais da especificação não estão, todas, necessaria- mente se referindo à mesma modalidade, nem são as modalidades separadas ou alternati- vas, necessariamente, mutuamente exclusivas de outras modalidades.

Números de referência que aparecem nas reivindicações são dados a título de ilus- tração somente, e não devem ter efeito de limitação no escopo das reivindicações.

Claims

1. Método para transferir conteúdo em um sistema de comunicação (10) que com- preende um primeiro terminal (1), pelo menos um segundo terminal (2) e um servidor de conteúdo (5, 8), CARACTERIZADO pelo fato de que o dito método compreende, no nível do primeiro terminal, as etapas de: - transferir conteúdo tanto em um modo puxar do dito servidor de conteúdo ou pelo menos do dito segundo terminal quanto em um modo empurrar do dito servidor de conteúdo; e - comutar ininterruptamente entre os ditos modos para continuar transferindo o dito conteúdo.

2. Método, de acordo com a reivindicação 1, CARACTERIZADO pelo fato de que compreende as etapas de: - transferir conteúdo em um modo empurrar; e - continuar transferindo o dito conteúdo em um modo puxar quando o dito modo empurrar parar no dito servidor de conteúdo.

3. Método, de acordo com a reivindicação 1, CARACTERIZADO pelo fato de que compreende as etapas de: - transferir conteúdo em um modo puxar; e - continuar transferindo o dito conteúdo em um modo empurrar quando o dito modo empurrar começar no dito servidor de conteúdo.

4. Método, de acordo com a reivindicação 2, CARACTERIZADO pelo fato de que compreende as etapas de: - receber o conteúdo no modo empurrar em uma distribuição de sessão de acordo com o protocolo FLUTE; e - receber informação em uma Tabela de Distribuição de Arquivo, FDT, durante a distribuição de sessão, que permite comutar para um modo puxar.

5. Método, de acordo com a reivindicação 4, CARACTERIZADO pelo fato de que compreende as etapas de: - verificar a integridade da instância da FDT; - indicar a um Servidor de Indexação (6) se a instância da FDT foi recebida com su- cesso ou não; e - indicar ao dito Servidor de Indexação se o arquivo associado com a instância da FDT foi recebido com sucesso ou não.

6. Método, de acordo com a reivindicação 5, CARACTERIZADO pelo fato de que compreende, durante a detecção de uma instância da FDT corrompida, as etapas de: - esperar pelo fim da distribuição do arquivo; e - realizar a reparação de uma instância da FDT em um modo puxar.

7. Método, de acordo com a reivindicação 5, CARACTERIZADO pelo fato de que compreende, durante a detecção de uma FDT completa corrompida, as etapas de: - esperar pelo fim da distribuição de sessão; e - realizar uma reparação de FDT completa em um modo puxar.

8. Método, de acordo com a reivindicação 3, CARACTERIZADO pelo fato de que compreende as etapas de: - receber o conteúdo no modo puxar de acordo com um protocolo ponto a ponto; e - receber um arquivo de metainformação ponto a ponto que compreende informa- ção que permite comutar para um modo empurrar.

9. Terminal (1, 2, 3), CARACTERIZADO pelo fato de que compreende: - dispositivo (1.6) para transferir conteúdo em um modo empurrar; - dispositivo (1.5) para transferir conteúdo no modo puxar; e - dispositivo (1.7) para comutar ininterruptamente de um modo para o outro modo.