WO2007113447A1

WO2007113447A1 - Method and device for transmitting and receiving data packets concerning a file transmitted cyclically in multicast mode

Info

Publication number: WO2007113447A1
Application number: PCT/FR2007/051049
Authority: WO
Inventors: Lise George; Halim Bendiabdallah
Original assignee: France Telecom
Priority date: 2006-03-31
Filing date: 2007-04-02
Publication date: 2007-10-11
Also published as: FR2899410A1; EP2005647A1

Abstract

The invention concerns a method for receiving data packets concerning a file, the file consisting of a plurality of packets, the method including a step of receiving (10, 46) packets transmitted cyclically in mulicast mode. The invention is characterized in that the method includes the following steps: detecting improperly received packets among the file packets which have been transmitted; for at least part of the packets identified as being improperly received: transmitting (77) at least one request in unicast mode to obtain said packets; and receiving said packets (78).

Description

Method and device for transmitting and receiving data packets relating to a cyclically transmitted file in multicast mode

The invention relates to a method and a system for transmitting data packets relating to a file, said packets being cyclically transmitted in multicast mode, and a method and a device for receiving such packets.

Currently, companies and providers of content, data, programs, including updates or new versions of software, video games, video-on-demand deferred time, appeal, so almost necessary, to the exchange of data and the transmission of data via the IP network ("Internet Protocol" in English terminology). The transmission and downloading of these data are carried out today, both on fixed networks and on mobile networks. Among the fixed networks, there is the IP network which includes the Internet network.

A non-limiting example of a data distribution system is peer-to-peer, also known as peer-to-peer, which allows the sharing of data between computers. a network.

Currently, data downloads, that is, data transmission and reception are essentially in unicast mode. The term "unicast" defines a point-to-point network connection. Thus, "unicast" means making two computers communicate with each other, each identified by a unique network address. To do this, the data packets are routed on the network according to the address of the encapsulated recipient in the transmitted frame. Normally, only the recipient intercepts and decodes the packet addressed to him.

These downloads are standardized and are made, for example, by the FTP protocol ("File Transfer Protocol" in English terminology) or by the HTTP protocol ("HyperText Transfer Protocol" in English terminology). These are protocols for the transfer of data over a TCP / IP network (Transmission Control Protocol / Internet Protocol in English terminology).

These protocols, in general, ensure the integrity of the data received, including a control of data transmission errors.

However, a first disadvantage of these download mechanisms lies in the fact that, during massive transmissions, the content broadcast server can be saturated due to the large number of simultaneous connections established with users.

In addition, these download mechanisms have the additional disadvantage of charging the network, or even saturate it, by circulating non-optimized large amounts of information.

Indeed, the use of a connection in unicast mode implies a strong redundancy of the transferred data.

These problems are encountered especially when making available data expected by a large number of users, such as a video game, an operating system update, music or other mediated content. Document US Pat. No. 6,256,673 discloses a method of broadcasting a file in multicast mode in which the contents of the file are continuously transmitted cyclically.

The "multicast" mode, unlike the "unicast" mode, makes it possible to simultaneously address a content to a plurality of recipient users, by means of a single sending.

Indeed, thanks to the multicast broadcasting technique, the broadcast server sends only once the data constituting the broadcast. The aforementioned data is duplicated by the routers of the network, dynamically, to reach authorized users who have requested it. The set of paths or paths followed by the data packets broadcast, from the server to the authorized users, form a multicast information broadcast tree whose root is the broadcast server, the various paths constituting the branches and the users constituting leaves of said tree.

At each access request of a new user, a new branch is added. With regard to multicast addressing, the multicast broadcasting mode uses a specific technique of multicast addressing.

According to this technique, a data packet that is part of a multicast broadcast has a destination IP address, called a "multicast address". All information carrier data packets belonging to the same broadcast bear the same destination multicast address.

