System and method for combining pull and push modes

(54) Title: SYSTEM AND METHOD TO COMBINE PULL AND PUSH MODES (30) Unionist Priority: 12/01/2007 ep 07300727.0 (73) Holder (s): Thomson Licensing (72) Inventor (s): Eric Gautier, François Gerard , Willem Lubbers (74) Attorney (s): Ricardo Pinho (86) International Request: pct EP2008050291 of 11/01/2008 (57) Summary: system and method for combining PULL AND PUSH modes. The present invention relates to a method for transferring content using a combination of push and pull modes. In a Communication System (10) comprising a first terminal (1), at least a second terminal (2) and a content server (5, 8), the invention relates to a method for transferring content that comprises, at the first terminal level, the steps of transferring content both in a pull mode from the content server or at least the second terminal and in a push mode from the content server, and continuously switch between modes to continue transferring content.

(87) International Publication: wo 2008 / 084096of 17/07/2008

<img file="BRPI0806326A2_D0001.tif" />

Communication system

<img file="BRPI0806326A2_D0002.tif" />

<img file="BRPI0806326A2_D0003.tif" />

“SYSTEM AND METHOD FOR COMBINING PULL AND PUSH WAYS

The present invention relates, in general, to the transfer of content and, in particular, to the use of a combination of pulling and pushing methods.

This section aims to introduce the reader to various aspects of the technology, which may be related to various aspects of the present invention which are described and / or claimed below. This discussion is believed to be useful in providing the reader with background information to facilitate a better understanding of the various aspects of the present invention. Thus, it is understood that these statements should be read in this light, and not as admissions of prior technology.

A distribution of content between a server and multiple receivers requires configuring a point-to-point connection between the server and each receiver or a multipoint connection. The point-to-point connection allows you to distribute the content in a unicast device to each receiver and provide a robust distribution. Henceforth, this is called the pull mode, and customers are usually active initiators. However, with a significant number of receivers, it requires heavy management of all connections. It can also significantly increase traffic on the network. Multicast distribution provides less network load with less robust distribution. Henceforth, this is called the push mode.

A service operator who manages the server cannot accurately predict the behavior of the receivers. In a push mode content distribution session, receivers can be excluded from complete or partial content transfer for the following reasons: receivers are disabled during push mode distribution; receivers are activated when push delivery is in progress; all reserved bandwidth is not available for push distribution, for example, the STB user is watching one program while recording another; receivers are short of storage space at the time of delivery in push mode; receivers are using all the CPU capacity at the time of distribution in push mode; networks cannot manage multicast traffic; etc. In order to optimize bandwidth, the operator may need to choose to keep the session in push or stop mode. Stopping the session in push mode allows the operator to free the network from a large amount of traffic and that recipients who have lost content can retrieve it using a recovery mode. A recovery method has been defined in patent application EP 06291464.3. On the other hand, in pull mode, the operator may need to face spikes in content demands. So, it may be more efficient for the operator to optimize the use of network bandwidth and the implementation delay by multicast this content in push mode instead of using pull mode.

The present invention relates to a method for efficiently switching between the pull mode and the push mode.

For this purpose, the invention relates to a method for transferring content, in a communication system comprising a first terminal, at least a second terminal and a content server. The method comprises, at the first terminal level, the steps of transferring content both in a pull mode from the content server and at least the second terminal and in a push mode from the content server, and of switching seamlessly between modes to continue to content transfer.

In this context, uninterruptedly means that the terminal continuously switches from one mode to the other mode, without having to request any additional information.

According to one embodiment, the method comprises the steps of transferring content in a push mode, and of continuing to transfer content in a pull mode when the push mode stops on the content server.

When the operator stops the push mode session, the terminal continues the transfer without much interruption. He acquired enough information during the push mode session to switch to the pull mode transfer and manage it.

According to another embodiment, the method comprises the steps of transferring content in a pull mode, and of continuing to transfer content in a push mode when the push mode starts on the content server.

According to one modality, the method comprises the steps of receiving the content in the push mode in a session distribution according to the FLUTE protocol, and of receiving information in a File Distribution Table, FDT, during the session distribution that allows switching to a pull mode.

The FDT comprises additional information needed to switch to pull without interruption. When the mode is pushed to, the terminal does not need to retrieve any additional information. He has already received relevant information from the FDT to switch to pull mode.