While a unicast IP address identifies one and only one machine (or a user's workstation), a multicast IP address is used to identify a set (or group) of machines, namely all machines. able to access this broadcast.

According to the broadcasting method described in US Pat. No. 6,256,673, the content of the file is broadcast cyclically as long as a user has not been able to load all the packets allowing the reconstruction of the requested file. To do this, when a user wants to download a file, after querying the server, it starts broadcasting the content of the file. The file breaks down, for its emission, in a multitude of packets. These are identified relative to their relative position in the file which allows the user to rebuild the file. When a second user wants to get the same content, he connects to the same server. The file being broadcast, the second user receives data upon connection to the server, but this data received is not necessarily at the beginning of the file.

Also, the server, during the connection of the user, notes that it must issue the contents of the file again so that the second user receives all the packets forming the file.

Stopping the broadcast occurs when all users have had the opportunity to receive all the packages forming the file.

The use of the multicast mode and the cyclic transmission make it possible to optimize the quantity of data circulating on the network and, therefore, to reduce the saturation thereof.

However, this diffusion method has the following drawbacks.

Firstly, multicast transmission of data is performed without error checking. However, it has been observed that packets broadcast in multicast mode are sometimes lost or erroneous and a file containing erroneous or missing data is very often not usable by the user.

Then, the management of the broadcast cycles to be performed is managed by an information note indicating that an additional cycle must be performed when a user connects during the broadcast of the contents of a file. Thus, the download must be made in its entirety over at most two broadcast cycles.

The present invention aims to overcome at least one of the disadvantages of the techniques and processes of the aforementioned prior art. An object of the present invention is in particular a method for receiving data packets relating to a file, the file being composed of a plurality of packets, the method comprising a step of receiving cyclically transmitted packets in multicast mode, characterized in that the method comprises the following steps: detecting packets not correctly received from the packets of the file that have been transmitted; for at least part of the packets identified as not correctly received: sending at least one request in unicast mode to obtain said packets; and o receiving said packets.

The method of receiving data packets relating to a file according to the invention makes it possible, on the one hand, to receive these packets in multicast mode, the packets being transmitted in multicast mode and cyclically, and on the other hand, of receive packets not correctly received during multicast reception by means of a unicast connection.

In this way, the use of multicast mode optimizes the network load since the same content is sent to a plurality of clients.

Moreover, a check of the integrity of the received data and a detection of the non received packets are carried out and allow the detection of the packets not correctly received.

A file containing incorrect data or missing information is often unusable. To solve this problem, the invention proposes to download these data by a connection in unicast mode, that is to say in point-to-point mode with a content server. According to the invention, the management of these incorrectly received packets is also performed so as to reduce the amount of information transmitted on the network and the time required to obtain all the packets forming the file for the client.

According to one characteristic, the packets being identified by their relative position in the file, the method further comprises a step of storing the received packets at their relative position in the file.

The reception of the packets relating to a file can begin while the emission of the file is already in progress. The storage of the data contained in the packets must, however, be carried out at the actual location of these data during reception. To do this, the packets include information identifying the relative position in the file of the data transported by these packets. According to one characteristic, the packets comprise at least one data integrity verification information, said at least one data integrity verification information being able to, for example, comprise a cyclic redundancy check code. According to this characteristic, the integrity of the data received can be verified. This check allows the detection of erroneously received packets, also known as incorrectly received packets.

According to one characteristic, the step of transmitting said at least one request in unicast mode is subject to a prior decision step whose realization depends on a predetermined criterion.

The predetermined criterion is, for example, a function of the number of packets identified as not correctly received and the transmission cycle period of the file.

According to this characteristic, the mode of reception of the packets identified as not correctly received is determined.

According to one characteristic, the method comprises, prior to the step of receiving packets, a step of sending, to a resource manager, a request to obtain said file.

According to another characteristic, the method comprises, prior to the step of sending a request to obtain said file, a step of establishing a connection in unicast mode with the resource manager.

Indeed, a link established in unicast mode between the client and the resource manager allows the latter to control all clients currently receiving the broadcast file.

According to another characteristic, the method comprises a step of receiving, from the resource manager, receiving parameters of said file.

The resource manager also manages the reception settings, including connection settings for clients in multicast mode that allow them to receive packets. According to one characteristic, the method further comprises a step of transmitting in unicast mode a notification informing of a current reception of said file.

This technique is called "keep alive" in Anglo-Saxon terminology. Thus, the recipient informs that he is receiving the transmitted file in multicast mode.

In addition, the method comprises a step of transmitting a notification of the end of reception of said file.

This step is used to manage the number of clients currently receiving the broadcast file.

Another object of the present invention is to provide a method for transmitting data packets relating to a file, the file being composed of a plurality of packets, said packets having previously been cyclically transmitted in multicast mode to at least one recipient, characterized in that the method comprises the following steps:

receiving at least one request sent in unicast mode in order to obtain packets already transmitted to said at least one recipient and not correctly received by the latter; and

- Unicast transmission of the required packets. The method of transmitting data packets relating to a file according to the invention makes it possible, on the one hand, to transmit these packets in multicast mode and cyclically, and on the other hand, to transmit, in unicast mode. , packets not correctly received by a recipient during the multicast broadcast.

Furthermore, the sending of erroneous packets via a connection in unicast mode makes it possible to reduce the amount of information transmitted on the network and the time required to obtain all the packets forming the file for the network. the customer. According to one characteristic, the packets comprise information identifying their relative position in the file. According to one characteristic, the packets furthermore comprise at least one data integrity verification information, said at least one data integrity verification information being able to, for example, comprise a cyclic redundancy check code. According to this feature, the integrity of the received data can be verified by the packet receiving client. This check allows the detection of received but erroneous packets, also called packets not correctly received.

According to a particular characteristic, the method comprises a preliminary step of receiving a request to obtain the file in multicast mode.

This request makes it possible to start the transmission of the requested file and to control the number of clients wishing to obtain the file.

According to one characteristic, the method comprises a step of incrementing the number of recipients of the file, following the receipt of a request to obtain the file.

In this way, we manage the number of connected clients who are in the process of receiving the transmitted file.

According to another characteristic, the method comprises the following steps:

determining the number of recipients currently receiving said file;

- if the number of recipients is equal to zero, stop sending the file. According to this characteristic, periodically, the number of clients being received of the transmitted file is determined.

Thus, if no client is being received, the broadcast of the file is stopped, thereby reducing the network load.

According to a particular embodiment, the method further comprises a step of adapting the rate of transmission of the packets as a function of the charges borne by recipients. According to one characteristic, the step of receiving at least one request in unicast mode in order to obtain already transmitted packets to at least one recipient and not correctly received by the latter and the unicast mode transmission step of Required packages are made by a download server. The download server is, for example, a device for broadcasting packets in multicast mode.

According to another characteristic, at least one of the following steps:

receiving a request to obtain the file in multicast mode,

incrementing the number of recipients of the file,

- Determining the number of recipients currently receiving said file, is performed by a resource manager. Correlatively, the invention also provides a device for receiving data packets relating to a file, the file being composed of a plurality of packets, the device comprising means for receiving cyclically transmitted packets transmitted in a multicast mode, characterized in that what the device comprises: means for detecting packets not correctly received from the packets of the file that have been sent;

means for transmitting at least one request in unicast mode to obtain said packets; and

means for receiving said packets. This device has the same advantages as the reception method briefly described above.

Another object of the present invention is to provide a system for sending data packets relating to a file, the file being composed of a plurality of packets, said packets having previously been cyclically transmitted in multicast mode to at least one packet. recipient, characterized in that the system comprises: means for receiving at least one request sent in unicast mode in order to obtain packets already transmitted to said at least one recipient and not correctly received by the latter; and

means for unicast transmission of the required packets. This system has the same advantages as the transmission method briefly described above.

According to another aspect, the invention relates to a computer program stored on an information medium, said program containing instructions for implementing the method of receiving data packets relating to a file according to the invention, when this program is loaded and executed by a computer system.

According to another aspect, the invention also relates to a computer program stored on an information medium, said program containing instructions for implementing the method of transmitting data packets relating to a file according to the invention, when this program is loaded and executed by a computer system.

According to yet another aspect, the invention is directed to a programmable component adapted to execute the instructions of a computer program according to the invention. Other aspects and advantages of the present invention will appear more clearly on reading the description of the embodiments which will follow, this description being given solely by way of nonlimiting example and with reference to the appended drawings, in which: Figure 1 shows, schematically, a general view of the system for broadcasting and receiving data carrier information according to the invention; Figure 2 shows, schematically, the contents of a packet transmitted by a broadcast server according to the invention; Figure 3 shows, schematically, the storage of packets received at the client; Figure 4 schematically shows a general view of the support data broadcast and reception system. information when connecting a second client according to the invention; Figure 5 shows, schematically, the storage of packets received by the second client; - Figure 6 shows, schematically, a general view of the broadcast system when disconnecting customers according to the invention; Figure 7 illustrates an algorithm for recovering packets not correctly received according to the invention; - Figure 8 shows, schematically, the hardware and / or software architecture of a client according to the invention; and Figure 9 shows, schematically, the hardware and / or software architecture of a transmission system according to the invention.

A detailed description of the methods for receiving and transmitting data packets relating to a file in accordance with the subject of the invention is provided hereinafter with reference to Figure 1.

The cyclic transmission of data packets in multicast mode in accordance with the invention is based on an architecture composed in particular of at least one multicast server SERV. This includes, in memory, a set of files that it can issue if a client machine, also called "client", makes the request.

Multicast broadcast mode works on UDP protocol

(< ^• < ^• User Datagram Protocol in English terminology) and any client can access it, provided that it is authorized by an ISP

Internet.

UDP is a simple, unreliable, unassigned packet delivery protocol belonging to layer 4 of the OSI model, ie the "transport layer". This layer is in charge of the transport of data, their division into packets and the management of possible transmission errors, the latter feature being however not available in UDP mode. The above protocol is detailed in RFC 768. It is particularly suitable for transmitting data very quickly and when the loss of some of this data does not affect, or for transmitting small amounts of data, there where the "3-WAY" TCP connection proves to be very cumbersome to manage ("3 WAY" TCP is a connection establishment mechanism based on the sending of a connection request packet, the sending of a connection request packet an acknowledgment packet accompanied by a request for synchronization in the opposite direction and the sending by the issuer of a final acknowledgment). Like TCP, UDP uses a system of ports on which clients must connect.

The broadcast server according to the invention is capable of transmitting, cyclically, data carrier data. This cyclical broadcast is also known as "carousel broadcast". The architecture according to the invention also comprises a resource manager GR. It has a database of all files that the broadcast server or broadcast servers associated with it are able to broadcast. In addition, it manages the list of all customers connected to the download service. Customers therefore receive data carrier data during multicast broadcast.

However, in an implementation variant, the resource manager and the broadcast server can be one and the same server.

Another embodiment variant includes a configuration in which each of the clients is also a multicast server and all clients are managed by a single resource manager. In this way, the resource manager centralizes the availability information of the various files proposed by the customers.

Such a configuration allows, first of all, the operator offering this service to expand its offer of available files. Then, it should be noted that the possible use of multiple servers of reduced capacity is more economical, with equal amount of information, than a large capacity server. This configuration also has the advantage that the resource manager is controlled by the service provider. The latter can therefore check the list of files proposed by customers and prevent his service from being used for the dissemination of illegal files. It can thus, in particular, delete these files from the list managed by the resource manager, without having to intervene on the clients' computers.

In the example illustrated in FIG. 1, the system comprises a resource manager GR and an associated SERV broadcast server. An example of hardware and / or software architecture of such a system is shown in Figure 9 and will be described later.

In the initial state of the system, no file copy is being broadcast.

The transmission and reception methods according to the invention and illustrated in FIG. 1 start with the connection of a client A to the resource manager GR in unicast mode (step 1).

An example of hardware and / or software architecture of a client is shown in Figure 8 and will be described later.

Next, the client issues a request (step 2) in order to obtain the list of the files managed and accessible by the broadcast server SERV associated with this resource manager GR. The latter returns in response (step 3) the list of available files and the client selects the desired file. In this example, this is the file "update_login".

The next step (step 4) consists in the client issuing a request to the resource manager GR in order to obtain the "update_login" file.

The resource manager determines whether this file is already being broadcast by the broadcast server SERV or not.

If not, the resource manager GR issues a request to the broadcast server SERV (step 5) so that the latter begins the cyclical transmission of the file requested by the client A (recipient of the file). This request includes, in addition, the connection parameters necessary to manage the broadcast in multicast mode, namely, the multicast address and port as well as the broadcast rate. The server, by means of these parameters, is able to start sending the content of the file in multicast mode cyclically to the client or clients who have requested it beforehand.

The broadcast server transmits to the resource manager GR an acknowledgment (step 6) indicating by the same that it will begin broadcasting, in multicast mode, the requested file. The use of the multicast transmission mode has the following advantages.

First, broadcast group members are dynamic, allowing hosts to join and leave the group at any time.

Then, the ability of hosts to join the multi-recipient groups is exploited, including via sending IGMP ("Internet Group Management Protocol") messages (English terminology).

In addition, groups are not limited in size and members can be spread across multiple IP networks.

On receipt of the acknowledgment of the broadcast server, the resource manager GR sends the client A the following information (step 7).

First, it sends the various parameters necessary for a multicast subscription, in order to receive the data relating to the required file. Then he can inform the client of the size and name of the file being issued.

The subscription is made in particular according to the IGMP procedure. This is a protocol used to access or leave an IP multicast group. All IP hosts that support multicast mode must support IGMP, of which there are several versions. They are all subject to numerous RFCs with the W3C standardization body. The client, upon receipt of the parameters of the resource manager GR creates an empty file, including the same name as that indicated in the parameters provided by said manager and the size also indicated by it. In parallel with this step, the broadcast server SERV starts multicasting the file (step 8).

To do this, the contents of the file are developed in the form of packets and each packet is then sent over the network.

Then, the client makes an IGMP connection request (step 9) using the connection parameters transmitted by the GR resource manager.

The client thus connects in multicast UDP mode in order to receive the packets of the file in question, namely the "update-software" file (step 10). The IGMP subscription is only acknowledged by the client broadcast server after the request to open a UDP connection point (or "socket") with parameters for an IP address in the range of multicast addresses and an IP address. port (This mechanism is intrinsic to TCP).

The adhesion mechanism is managed by the lower layers of the ISO layers. From the developer's point of view, it's only about opening a socket with the multicast parameters defined by normalization.

Since the UDP protocol does not manage the scheduling of transmitted and received data packets, the packets broadcast by the broadcast server SERV must contain information determining the relative place of each packet in the file under consideration.

In addition, the UDP protocol does not manage the integrity of the data transmitted, the packets contain information integrity verification received data, allowing the detection of packets not correctly received. For all these reasons, the broadcast server transmits packets, including packets of a constant size, comprising a header (21) indicating the position of the packet to be inserted in the file at the reception at the client, the data carrier data (22) and information (23), such as a CRC code ("Cyclic Redundancy Check" in English terminology) for verifying the integrity of the data received, as shown in Figure 2. The CRC code, also called "cyclic redundancy check" is a type of hash redundancy used to produce a checksum (called "checksum" in English terminology) which is an integer calculated from a block of data for the purpose of detecting transmission or copy errors. It can also allow the repair of these errors.

When the client receives the packets (step 10 of Figure 1), the latter are stored at their relative position in the file after checking the integrity of the contents of each packet received, including the CRC code contained in the packet. In case of failure during the integrity check, the position of the package in the file is stored in an error file, also called "error logs".

The aforementioned file contains, in particular, the identifier of lost packets or received but erroneous packets. These packets are called "incorrectly received" packets. The error file is used later to retrieve the packets thus detected and identified as not correctly received.

As and when, the client stores the packets relating to the requested file in the initially empty file and is created as shown in Figure 3.

According to one embodiment, during the transfer of the packets from the required file, the client remains permanently connected to the resource manager GR. The latter performs a periodic test on the client to verify that it is still connected and is in the process of receiving broadcast packets. According to an alternative embodiment, the client sends, regularly or not, an information frame (notification) to the resource manager GR to indicate that it is still receiving a file.

It should be noted that these alternatives are not mutually exclusive.

This mechanism for verifying that the client is still in process when receiving the file sent in multicast mode is also called "keep alive".

This connection is carried out in particular according to the TCP protocol, which makes it possible to avoid accidental disconnections and the loss of packets. Indeed, the TCP protocol defines a set of rules that allow the good communication between two computers through one or more interconnected networks. TCP acts in connected mode and provides simultaneous two-way communication. In addition, it is a reliable transport service. For this purpose, it defines the structure of the data and the acknowledgments exchanged and specifies how to detect and correct a packet loss or duplication.

In case of voluntary or accidental disconnection of a client, the resource manager GR updates the number of clients of the file being broadcast. In addition, the resource manager GR controls, upon disconnection, the deletion of the multicast connection of the corresponding client. This disconnection can mean, for example, that the client is disconnected and therefore can not receive anything.

The management of the "keep alive" concerns the interrogation of the client by the resource manager or by the client sending frames of information to the resource manager. This management is performed using the connection initially created when connecting the client to the resource manager to obtain a file, that is to say using the same connection port (or socket). Figure 4 illustrates the connection of a second client to the broadcast system, the broadcast server being issuing the file required by a first client and the latter being still receiving said file. As illustrated in FIG. 2, the second client (client B) sends a first request (step 41) in order to consult the list of files available on the resource manager GR. The latter, in response, sends him the list of available files (step 42). Then, client B issues a request to the resource manager GR containing the identifier of the file that it wishes to load (step 43). In this example, this is the file "update_login".

Upon receipt of this request, the GR resource manager notes that this file is already being broadcast by SERV broadcast servers.

Without dialogue with the broadcast server, the resource manager GR responds to the client B by transmitting the same connection parameters as for the client A (step 44), provided, however, that the client B can support the reception of the file at flow in progress. Upon receipt of these parameters, the client B, like the client A, creates an empty file, for example of the same name as the name of the transmitted file and the size indicated in the parameters.

Next, client B makes a connection request in UDP multicast mode to receive packets of the requested file (step 45).

Since the file is not necessarily at the beginning of broadcast by the broadcast server at the beginning of the reception by the client B, the first packet received by the client B (step 46) is inserted in the file in the place indicated by the packet header information, as shown in Figure 5. The missing part, ie the beginning of the file, will only be received at the next cycle of file transmission.

The various steps illustrated in FIG. 4, and described above, are applicable to any client wishing to download a file being broadcast by the broadcast server SERV. Figure 6 illustrates the management of client disconnections from the GR resource manager, and incidentally from the SERV broadcast server. The management of the connections and disconnections of the customers makes it possible to ask the server of diffusion the beginning and the stop of the diffusion of the file to diffuse. This connection management has the advantage of circulating data over the network only when the file is required, which limits the congestion of the network.

To do this, when a client has finished receiving the file, it notifies the resource manager GR by issuing a message (step 61).

On receipt of such a message, the resource manager GR then decrements the number of subscribers according to the IGMP protocol on the file being broadcast.

When the resource manager GR detects that there are no more clients that are loading the transmitted file, it sends a notification to the broadcast server SERV so that the latter stops the cyclic transmission of the file (step 62). ). The broadcast server SERV therefore stops the transmission of the file

(step 63), without waiting for the end of the broadcast cycle. This file is no longer distributed in carousel.

As previously described, all clients are connected in unicast mode with the GR resource manager. This connection mode allows the GR resource manager to determine if the clients are still connected and receive the file being broadcast.

If the connection is interrupted, the resource manager GR considers that the client has abandoned the reception of the file (step 64).

According to a particular embodiment, the resource manager issues a request to the clients that are connected to it in unicast mode.

Alternatively, clients send information frames to the resource manager (step 65).

This determines whether the connection is still in progress and, therefore, whether the client is still receiving the transmitted file in multicast mode cyclically. It should be noted that a resource manager GR can manage a plurality of broadcast servers, these servers can be distributed in different locations on the network.

In support of Figure 1, it has been described that the client detects packets not correctly received, and that the identifier of these packets is stored in an error file.

In most cases, the client can not disregard packets that are not correctly received, since a file containing software is not executable if parts are wrong or missing. The client must therefore handle the packets not correctly received for later retrieval.

One embodiment of such a method for managing packets not correctly received is now described in support of FIG. 7.

The algorithm starts in step 71 by handling packets not correctly received.

This step is followed by step 72 which constitutes a decision step as to the mode of recovery of packets identified as not correctly received.

The decision step depends on a criterion, the latter being in particular a function of the number of packets identified as not correctly received and the transmission cycle period of the packets of the file.