According to one modality, the method comprises the steps of verifying the integrity of the FDT instance, indicating to an index server whether the FDT instance was successfully received or not, and indicating to the index server whether the associated file with the FDT instance was received successfully or not.

According to one modality, the method comprises, during the detection of an instance of the FDT that has been corrupted, the steps of waiting for the end of the distribution of the file, and of carrying out a repair in the instance of the FDT in a pull mode.

According to one embodiment, the method comprises, during the detection of a corrupted complete FDT, the steps of waiting for the end of the session distribution, and of making a repair on the complete FDT in a pull mode.

According to one modality, the method comprises the steps of receiving the content in the pull mode according to a point-to-point protocol, and of receiving a point-to-point metadata file that comprises information that allows switching to a push mode.

The present invention also relates to a terminal comprising a device for transferring content in a push mode, a device for transferring content in a pull mode, and a device for switching seamlessly from one mode to the other mode.

Another object of the invention is a computer program product which comprises instructions in program code to perform the steps of the process according to the invention when this program is run on a computer. "Computer program product" means a computer program medium that may consist not only of a storage space containing the program, such as a floppy disk or cassette, but also of a signal, such as a signal electrical or optical.

Certain aspects of scope commensurate with the disclosed modalities are presented below. It is understood that these aspects are presented merely to provide the reader with a summary of certain forms that the invention can take, and that these aspects are not intended to limit the scope of the invention. In fact, the invention can cover a variety of aspects that may not be presented below.

The invention will be better understood and illustrated by means of the following modality and examples of execution, in no way limiting, in relation to the attached drawings, in which:

figure 1 is a block diagram of a system in accordance with the modality;

figure 2 represents a terminal according to the modality;

figure 3 is a flow chart illustrating how to pull; and

- figure 4 is a flow chart showing a combination of push and pull modes.

In figures 1 and 2, the blocks represented are purely functional entities, which do not necessarily correspond to physically separate entities. Namely, they can be developed in the form of software or be implemented in one or several integrated circuits.

Figure 1 represents the architecture of the communication system 10 according to the modality for distributing content. Terminals 1,2,3 comprise client applications. In particular, they understand the function of a frequency signal converter (STB). Then, in the mode, the terminal is an STB, but the mode is not limited to such terminals. It is applicable to a device that comprises a client application to transfer data from a content server.

The terminal also comprises a device for transferring content in a push mode and a device for transferring content in a pull mode. It performs the pulling and pushing functions as described below.

The system comprises a content server in push mode 5 and a content server in pull mode 8. The content server in pull mode is adapted to distribute content in a pull mode. It comprises a device for establishing a point-to-point connection with multiple clients. The push mode content server is adapted to distribute the content in a push mode. Certainly, these servers can be included on the same device.

The role of Indexing Server 6 is to place STBs even in relation to each other to complete the repair or recovery of the content. The role of the Indexing Server is to place pairs that need to retrieve files, or parts of files, in relation to pairs that can provide the missing information. The Indexing Server does not store any content files, it acts as a centralized index to store information about the location of the files. The pull mode protocol requires that the Index Server be kept informed, by each STB, about the transfer status of the content. According to the modality, the system comprises only one Indexing Server. A network can have several Indexing Servers to optimize access, for example, by geographic region or by content type. The same Index Server is used in a push mode environment, as well as in a pull mode environment.

Service discovery server 7, hereinafter referred to as SD&amp;S, is adapted to perform the service discovery and selection mechanism, as indicated in the ETSI TS 102 034 V1.2.1 (2006-09) Digital Video Broadcast (DVB) standard , DVB Services Based on MPEG-2 Transport over IP Based Networks.

According to the modality, the same SD&amp;S server is used in the PUSH mode environment as well as in the PULL mode.

Figure 2 represents the building blocks of a terminal according to the modality. The terminal comprises storage device 1.1, communication device 1.2, processing device 1.3 and an internal bus 1.4. The storage device is intended to store a program that allows the terminal to transfer the file in a push or pull mode. Thus, the terminal comprises transfer device in push mode 1.6 and transfer device in pull mode 1.5. It comprises a device for switching 1.7 from one mode to the other mode.

The method of pulling is now described. It is based on a point-to-point strategy, referred to as P2P.