If the incorrectly received packets are contiguous and the file broadcast cycle period is not excessively long, then the algorithm continues with a step 73. During this step, the recovery of packets identified as not correctly received during the next file broadcast cycle.

The algorithm ends with step 74, during which the client disconnects from the broadcast server and notifies the resource manager GR that the reception has ended.

If the number of packets not correctly received is low, if the packets are not contiguous and if the broadcast cycle period of the file is high, then the recovery of the packets can be carried out as indicated in the following steps 75 to 79.

First, the client disconnects from the broadcast server and notifies it to the resource manager GR (step 75). Next, the client establishes a unicast connection with a server to retrieve packets identified as not correctly received (step 76).

Note that the connection in unicast mode can be performed on the broadcast server or on another server, including a mirror server of the broadcast server.

This connection is performed in particular in TCP mode to ensure the integrity of the data.

In the next step 77, the client sends at least one request containing the identifier of at least one packet to retrieve. The server, upon receipt of the request or requests, responds by sending the client packets that have already been issued in multicast mode, but this time, the packets are sent in unicast mode.

Step 78 corresponds to the reception of the packets at the client and the storage, in the file, of the information carrier data contained in the packet, in particular after verifying the integrity of the data.

The algorithm ends in step 79 by disconnecting the server.

In an alternative embodiment not shown, the connection of the client to the broadcast server or to another server for the purpose of recovering packets not correctly received can be performed according to the UDP protocol. In this case, at the end of step 78, the client must check the integrity of the data, and if the latter detects problems, he must reissue a request. In this case, the algorithm loops in step 77 until all the packets not correctly received are obtained.

According to another embodiment not shown, the connection of the client to a broadcast server or to another server for the purpose of recovering packets not correctly received is performed simultaneously with the multicast connection to the broadcast server. This variant has the advantage of obtaining the incorrectly received packets identified at the beginning of the reception of a file before the end of a multicast transmission cycle of the file. This variant is particularly interesting when receiving large files. This variant embodiment may require the implementation of a particular management for counting lost packets, in particular a statistical management of the number of packets lost. This management must make it possible, in particular, to determine whether the unicast connection is maintained during the entire reception of the file in multicast mode, or if the unicast connection is established several times during narrower periods.

According to an alternative embodiment, the broadcast server can transmit the file at a rate that can be adapted, in particular according to the maximum loads supported by each of the clients.

Different adaptations can be made. A first method is to readjust the delivery rate by taking into account the lower capacity in terms of resources among the customers, provided, however, that the gap with the capacities of the other customers is not too constraining for the latter.

A second method is to create a new multicast streaming channel with a different throughput. When a new client connects, they are assigned the most appropriate broadcast channel for their throughput capabilities.

If a client is not able to receive the packets transmitted at a given bit rate, then the resource manager GR can create a new multicast broadcast channel with a lower bit rate.

The GR resource manager can also manage multiple rate ranges on which it assigns different clients, for example, 4Mb / s, 2Mb / s, 512kb / s, 128kb / s. The different ranges can be set by the GR resource manager. According to yet another embodiment not shown, there are at least two multicast broadcast servers, each being able to transmit the same stream of data at different rates. This allows meet technical constraints related to the reception capabilities of different customers.