In order to perform a pull method, first, the terminal performs the discovery phase of the Indexing Server address. An STB finds content for download by browsing a catalog of content available for download. The catalog address is found using the DVB-IP Broadband Content Guide Register, as specified in ETSI TS 102 034 V1.2.1 (2006-09) and ETSI TS 102 539 V1.1.1,

Digital Video Broadcast (DVB), Transport of information from the Broadband Content Guide (BCG) by Internet Protocol (IP), which describes the transport and signaling of content guides in the context of DVB-IP. The terminal finds the address of an Indexing Server in the catalog. Certainly, the address of the Indexing Server can be found by other means, such as a register that offers transfer of content that is distributed by DVB-IP / SD&amp;S signaling.

To improve the ability to transfer large content, each content file is divided into smaller blocks. Then, the pairs can receive and verify the blocks of content and then exchange these blocks before receiving the content in whole or in part. A scatter code is calculated for each block. The metadata, as indicated in table 1, is stored as a file on the Content Server. Metadata comprises all the information necessary to carry out a point-to-point file exchange. The spreading operation can be done by the content server.

The following table represents the content metadata according to the modality. The TSI and TOI fields are defined in the FLUTE protocol. They are optional. They are used here to support uninterrupted switching between pull and push modes. The Content-Block-Length, Content-Block-Digests, File-Name, File-Length, File-Digest, File-Block-Length and File-Block-Digests fields are the minimum metadata required for a P2P protocol.

<td>Name</td><td>description</td>

<td>Multi-Files-Attributes</td><td>Attributes related to multi-files</td>

<td>Meta-information-length</td><td>Metadata file size</td>

<td>Content-Type</td><td>File content type</td>

<td>Content-Encoding</td><td>Compression</td>

<td>Client-ld</td><td>To target the transfer of content, depending on the customer's identifier (HW, SW, Profile, etc ...)</td>

<td>Content-Block-Length</td><td>Block size</td>

<td>Content-Block-Digests (one per block)</td><td>Block dispersion (SHA1 ...)</td>

<td>File-Attributes (one per file)</td><td>Attributes related to the file itself</td>

<td>File-Type</td><td>MIME media type of the file</td>

<td>File-Encoding</td><td>Compression</td>

<td>Client-ld</td><td>To target file transfer, depending on the customer's identifier (HW, SW, Profile, etc ...)</td>

<td>TSI</td><td>Transport Session Identifier. Identifies exclusively a FLUTE session for a given IP source address</td>

<td>TOI</td><td>Transport Object Identifier</td>

<td>File-Name</td><td>Identification and location of the file for transfer, for example, URI</td>

<td>File-Length</td><td>File size</td>

<td>File-Digest</td><td>File scattering (e.g., SHA1 ...)</td>

<td>File-Block-Length</td><td>Block size</td>

<td>File-Block-Digests (one per block)</td><td>Block dispersion (SHA1 ...)</td>

<td>Metâ-Info-Digest</td><td></td>

<td>Meta-Info-Digest</td><td>Scattering of Metadata (eg MD5, SHA1 ...)</td>

Table 1

The Meta-Info-Digest field can be used to transmit an RSA signature to allow authentication of the metadata file.

Then, the method for transferring file is as follows, as described in the figure

3.

Step S1. STB 1 transmits a request for chosen content to the Index Server.

Step S2. The Indexing Server responds to the STB with the address of an even STB 2 that can provide metadata for the content. Certainly, the Indexing Server can supply the address of several pairs.

STB 1 initiates a connection with the indicated pair, Step S3. It retrieves the metadata file in Step S4, checks its integrity in Step S5, stores this file and notifies the Indexing Server of the receipt of the metadata, Step S6. STB 1 keeps this file in memory until the content associated with it is deleted.

With this metadata file, the STB can request any range of bytes in a block from the other pairs and check the integrity of the received data. After the STB receives the metadata file, it can transfer one or more files or blocks from one or more files.

The STB requests a block from the Indexing Server. Step 7. Certainly, the STB can request several blocks at the same time. It transmits the block number and the file identifier (this can be the file name). The file ID is required when multiple files are transferred concurrently.

The Indexing Server returns a peer address that can provide the block of content, Step 8.

The STB initiates a connection with the indicated pair (s), Step 9, retrieves the content block (s), Step 10, and verifies their integrity (s), Step 11 .