According to this configuration, the information transmitted by the broadband broadcast server is transmitted by a lower rate broadcast server with a certain time lag.

Thus, according to this configuration, a client receiving a stream sent by the broadband broadcast server may also use the lower rate broadcast server and connect to it, in order to recover all or part of the packets identified as not correctly received. FIG. 8 represents an example of a hardware and / or software architecture of a client according to the invention and which is implemented in the manner described with reference to FIGS. 1, 4, 6 and 7.

A client 81, in particular Client A, comprises, on the one hand, means for managing a communication 82 for receiving a file in multicast mode, and, on the other hand, means for managing a communication in communication. unicast mode 83 to receive packets not correctly received.

More particularly, the management means 82 comprise means for establishing a connection in unicast mode with the resource manager 84 and means for transmitting a request 85 to request obtaining a given file. .

The management means 82 also comprise means for receiving the reception parameters of the file enabling the connection to the broadcast server, and means for establishing the connection in multicast mode using the reception parameters received. The management means 82 furthermore comprise means for receiving and memorizing the file broadcast in multicast mode by a broadcast server and means for detecting the packets not correctly received from the packets of the file that have been sent.

In addition, the management means 82 comprise transmission means 90 of a notification of the end of receipt of the file. Finally, the management means 82 include transmission means 91 of information frames to indicate that the client is in the process of receiving a file transmitted in multicast mode.