The STB indicates the status of the block transfer, in terms of success or failure, to the Index Server, Step 12.

The client can transmit new requests by other blocks to the Indexing Server until it has transferred the complete content.

Using the information given in the reports it receives from the STBs, the Indexing Server continuously updates its database. At any given time, it can place an STB that needs data recovery in relation to an even STB that can provide the missing information.

Thanks to the TSI and TOI fields, the terminal can switch continuously to push mode to transfer the file.

In figure 3, the pair that provides the content block is the same pair that provides the content metadata. Certainly, this may be another pair.

In addition, the Index Server can return the address of more than one pair that can provide the block of content. Then, the STB will possibly connect in more than one pair.

An Indexing Server may have information that the requested content or metadata file cannot be provided by any of the even STBs.

In this case, it can provide the address of a Content Server that can distribute the content directly. In order to avoid overloading the Content Server with requests for content, the Index Server can serve only a group of even STBs. It puts the other STB on hold and then tells them the addresses of the group of peer STBs that successfully transferred the content.

Alternatively, the Index Server can address the request to another Index Server or to a “Super” Index Server. If it finds the requested information, the Indexing Server can store the information in its database and respond positively to the STB.

An Indexing Server can provide multiple addresses for the same content. The content can be propagated in several even STBs, that is, none of the even STBs has the entire content, but the total content can be constructed from the partial contents resident in the even STBs. The Indexing Server can also indicate alternate STBs that can provide the requested content as a whole or in part, to give the STB the opportunity to retrieve content from another pair if it finds that the transfer speed is too slow or if the pair prove unavailable.

On the other hand, an Indexing Server can be fed with algorithms that allow intelligent pair selection, for example, based on statistics on the number of successful transfers from a pair.

The method for delivery in push mode is now described. Push mode distribution is based on File Distribution in Unidirectional Transport Protocol, referred to as FLUTE, as specified in RFC 3926. Push mode distribution comprises a retrieval mechanism that uses the aforementioned point-to-point mechanism.

The FLUTE protocol defines the transmission of multicast objects and the associated descriptor tables. It defines a File Distribution Table, named FDT, which contains information on the files that need to be transmitted in the current session. The FLUTE protocol transmits the FDT from the content server in a multicast mode to all STBs. FLUTE defines several transmission modes, such as a complete FDT followed by multiple files or series of FDT instances (intermediate FDTs) followed by their associated files. The latter is especially suitable for transmitting huge video files. It allows a receiver to check whether an object, or a file, has been correctly received before the end of the session is reached. The first mode of transmission is very convenient in an environment where small files are transmitted. A complete FDT is built from all FDT instances in the same session.

According to the modality, the FLUTE FDT comprises the specific Point to Point metadata (comprising block length and block dispersion), as indicated in the following Table 2. Then, it is possible, during a content transfer, to switch continuously from one protocol to the other. In fact, receivers who did not transfer the content completely or completely at the end of a FLUTE multicast push mode can continuously switch to the Point to Point pull mode and transfer the missing blocks thanks to the information in the FDT that allows they know exactly the missing content units. Similarly, a receiver that has started transferring content using the Point-to-Point pull mode can continuously switch to a push mode using the FDT, which gives the receiver the information necessary to retrieve the missing blocks from the file with the push mode.

The following table represents the FLUTE File Distribution Table, including P2P metadata according to the modality.

<td>Element / Attribute Name</td><td>Element / Attribute Description</td>

<td>FDT-I nstances-Attributes</td><td>Common attributes for all files described by FDT instance</td>

<td>Expiration-Time</td><td>FDT instance expiration time</td>

<td>Send-Complete</td><td>Describes whether the FDT instance is complete or not (for example, describes all files to be distributed in the session)</td>

<td>Multi-Files-Delivery-Attributes</td><td>Attributes related to the distribution of multi-files</td>

<td>FEC-OTI-FEC-Encoding-ID</td><td>Identification of the FEC algorithm</td>

<td>FEC-OTI-FEC-Instance-ID</td><td>FDT instance that depends on the identification of the FEC algorithm</td>

<td>FEC-OTI-Maximum-Source- Block-Length</td><td>The maximum number of font symbols per block of source</td>

<td>FEC-OTI-Encoding-Symbol-Length</td><td>Length of encoding symbols, in bytes</td>

<td>FEC-OTI-MaxNumber-Of- Encoding-Symbols</td><td>Maximum number of encoding symbols that can be be generated for a source block</td>

<td>Multi-Files-Attributes Λ. , 3 Λ. -JK Mi -K i «# · &lt;*</td><td>Attributes related to multi-files</td>

<td>Content-Type</td><td>File content type</td>

<td>Content-Encoding</td><td>Compression...</td>

<td>Client-ld</td><td>To target the transfer of content, depending on the customer's identifier (HW, SW, Profile, etc ...)</td>

<td>Content-Block-Length</td><td>Block size</td>

<td>Content-Block-Digests (one per block)</td><td>Block dispersion (SHA1 ...)</td>

<td>Download-Files-Attributes (a per file)</td><td></td>

<td>File-Delivery-Attributès</td><td>Attributes related to file distribution</td>

<td>TOI</td><td>Transport Object Identifier</td>

<td>Transfert-Length</td><td>Size of the transport object carrying the file</td>

<td>Bandwidth-Requirement</td><td>Aggregate packet transmission rate for all the channels</td>

<td>FEC-OTI-FEC-Encoding-ID</td><td>Identification of the FEC algorithm</td>

<td>FEC-OTI-FEC-Instance-ID</td><td>FDT instance that depends on the identification of the FEC algorithm</td>

<td>FEC-OTI-Maximum-Source- Block-Length</td><td>The maximum number of font symbols per block of source</td>

<td>FEC-OTI-Encoding-Symbol-Length</td><td>Length of encoding symbols, in bytes</td>

<td>FEC-OTI-MaxNumber-Of- Encoding-Symbols</td><td>Maximum number of encoding symbols that can be be generated for a source block</td>

<td>File-Attributes</td><td>Attributes related to the file itself</td>

<td>File-Type</td><td>MIME media type of the file</td>

<td>File-Encoding</td><td>Compression</td>

<td>Client-ld</td><td>To target the transfer of content, depending on the customer's identifier (HW, SW, Profile, etc ...)</td>

<td>File-Name</td><td>Identification and location of the file for transfer, for example, URI</td>

<td>File-Length</td><td>File size</td>

<td>File-Digest</td><td>File scattering (e.g. MD5, SHA1 ...)</td>

<td>File-Block-Length</td><td>Block size</td>

<td>File-Block-Digests (one per block)</td><td>Block dispersion (SHA1 ...)</td>

<td>FDT-Instance-Digest</td><td></td>

<td>FDT-Instance-Digest</td><td>Scattering of the FDT instance (for example, MD5, SHA1 ...)</td>

<td>FDT-Complete-Digest (only in the last instance of FDT) _?</td><td></td>

<td>Complete-FDT-Digest</td><td>Dispersion of the complete FDT (eg MD5, SHA1 ...)</td>

Table 2

The Content-Block-Length, Content-Block-Digests, File-Name, File-Length, File-Digest, File-Block-Length and File-Block-Digests fields are the minimum metadata required for a P2P protocol. A file is cut into several blocks.

The Complete-FDT-Digest field can be used to transmit an RSA signature to allow full FDT authentication.

In order to transfer content with a push method, a customer performs a discovery phase of the content transfer session in the push mode. A client STB subscribes to a transfer offer in push mode. As part of the subscription, it obtains the distribution address where the service signal is transmitted by the SD&amp;S server through the DVB-IP / SD&amp;S mechanism. The STB then monitors the dedicated multicast address. It discovers a record that offers transfer of DVB-IP content.

In this record that offers content transfer, it finds the start / end date / time of the content transfer session, as well as other information, such as the addresses and multicast ports where the content is distributed and the address of the Indexing Server on which it depends. The SD&amp;S record file according to the modality is indicated in the following Table 3.

<td>Element / Attribute Name</td><td>Element / Attribute Description</td>

<td>@DomainName</td><td>An Internet DNS domain name registered by the Service Provider that uniquely identifies the Service Provider</td>

<td>@Version</td><td>Version of the registry offering DVB-IP, the number of the</td>

<td></td><td>health should be increased every time a registry change that offers DVB-IP</td>

<td>ContentDownloadOffering type (one * per list of Content Transfer):</td><td>ContentDownloadServiceDiscovery / ContentDownlad- ServiceList</td>