The management means of the unicast communication 83 comprise, for their part, decision means 92 for sending at least one request in unicast mode to a download server.

In addition, the management means 83 comprise means for establishing a unicast connection 93 with a loading server in order to obtain the packets not correctly received, means 94 for transmitting at least one unicast request to this loading server, as well as means for receiving and storing 95 required packets.

FIG. 9 represents an example of a hardware and / or software architecture of a data packet transmission system according to the invention and which is implemented in the manner described with reference to FIGS. 1, 4 and 6.

The data packet sending system 100 comprises at least one broadcast server 101, at least one resource manager 102 and at least one download server 103. It will be noted that said at least one broadcast server 101, said at least one a resource manager 102 and said at least one download server 103 may be made according to a single hardware and / or software component.

The broadcast server 101 is able to broadcast cyclically in multicast mode packets forming a file to at least one recipient. It includes, in particular, packet sending means 104, start means 105 for sending packets of a given file and stop means 106 for sending the file.

In addition, the broadcast server 101 includes means 107 for matching the packet transmission rate as a function of the charges borne by the recipients of the packets. The resource manager 102 includes means 108 for receiving a request to obtain a file in multicast mode. In addition, the resource manager 102 includes means 109 for incrementing the number of recipients of the file being transmitted by a broadcast server associated with the resource manager.

The manager 102 also comprises, means for determining the number of recipients 115 receiving the transmitted file, these determination means being able to decrement the number of recipients of the file on receipt of a notification of the end of receipt of the file. In addition, it includes means 111 for informing the broadcast server that it must stop the transmission of a file. The download server 103 comprises means 112 for receiving at least one request sent in unicast mode in order to obtain already transmitted packets to the addressee sending the request and means 113 for sending in unicast mode of the requested packets. .

According to an exemplary embodiment, the download server 103 may also be a broadcast server 102.

Claims

A method of receiving data packets relating to a file, the file being composed of a plurality of packets, the method comprising a step of receiving (10, 46) cyclically transmitted packets in multicast mode, characterized in that the process comprises the following steps:

detection of packets not correctly received among the packets of the file that have been sent;

for at least part of the packets identified as not correctly received: sending at least one request (77) in unicast mode to obtain said packets; and o receiving said packets (78).

2. Reception method according to claim 1, characterized in that the packets being identified by their relative position in the file, the method further comprises a step of storing the received packets at their relative position in the file.

3. Reception method according to claim 1 or claim 2, characterized in that the packets comprise at least one data integrity verification information.

4. Reception method according to any one of the preceding claims, characterized in that the step of transmitting said at least one request in unicast mode is subject to a prior decision step (72) whose realization depends on a predetermined criterion.

5. receiving method according to any one of the preceding claims, characterized in that it comprises, prior to the step of receiving packets, a transmission step (4, 43), to a manager of resources, a request to obtain said file.

6. Reception method according to claim 5, characterized in that it comprises, prior to the step of issuing a request to obtain said file, a step of establishing a connection in unicast mode (1). with the resource manager.

7. Reception method according to claim 5 or 6, characterized in that it comprises a reception step (7, 44), from the resource manager, receiving parameters of said file.

8. Method according to any one of the preceding claims, characterized in that it further comprises a step of transmitting (65) in unicast mode of a notification informing of a current reception of said file.

9. Reception method according to any one of the preceding claims, characterized in that it further comprises a step of transmitting an end of receipt notification (61) of said file.

A method of transmitting data packets relating to a file, the file being composed of a plurality of packets, said packets having previously been cyclically transmitted in multicast mode to at least one recipient (8), characterized in that the process comprises the following steps:

- Unicast transmission of the required packets.

11. Transmission method according to claim 10, characterized in that the packets comprise information identifying their relative position in the file.

12. Transmission method according to claim 10 or claim 11, characterized in that the packets further comprise at least one information integrity verification data.

13. Transmission process according to any one of the claims

10 to 12, characterized in that it comprises a preliminary step of receiving a request (4, 43) to obtain the file in multicast mode.

14. Transmission method according to claim 13, characterized in that it comprises a step of incrementation of the number of recipients of the file, following the receipt of a request to obtain the file.

15. Transmitting method according to any one of claims 10 to 14, characterized in that it comprises the following steps: - determining the number of recipients currently receiving said file; and

if the number of recipients is equal to zero, stopping the transmission of the file (62).

16. Transmission process according to any one of the claims

10 to 15, characterized in that it further comprises a step of adapting the rate of transmission of the packets as a function of the charges borne by recipients.

17. Transmission process according to any one of the claims

10 to 16, characterized in that the step of receiving at least one request in unicast mode in order to obtain already transmitted packets to at least one recipient and not correctly received by the latter and the transmission step in unicast mode, the required packets are made by a download server.

18. Transmission method according to any one of claims 13 to 15, characterized in that, at least one of the following steps:

receiving a request to obtain the file in multicast mode; incrementing the number of recipients of the file;

- Determining the number of recipients currently receiving said file, is performed by a resource manager.

19. Device for receiving data packets relating to a file, the file being composed of a plurality of packets, the device comprising means for receiving (86) cyclically transmitted packets in a multicast mode, characterized in that the device comprises:

means for detecting (89) packets not correctly received among the packets of the file that have been sent;

means for sending (94) at least one request in unicast mode to obtain said packets; and

means for receiving (95) said packets.

20. Receiving device according to claim 19, characterized in that the device comprises means (93) for establishing a connection in unicast mode with a download server in order to obtain the packets not correctly received.

21. Receiving device according to claim 20, characterized in that the download server is a packet broadcasting device in multicast mode.

22. System for sending data packets relating to a file, the file being composed of a plurality of packets, said packets having previously been cyclically transmitted in multicast mode to at least one recipient, characterized in that the system includes: means for receiving (112) at least one request sent in unicast mode in order to obtain packets already transmitted to said at least one recipient and not correctly received by the latter; and

transmitting means (113) in unicast mode of the required packets.

23. Transmitting system according to claim 22, characterized in that the download server is a packet broadcasting device in multicast mode.

A computer program stored on an information carrier, said program containing instructions for implementing the method of receiving data packets relating to a file according to any one of claims 1 to 9, when the program is loaded and executed by a computer system.

25. A computer program stored on an information carrier, said program containing instructions for implementing the method of transmitting data packets relating to a file according to any one of claims 10 to 18, when the program is loaded and executed by a computer system.

26. Programmable component adapted to execute the instructions of a computer program according to claim 24.