<td>Catalog @ ld</td><td>This Id is allocated by the Service Provider</td>

<td>Name</td><td>Name of the catalog that offers Content Transfer for display in one or more languages; it's allowed one name per language code, and at least one language must be provided (though not necessarily more than one)</td>

<td>Description</td><td>Description of the catalog offering General Content Transfer for potential display in one or more languages; a language code description</td>

<td>ContentReleaseTime</td><td>Date and time when the new content becomes available for be exchanged for old content</td>

<td>Clientld</td><td>To target the content transfer session that depends on the customer identifier. This can include the client's hardware version, client software version, client profile, regionalization ... Also specified in the FDT to specifically target each transfer file, depending on the user's profile</td>

<td>ServiceLocation type (one per Content Transfer Service, for example, Session)</td><td>0 location where the Content Transfer Service can be found 1 ^ 1</td>

<td>ProtocolType</td><td>FLUTE or Other</td>

<td>Session ID</td><td>Uniquely identifies a FLUTE session for a</td>

<td>Transport (TSI)</td><td>given IP source address</td>

<td>IPMulticastAddress @ Source</td><td>One IP transmitter address per content distribution session</td>

<td>IPMulticastAddress @ Address</td><td>Multicast address</td>

<td>Number of Channels in the</td><td>Use of multiple LCT channels to distribute content</td>

<td>session</td><td>in a single FLUTE session</td>

<td>IPMulticastPort number for</td><td>Port number corresponding to each channel number</td>

<td>each channel in the session</td><td></td>

<td>Start data and time of the</td><td>Start Date and Time of the Distribution Session</td>

<td>content delivery session</td><td>Content in Selective Diffusion</td>

<td>End data and time of the content delivery session</td><td>End date and time of Multicast Content Distribution Session</td>

<td>FLUTE packet Reception timeout</td><td>Time to receive at least one FLUTE package on session level</td>

<td>File Delivery Table (FDT) reception timeout</td><td>Time to receive at least one instance of the FDT at the session level</td>

<td>Object (for example, file) reception timeout</td><td>Time to receive at least one File at the session</td>

<td>BandwidthRequirement</td><td>Maximum bandwidth to be used by the session</td>

<td>RecoveryMòde type</td><td>Information considering the recovery mode</td>

<td>P2P IndexServer URI</td><td>Identification and location of the P2P Index Server (URI)</td>

<td>P2P IndexServerBackup URI</td><td>List of index backup servers (URI)</td>

<td>Current Session File Repair OffsetTime</td><td>The time the customer must wait after the end of the file distribution or file distribution session content (depending on FLUTE transmission mode) to begin the file recovery procedure</td>

<td>Current Session File Repair RandomTimePeriod</td><td>The duration of the time window during which a customer should calculate a random time to start the file recovery procedure</td>

<td>Integrity type</td><td></td>

<td>AnnouncementDigest</td><td>Ad build (Scatter, CRC ...)</td>

Table 3

The AnnouncementDigest field can be used to transmit an RSA signature to allow authentication of the announcement.

As illustrated in figure 4, using the information acquired in the discovery phase5, an STB monitors the multicast address to which the push session content is distributed, step S'1.

Each FDT instance contains several scatter codes that allow the verification of its own integrity and the integrity of the blocks of the file associated with it. This information corresponds to the metadata file, as described for the pull mode. As for the pull mode, the STB stores the metadata file, while it maintains the associated content. Then, the file can subsequently be used to serve peers in pull mode.

The STB detects when the distribution of a file ends using the “End-Of-Transmission-File” indicator of the FLUTE protocol. From this moment, each STB can verify the integrity of the FDT instance, steps S'2, S'3. After this check, each STB transmits a message to the Index Server indicating whether it has received the FDT instance, steps S'4, S'5.

Then, if the integrity check of the FDT instance is successful, the STB checks the integrity of the blocks of the file associated with the FDT instance (step S'6, S'7) and transmits a report to the Indexing Server regarding to the associated file, steps S'8, S'9. This report contains information about the blocks that were correctly received, as well as about the file identifier. The Indexing Server stores this information and updates its database. For the part of these files that is missing, an STB performs a file recovery, as described below.

If the integrity check of the FDT instance fails, a corrupted FDT instance does not allow the STB to check the integrity of the file blocks associated with it, because this information is contained in the FDT instance. The STB stores the file that follows the corrupted FDT and waits for the detection of the end of the file distribution to begin repairing the FDT instance, as described below. FLUTE packages that contain a block include an identifier called TOI, which is unique for each file. An FDT also contains this identifier, which allows you to relate blocks to a file.

The last FDT instance of the session also contains a scatter code calculated on the total of all FDT instances that are part of the session. This allows the verification of the integrity of the complete FDT and the knowledge if the instances of the FDT are absent. This can be used to detect the case where an FDT instance is distributed only by a FLUTE package, and that package is released.

The STB detects when a session ends, by means of a session end time / date that is included in the session signaling record or by means of the “EndOf-Session” indicator provided in the FLUTE package header.

Therefore, each STB verifies the integrity of the complete FDT, which is the sum of all received FDT instances. It then checks whether the full FDT is corrupted or if any of the FDT instances are missing. If the complete FDT is not corrupted, it may still be necessary to activate a recovery process for some files, depending on their reception status. On the other hand, if it is found that the complete FDT is corrupted, an STB transmits a message to the Index Server indicating a request for a complete FDT, after which, it checks whether a recovery process is necessary for corrupted files.

Push mode content that was missing or damaged can be recovered in a normal pull phase, as described above.

If an integrity check on the complete FDT or an instance of the FDT fails step S'10, then the STB transmits a message to the Index Server indicating a request for a complete FDT (respectively, an instance of the FDT, as illustrated in figure 4).

Since the Indexing Server is not supposed to have any knowledge of FLUTE, the following applies to allow the recovery of a complete FDT (respectively, an instance of the FDT):

The STB keeps the complete FDT and FDT instances in memory for a certain period, in particular, until new content is transferred in a new session. It reports the correct reception of this complete FDT (respectively, the FDT instance) to the Index Server.

The STB that has a complete corrupted FDT (respectively, a corrupted FDT instance), can interrogate the Index Server (step S'11), which provides addresses of peers that can transmit an uncorrupted version, steps S'12, S '13.

The STB can recover a complete uncorrupted FDT (respectively, an uncorrupted FDT instance), steps S'14, S'15, S'16, S'17, with its dispersion value. He checks your integrity. It analyzes the complete FDT to identify which files in the push mode session it lost or to repair the corrupted FDT instance. It then checks the integrity of the associated file. If the STB detects a missing file, it starts a file recovery for the missing file. If the STB detects a corrupted file, it starts a block recovery.

Using the information given in the reports it receives from the STBs, the Indexing Server continuously updates its database. At any given time, it can place the STB that needs data recovery in relation to a peer STB that can provide the missing information.

Thanks to the length of the session given by the announcement of the session in the SD&amp;S record, an STB knows if it missed a push mode session. An STB that missed a push session can interrogate the Index Server for a complete FDT, with the file name “FDT”, and proceed with a file recovery for the missing files.

An STB that connects when a file distribution session is in progress can still acquire some of the content of the FLUTE multicast session. To obtain the missing files in the FLUTE session, it waits for the end of the session to perform a “full” FDT recovery and to obtain the missing files from the peers.

In a video file transfer environment, the combination of pulling and pushing methods provides a better distribution model. A distribution policy can be as follows. Movies that are relatively popular can be offered in push mode, while other films that are less demanded can be offered in pull mode. When the set of films in the push mode is replaced by a new set, the old set joins the set of films available in the pull mode.

On the other hand, the Indexing Server can indicate to the Content Server that it is interesting to switch the distribution mode of some films from the pull mode to the push mode, or vice versa, according to the demand statistics that the Index Servers can gather.

For a monitoring or management entity, Indexing Servers offer the possibility to collect statistics on file recovery activity. This information is used by an operator to dynamically monitor or adapt the distribution strategy. The latter can consist of planning an extra push distribution session or adding FEC. Other actions may include changing the bandwidth allocated for transferring the file distribution.

Here, the reference to "a modality" or "some modalities" means that a particular feature, structure or feature described in conjunction with the modality can be included in at least one implementation of the invention. The appearances of the phrase “in one modality” at various locations in the specification are not all necessarily referring to the same modality, nor are the separate or alternative modalities necessarily mutually exclusive from other modalities.

Reference numbers appearing in the claims are given by way of illustration only, and should not have a limiting effect on the scope of the claims.