EP2005647A1 - Procede et dispositif d'emission et de reception de paquets de donnees relatifs a un fichier emis de maniere cyclique en mode multicast - Google Patents

Procede et dispositif d'emission et de reception de paquets de donnees relatifs a un fichier emis de maniere cyclique en mode multicast

Info

Publication number
EP2005647A1
EP2005647A1 EP07731853A EP07731853A EP2005647A1 EP 2005647 A1 EP2005647 A1 EP 2005647A1 EP 07731853 A EP07731853 A EP 07731853A EP 07731853 A EP07731853 A EP 07731853A EP 2005647 A1 EP2005647 A1 EP 2005647A1
Authority
EP
European Patent Office
Prior art keywords
packets
file
receiving
request
mode
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Withdrawn
Application number
EP07731853A
Other languages
German (de)
English (en)
Inventor
Lise George
Halim Bendiabdallah
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Orange SA
Original Assignee
France Telecom SA
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by France Telecom SA filed Critical France Telecom SA
Publication of EP2005647A1 publication Critical patent/EP2005647A1/fr
Withdrawn legal-status Critical Current

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/02—Details
    • H04L12/16—Arrangements for providing special services to substations
    • H04L12/18—Arrangements for providing special services to substations for broadcast or conference, e.g. multicast
    • H04L12/1863—Arrangements for providing special services to substations for broadcast or conference, e.g. multicast comprising mechanisms for improved reliability, e.g. status reports
    • H04L12/1868—Measures taken after transmission, e.g. acknowledgments
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L1/00—Arrangements for detecting or preventing errors in the information received
    • H04L1/12—Arrangements for detecting or preventing errors in the information received by using return channel
    • H04L1/16—Arrangements for detecting or preventing errors in the information received by using return channel in which the return channel carries supervisory signals, e.g. repetition request signals
    • H04L1/18—Automatic repetition systems, e.g. Van Duuren systems
    • H04L1/1867—Arrangements specially adapted for the transmitter end
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L1/00—Arrangements for detecting or preventing errors in the information received
    • H04L2001/0092—Error control systems characterised by the topology of the transmission link
    • H04L2001/0093—Point-to-multipoint

Definitions

  • 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.
  • IP network Internet Protocol
  • 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.
  • unicast defines a point-to-point network connection.
  • 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.
  • 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.
  • connection in unicast mode implies a strong redundancy of the transferred data.
  • 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.
  • 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.
  • the multicast broadcasting mode uses a specific technique of multicast addressing.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • the download must be made in its entirety over at most two broadcast cycles.
  • 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.
  • the use of multicast mode optimizes the network load since the same content is sent to a plurality of clients.
  • 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.
  • 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.
  • 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.
  • 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.
  • the packets include information identifying the relative position in the file of the data transported by these packets.
  • 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.
  • the integrity of the data received can be verified. This check allows the detection of erroneously received packets, also known as incorrectly received packets.
  • 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.
  • the mode of reception of the packets identified as not correctly received is determined.
  • the method comprises, prior to the step of receiving packets, a step of sending, to a resource manager, a request to obtain said file.
  • 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.
  • 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.
  • 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.
  • the method further comprises a step of transmitting in unicast mode a notification informing of a current reception of said file.
  • 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:
  • 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.
  • the use of multicast mode optimizes the network load since the same content is sent to a plurality of clients.
  • 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.
  • the packets comprise information identifying their relative position in the file.
  • 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.
  • 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.
  • the method comprises a step of incrementing the number of recipients of the file, following the receipt of a request to obtain the file.
  • the method comprises the following steps:
  • the method further comprises a step of adapting the rate of transmission of the packets as a function of the charges borne by recipients.
  • 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.
  • 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;
  • 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
  • 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.
  • 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.
  • 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.
  • 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
  • Figure 9 shows, schematically, the hardware and / or software architecture of a transmission system according to the invention.
  • 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
  • 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.
  • 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).
  • 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.
  • 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.
  • 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.
  • 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).
  • 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.
  • this is the file "update_login”.
  • 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.
  • 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.
  • broadcast group members are dynamic, allowing hosts to join and leave the group at any time.
  • groups are not limited in size and members can be spread across multiple IP networks.
  • the resource manager GR On receipt of the acknowledgment of the broadcast server, the resource manager GR sends the client A the following information (step 7).
  • 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.
  • the broadcast server SERV starts multicasting the file (step 8).
  • the contents of the file are developed in the form of packets and each packet is then sent over the network.
  • 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.
  • the packets broadcast by the broadcast server SERV must contain information determining the relative place of each packet in the file under consideration.
  • 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.
  • 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.
  • the client 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.
  • the client stores the packets relating to the requested file in the initially empty file and is created as shown in Figure 3.
  • the client 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.
  • the client sends, regularly or not, an information frame (notification) to the resource manager GR to indicate that it is still receiving a file.
  • This mechanism for verifying that the client is still in process when receiving the file sent in multicast mode is also called “keep alive”.
  • 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.
  • it is a reliable transport service.
  • it defines the structure of the data and the acknowledgments exchanged and specifies how to detect and correct a packet loss or duplication.
  • the resource manager GR updates the number of clients of the file being broadcast.
  • 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.
  • FIG. 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.
  • the second client client B
  • sends a first request step 41
  • the resource manager GR containing the identifier of the file that it wishes to load
  • this is the file "update_login”.
  • the GR resource manager Upon receipt of this request, the GR resource manager notes that this file is already being broadcast by SERV broadcast servers.
  • 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.
  • the client B 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.
  • client B makes a connection request in UDP multicast mode to receive packets of the requested file (step 45).
  • 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.
  • FIG. 4 illustrates 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.
  • a client when a client has finished receiving the file, it notifies the resource manager GR by issuing a message (step 61).
  • the resource manager GR 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.
  • the resource manager GR 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.
  • the resource manager GR considers that the client has abandoned the reception of the file (step 64).
  • the resource manager issues a request to the clients that are connected to it in unicast mode.
  • clients send information frames to the resource manager (step 65).
  • a resource manager GR can manage a plurality of broadcast servers, these servers can be distributed in different locations on the network.
  • 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.
  • the algorithm starts in step 71 by handling packets not correctly received.
  • 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.
  • step 73 the recovery of packets identified as not correctly received during the next file broadcast cycle.
  • step 74 the client disconnects from the broadcast server and notifies the resource manager GR that the reception has ended.
  • the recovery of the packets can be carried out as indicated in the following steps 75 to 79.
  • the client disconnects from the broadcast server and notifies it to the resource manager GR (step 75).
  • the client establishes a unicast connection with a server to retrieve packets identified as not correctly received (step 76).
  • 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.
  • 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.
  • step 79 The algorithm ends in step 79 by disconnecting the server.
  • 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.
  • the client 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.
  • the algorithm loops in step 77 until all the packets not correctly received are obtained.
  • 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.
  • 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.
  • 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.
  • 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.
  • the information transmitted by the broadband broadcast server is transmitted by a lower rate broadcast server with a certain time lag.
  • 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.
  • 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.
  • management means 82 comprise transmission means 90 of a notification of the end of receipt of the file.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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. .
  • the download server 103 may also be a broadcast server 102.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

L'invention concerne un procede de reception de paquets de donnees relatifs a un fichier, Ie fichier etant compose d'une pluralite de paquets, Ie procede comprenant une etape de reception (10, 46) de paquets emis de maniere cyclique en mode multicast, caracterise en ce que Ie procede comprend les etapes suivantes : detection des paquets non correctement recus parmi les paquets du fichier qui ont ete emis; pour au moins une partie des paquets identifies comme non correctement regus : emission (77) d'au moins une requete en mode unicast pour obtenir lesdits paquets; et reception desdits paquets (78).

Description

Procédé et dispositif d'émission et de réception de paquets de données relatifs à un fichier émis de manière cyclique en mode multicast
L'invention concerne un procédé et un système d'émission de paquets de données relatifs à un fichier, lesdits paquets étant émis de manière cyclique en mode multicast, ainsi qu'un procédé et un dispositif de réception de tels paquets.
A l'heure actuelle, les entreprises et les fournisseurs de contenus, de données, de programmes, notamment de mises à jour ou de nouvelles versions de logiciels, de jeux vidéo, de vidéo à la demande en temps différé, font appel, de manière quasi nécessaire, à l'échange de données et à la transmission de données par l'intermédiaire du réseau IP (« Internet Protocol » en terminologie anglo-saxonne). La transmission et le téléchargement de ces données sont effectués, aujourd'hui, aussi bien sur les réseaux fixes que sur les réseaux mobiles. Parmi les réseaux fixes, on trouve le réseau IP qui comprend le réseau Internet.
Un exemple, non limitatif, de système de distribution de données est le « peer-to-peer », aussi appelé « d'égal à égal », ou « pair à pair » qui consiste à permettre le partage de données entre les ordinateurs d'un réseau.
Actuellement, les téléchargements de données, c'est-à-dire l'émission et la réception de données se font essentiellement en mode unicast. Le terme « unicast » définit une connexion réseau point à point. Ainsi, on entend par « unicast » le fait de faire communiquer entre eux deux ordinateurs identifiés chacun par une adresse réseau unique. Pour ce faire, les paquets de données sont routés sur le réseau suivant l'adresse du destinataire encapsulée dans la trame transmise. Normalement, seul le destinataire intercepte et décode le paquet qui lui est adressé.
Ces téléchargements sont normalisés et sont réalisés, par exemple, soit par le protocole FTP (« File Transfert Protocol » en terminologie anglo- saxonne), soit par le protocole HTTP (« HyperText Transfert Protocol » en terminologie anglo-saxonne). Ce sont des protocoles permettant le transfert de données sur un réseau TCP / IP («Transmission Control Protocol/Internet Protocol» en terminologie anglo-saxonne).
Ces protocoles assurent, en général, l'intégrité des données réceptionnées, notamment par un contrôle des erreurs de transmission de données.
Toutefois, un premier inconvénient de ces mécanismes de téléchargement réside dans le fait que, lors d'émissions massives, le serveur de diffusion de contenus peut être saturé en raison du grand nombre de connexions simultanées établies avec des utilisateurs.
En outre, ces mécanismes de téléchargement présentent l'inconvénient supplémentaire de charger le réseau, voire de le saturer, en faisant circuler de manière non optimisée de grandes quantités d'informations.
En effet, l'utilisation d'une connexion en mode unicast implique une forte redondance des données transférées.
Ces problèmes se rencontrent notamment lors de la mise à la disposition de données attendues par une grande multiplicité d'utilisateurs, tel qu'un jeu vidéo, une mise à jour d'un système d'exploitation, une musique ou tout autre contenu médiatisé. II est connu du document US 6,256,673 un procédé de diffusion d'un fichier en mode multicast dans lequel le contenu du fichier est émis en continu de manière cyclique.
Le mode « multicast », contrairement au mode « unicast », permet d'adresser simultanément un contenu à une pluralité d'utilisateurs destinataires, au moyen d'un seul envoi.
En effet, grâce à la technique de diffusion multicast, le serveur de diffusion n'envoie qu'une seule fois les données constitutives de la diffusion. Les données susmentionnées sont dupliquées par les routeurs du réseau, de façon dynamique, pour atteindre les utilisateurs habilités qui en ont fait la demande. L'ensemble des chemins ou cheminements suivis par les paquets de données diffusés, du serveur vers les utilisateurs habilités, forme un arbre de diffusion d'information multicast dont la racine est le serveur de diffusion, les divers cheminements constituant les branches et les utilisateurs constituant les feuilles dudit arbre.
A chaque demande d'accès d'un nouvel utilisateur, une nouvelle branche est rajoutée. En ce qui concerne l'adressage multicast, le mode de diffusion multicast fait appel à une technique spécifique d'adressage multicast.
Selon cette technique, un paquet de données faisant partie d'une diffusion multicast possède une adresse IP de destination, dite « adresse multicast ». Tous les paquets de données support d'information appartenant à la même diffusion portent la même adresse multicast de destination.
Alors qu'une adresse IP unicast permet d'identifier une et une seule machine (ou poste de travail d'un utilisateur), une adresse IP multicast sert à identifier un ensemble (ou groupe) de machines, à savoir l'ensemble des machines habilitées à accéder à cette diffusion.
Selon le procédé de diffusion décrit dans US 6,256,673, le contenu du fichier est diffusé de façon cyclique tant qu'un utilisateur n'a pas eu la possibilité de charger l'ensemble des paquets permettant la reconstruction du fichier demandé. Pour ce faire, lorsqu'un utilisateur souhaite le téléchargement d'un fichier, après interrogation du serveur, celui-ci démarre la diffusion du contenu du fichier. Le fichier se décompose, pour son émission, en une multitude de paquets. Ceux-ci sont identifiés par rapport à leur position relative dans le fichier ce qui permet à l'utilisateur de reconstruire le fichier. Lorsqu'un second utilisateur souhaite obtenir le même contenu, il se connecte au même serveur. Le fichier étant en cours de diffusion, le second utilisateur réceptionne des données dès sa connexion au serveur, mais ces données reçues ne sont pas nécessairement en début de fichier.
Aussi, le serveur, lors de la connexion de l'utilisateur, note qu'il doit émettre le contenu du fichier une nouvelle fois afin que le second utilisateur réceptionne l'ensemble des paquets formant le fichier.
L'arrêt de la diffusion intervient lorsque tous les utilisateurs ont eu la possibilité de réceptionner tous les paquets formant le fichier.
L'utilisation du mode multicast et la transmission cyclique permettent d'optimiser la quantité de données circulant sur le réseau et, donc, de réduire la saturation de celui-ci.
Toutefois, ce procédé de diffusion présente les inconvénients suivants.
Tout d'abord, la transmission en mode multicast de données est réalisée sans contrôle d'erreurs. Or, il a été observé que les paquets diffusés en mode multicast sont quelquefois perdus ou erronés et un fichier contenant des données erronées ou absentes est bien souvent non exploitable par l'utilisateur.
Ensuite, la gestion des cycles de diffusion à réaliser est gérée par une note d'information indiquant qu'un cycle supplémentaire doit être effectué lorsqu'un utilisateur se connecte au cours de la diffusion du contenu d'un fichier. Ainsi, le téléchargement doit être effectué dans son intégralité sur au plus deux cycles de diffusion.
La présente invention a pour objet de remédier à au moins un des inconvénients des techniques et processus de l'art antérieur précités. Un objet de la présente invention est en particulier un procédé de réception de paquets de données relatifs à un fichier, le fichier étant composé d'une pluralité de paquets, le procédé comprenant une étape de réception de paquets émis de manière cyclique en mode multicast, caractérisé en ce que le procédé comprend les étapes suivantes : - détection des paquets non correctement reçus parmi les paquets du fichier qui ont été émis ; - pour au moins une partie des paquets identifiés comme non correctement reçus : o émission d'au moins une requête en mode unicast pour obtenir lesdits paquets ; et o réception desdits paquets.
Le procédé de réception de paquets de données relatifs à un fichier selon l'invention permet, d'une part, de recevoir ces paquets en mode multicast, les paquets étant émis en mode multicast et de manière cyclique, et d'autre part, de recevoir les paquets non correctement reçus lors de la réception en multicast au moyen d'une connexion en mode unicast.
De la sorte, l'utilisation du mode multicast permet d'optimiser la charge du réseau puisqu'un même contenu est émis à une pluralité de clients.
Par ailleurs, un contrôle de l'intégrité des données reçues et une détection des paquets non reçus sont réalisés et permettent la détection des paquets non correctement reçus.
Un fichier contenant des données erronées ou des informations absentes est bien souvent inexploitable. Pour résoudre ce problème, l'invention propose de télécharger ces données par une connexion en mode unicast, c'est- à-dire en mode point à point auprès d'un serveur de contenu. Selon l'invention, la gestion de ces paquets non correctement reçus est également réalisée de manière à réduire la quantité d'informations émises sur le réseau et le temps nécessaire à l'obtention de l'ensemble des paquets formant le fichier pour le client.
Selon une caractéristique, les paquets étant identifiés par leur position relative dans le fichier, le procédé comprend en outre une étape de mémorisation des paquets reçus à leur position relative dans le fichier.
La réception des paquets relatifs à un fichier peut débuter alors que l'émission du fichier est déjà en cours. La mémorisation des données contenues dans les paquets doit cependant être effectuée à l'emplacement effectif de ces données lors de la réception. Pour ce faire, les paquets comprennent une information identifiant la position relative dans le fichier des données transportées par ces paquets. Selon une caractéristique, les paquets comprennent au moins une information de vérification de l'intégrité des données, ladite au moins une information de vérification de l'intégrité des données pouvant, par exemple, comprendre un code de contrôle de redondance cyclique. Selon cette caractéristique, l'intégrité des données réceptionnées peut être vérifiée. Cette vérification permet la détection des paquets reçus de façon erronée, aussi appelés paquets non correctement reçus.
Selon une caractéristique, l'étape d'émission de ladite au moins une requête en mode unicast est subordonnée à une étape préalable de décision dont la réalisation dépend d'un critère prédéterminé.
Le critère prédéterminé est, par exemple, fonction du nombre de paquets identifiés comme non correctement reçus et de la période de cycle d'émission du fichier.
Selon cette caractéristique, on détermine le mode de réception des paquets identifiés comme non correctement reçus.
Selon une caractéristique, le procédé comprend, préalablement à l'étape de réception de paquets, une étape d'émission, à destination d'un gestionnaire de ressources, d'une requête pour obtenir ledit fichier.
Selon une autre caractéristique, le procédé comprend, préalablement à l'étape d'émission d'une requête pour obtenir ledit fichier, une étape d'établissement d'une connexion en mode unicast avec le gestionnaire de ressources.
En effet, une liaison établie en mode unicast entre le client et le gestionnaire de ressources permet à ce dernier de contrôler l'ensemble des clients en cours de réception du fichier diffusé.
Selon une autre caractéristique, le procédé comprend une étape de réception, en provenance du gestionnaire de ressources, de paramètres de réception dudit fichier.
Le gestionnaire de ressources gère en outre les paramètres de réception, notamment les paramètres de connexion des clients en mode multicast qui leur permettent de recevoir des paquets. Selon une caractéristique, le procédé comprend en outre une étape d'émission en mode unicast d'une notification informant d'une réception en cours dudit fichier.
Cette technique est appelée « keep alive » en terminologie anglo- saxonne. Ainsi, le destinataire informe qu'il est en cours de réception du fichier émis en mode multicast.
En outre, le procédé comprend une étape d'émission d'une notification de fin de réception dudit fichier.
Cette étape permet la gestion du nombre de clients en cours de réception du fichier diffusé.
La présente invention a également pour but de fournir un procédé d'émission de paquets de données relatifs à un fichier, le fichier étant composé d'une pluralité de paquets, lesdits paquets ayant été préalablement émis de manière cyclique en mode multicast vers au moins un destinataire, caractérisé en ce que le procédé comprend les étapes suivantes :
- réception d'au moins une requête émise en mode unicast en vue d'obtenir des paquets déjà émis vers ledit au moins un destinataire et non correctement reçus par ce dernier ; et
- émission en mode unicast des paquets requis. Le procédé d'émission de paquets de données relatifs à un fichier selon l'invention permet, d'une part, d'émettre ces paquets en mode multicast et de manière cyclique, et d'autre part, d'émettre, en mode unicast, les paquets non correctement reçus par un destinataire lors de l'émission en multicast.
De la sorte, l'utilisation du mode multicast permet d'optimiser la charge du réseau puisqu'un même contenu est émis à une pluralité de clients.
Par ailleurs, l'émission des paquets erronés par l'intermédiaire d'une connexion en mode unicast permet de réduire la quantité d'informations émises sur le réseau et le temps nécessaire à l'obtention de l'ensemble des paquets formant le fichier pour le client. Selon une caractéristique, les paquets comprennent une information identifiant leur position relative dans le fichier. Selon une caractéristique, les paquets comprennent en outre au moins une information de vérification de l'intégrité des données, ladite au moins une information de vérification de l'intégrité des données, pouvant, par exemple, comprendre un code de contrôle de redondance cyclique. Selon cette caractéristique, l'intégrité des données réceptionnées peut être vérifiée par le client récepteur des paquets. Cette vérification permet la détection des paquets reçus mais erronés, aussi appelés paquets non correctement reçus.
Selon une caractéristique particulière, le procédé comprend une étape préalable de réception d'une requête pour obtenir le fichier en mode multicast.
Cette requête permet de débuter l'émission du fichier demandé et de contrôler le nombre de clients désirant obtenir le fichier.
Selon une caractéristique, le procédé comprend une étape d'incrémentation du nombre de destinataires du fichier, consécutivement à la réception d'une requête pour obtenir le fichier.
De la sorte, on gère le nombre de clients connectés et qui sont en cours de réception du fichier émis.
Selon une autre caractéristique, le procédé comprend les étapes suivantes :
- détermination du nombre de destinataires en cours de réception dudit fichier ;
- si le nombre de destinataires est égal à zéro, arrêt de l'émission du fichier. Selon cette caractéristique, périodiquement, on détermine le nombre de clients en cours de réception du fichier émis.
Ainsi, si aucun client n'est en cours de réception, la diffusion du fichier est arrêtée, réduisant de la sorte la charge du réseau.
Selon un mode de réalisation particulier, le procédé comprend, en outre, une étape d'adaptation du débit de l'émission des paquets en fonction des charges supportées par des destinataires. Selon une caractéristique, l'étape de réception d'au moins une requête en mode unicast en vue d'obtenir des paquets déjà émis vers au moins un destinataire et non correctement reçus par ce dernier et l'étape d'émission en mode unicast des paquets requis sont effectuées par un serveur de téléchargement. Le serveur de téléchargement est, par exemple, un dispositif de diffusion des paquets en mode multicast.
Selon une autre caractéristique, au moins l'une des étapes suivantes :
- de réception d'une requête pour obtenir le fichier en mode multicast,
- d'incrémentation du nombre de destinataires du fichier,
- de détermination du nombre de destinataires en cours de réception dudit fichier, est effectuée par un gestionnaire de ressources. Corrélativement, l'invention fournit également un dispositif de réception de paquets de données relatifs à un fichier, le fichier étant composé d'une pluralité de paquets, le dispositif comprenant des moyens de réception de paquets émis de manière cyclique en mode multicast, caractérisé en ce que le dispositif comprend : - des moyens de détection des paquets non correctement reçus parmi les paquets du fichier qui ont été émis ;
- des moyens d'émission d'au moins une requête en mode unicast pour obtenir lesdits paquets ; et
- des moyens de réception desdits paquets. Ce dispositif présente les mêmes avantages que le procédé de réception brièvement décrit ci-dessus.
La présente invention a également pour but de fournir un système d'émission de paquets de données relatifs à un fichier, le fichier étant composé d'une pluralité de paquets, lesdits paquets ayant été préalablement émis de manière cyclique en mode multicast vers au moins un destinataire, caractérisé en ce que le système comprend : - des moyens de réception d'au moins une requête émise en mode unicast en vue d'obtenir des paquets déjà émis vers ledit au moins un destinataire et non correctement reçus par ce dernier ; et
- des moyens d'émission en mode unicast des paquets requis. Ce système présente les mêmes avantages que le procédé d'émission brièvement décrit ci-dessus.
Selon un autre aspect, l'invention vise un programme d'ordinateur stocké sur un support d'informations, ledit programme contenant des instructions permettant la mise en œuvre du procédé de réception de paquets de données relatifs à un fichier conforme à l'invention, lorsque ce programme est chargé et exécuté par un système informatique.
Selon un autre aspect, l'invention vise également un programme d'ordinateur stocké sur un support d'informations, ledit programme contenant des instructions permettant la mise en œuvre du procédé d'émission de paquets de données relatifs à un fichier conforme à l'invention, lorsque ce programme est chargé et exécuté par un système informatique.
Selon encore un autre aspect, l'invention vise un composant programmable adapté à exécuter les instructions d'un programme d'ordinateur conforme à l'invention. D'autres aspects et avantages de la présente invention apparaîtront plus clairement à la lecture de la description des modes de réalisation qui va suivre, cette description étant donnée uniquement à titre d'exemple non limitatif et faite en référence aux dessins annexés, dans lesquels : la Figure 1 représente, de manière schématique, une vue générale du système de diffusion et de réception de données support d'information conforme à l'invention ; la Figure 2 représente, de manière schématique, le contenu d'un paquet émis par un serveur de diffusion selon l'invention ; la Figure 3 représente, de manière schématique, la mémorisation des paquets reçus au niveau du client ; la Figure 4 représente, de manière schématique, une vue générale du système de diffusion et de réception de données support d'information lors de la connexion d'un second client conformément à l'invention ; la Figure 5 représente, de manière schématique, la mémorisation des paquets reçus par le second client ; - la Figure 6 représente, de manière schématique, une vue générale du système de diffusion lors de la déconnexion des clients conformément à l'invention ; la Figure 7 illustre un algorithme de récupération des paquets non correctement reçus conformément à l'invention ; - la Figure 8 représente, de manière schématique, l'architecture matérielle et / ou logicielle d'un client conformément à l'invention ; et la Figure 9 représente, de manière schématique, l'architecture matérielle et / ou logicielle d'un système d'émission conforme à l'invention.
Une description détaillée des procédés de réception et d'émission de paquets de données relatifs à un fichier conformes à l'objet de l'invention est fournie ci-après en référence à la Figure 1.
L'émission de manière cyclique de paquets de données en mode multicast conforme à l'invention s'appuie sur une architecture composée notamment d'au moins un serveur de diffusion multicast SERV. Celui-ci comprend, en mémoire, un ensemble de fichiers qu'il peut émettre si une machine cliente, aussi appelée « client », en fait la requête.
Le mode de diffusion multicast fonctionne sur le protocole UDP
(<•<• User Datagram Protocol » en terminologie anglaise) et tout client peut y accéder, à condition toutefois d'y être autorisé par un fournisseur d'accès
Internet.
Le protocole UDP est un protocole de remise de paquets simple, non fiable, sans connexion préalable, appartenant à la couche 4 du modèle OSI, c'est-à-dire à la « couche transport ». Cette couche est en charge du transport des données, de leur découpage en paquets et de la gestion des éventuelles erreurs de transmission, cette dernière fonctionnalité n'étant toutefois pas disponible en mode UDP. Le protocole susmentionné est détaillé dans le document RFC 768. Il est particulièrement adapté pour transmettre des données très rapidement et lorsque la perte d'une partie de ces données n'a pas d'incidence, ou pour transmettre de petites quantités de données, là où la connexion « 3-WAY » TCP s'avère très lourde à gérer (« 3 WAY » TCP est un mécanisme d'établissement de connexion reposant sur l'envoi d'un paquet de demande de connexion, l'envoi en retour d'un paquet d'acquittement accompagné d'une demande de synchronisation en sens inverse et l'envoi par l'émetteur d'un acquittement final). Tout comme le protocole TCP, le protocole UDP utilise un système de ports sur lesquels les clients doivent se connecter.
Le serveur de diffusion conforme à l'invention est apte à émettre de manière cyclique, des données support d'information. Cette émission cyclique est aussi connue sous le nom de « diffusion en mode carrousel ». L'architecture selon l'invention comprend également un gestionnaire de ressources GR. Celui-ci possède une base de données de l'ensemble des fichiers que le serveur de diffusion ou les serveurs de diffusion qui lui sont associés sont aptes à diffuser. En outre, il gère la liste de l'ensemble des clients, connectés au service de téléchargement. Les clients réceptionnent donc des données support d'information en cours de diffusion multicast.
Toutefois, dans une variante de mise en œuvre, le gestionnaire de ressources et le serveur de diffusion peuvent être un seul et même serveur.
Une autre variante de réalisation comprend une configuration dans laquelle chacun des clients est également un serveur multicast et tous les clients sont gérés par un unique gestionnaire de ressources. De cette manière, le gestionnaire de ressources centralise les informations de disponibilité des différents fichiers proposés par les clients.
Une telle configuration permet, tout d'abord, à l'opérateur proposant ce service d'élargir son offre de fichiers disponibles. Ensuite, il est à noter que l'utilisation possible de plusieurs serveurs de capacité réduite est plus économique, à quantité d'informations égale, qu'un serveur de grande capacité. Cette configuration présente également l'avantage que le gestionnaire de ressources est contrôlé par le fournisseur de services. Ce dernier peut donc vérifier la liste de fichiers proposés par les clients et empêcher que son service ne serve à la diffusion de fichiers à caractère illégal. II peut ainsi, notamment, supprimer ces fichiers de la liste gérée par le gestionnaire de ressources, sans avoir à intervenir sur les ordinateurs des clients.
Dans l'exemple illustré par la Figure 1 , le système comprend un gestionnaire de ressources GR et un serveur de diffusion SERV associé. Un exemple d'architecture matérielle et / ou logicielle d'un tel système est représenté en Figure 9 et sera décrite ultérieurement.
A l'état initial du système, aucun exemplaire de fichier n'est en cours de diffusion.
Les procédés d'émission et de réception conformes à l'invention et illustrés sur la Figure 1 débutent par la connexion d'un client A au gestionnaire de ressources GR en mode unicast (étape 1).
Un exemple d'architecture matérielle et / ou logicielle d'un client est représenté en Figure 8 et sera décrite ultérieurement.
Ensuite, le client émet une requête (étape 2) afin d'obtenir la liste des fichiers gérés et accessibles par le serveur de diffusion SERV associé à ce gestionnaire de ressources GR. Ce dernier retourne en réponse (étape 3) la liste des fichiers disponibles et le client sélectionne le fichier souhaité. Dans l'exemple considéré, il s'agit du fichier « mise_à_jour_logiciel».
L'étape suivante (étape 4) consiste en l'émission par le client d'une requête au gestionnaire de ressources GR afin d'obtenir le fichier « mise_àjour_logiciel».
Le gestionnaire de ressources détermine si ce fichier est déjà en cours d'émission par le serveur de diffusion SERV ou non.
Dans la négative, le gestionnaire de ressources GR émet une requête au serveur de diffusion SERV (étape 5) afin que ce dernier débute l'émission, en mode cyclique, du fichier demandé par le client A (destinataire du fichier). Cette requête comprend, en outre, les paramètres de connexion nécessaires pour gérer la diffusion en mode multicast, à savoir, l'adresse et le port multicast ainsi que le débit de diffusion. Le serveur, au moyen de ces paramètres, est apte à débuter l'émission du contenu du fichier en mode multicast de manière cyclique à destination du ou des clients qui en ont fait la demande préalablement.
Le serveur de diffusion émet au gestionnaire de ressources GR un acquittement (étape 6) indiquant par la même qu'il va débuter la diffusion, en mode multicast, du fichier demandé. L'utilisation du mode de transmission multicast présente les avantages suivants.
Tout d'abord, les membres du groupe de diffusion sont dynamiques, ce qui permet aux hôtes de rejoindre et de quitter le groupe à tout moment.
Ensuite, la capacité des hôtes à se joindre aux groupes multi-destinataires est exploitée, notamment via l'envoi de messages IGMP (« Internet Group Management Protocol » en terminologie anglo-saxonne).
En outre, les groupes ne sont pas limités en taille et les membres peuvent être répartis à travers plusieurs réseaux IP.
Sur réception de l'acquittement du serveur de diffusion, le gestionnaire de ressources GR envoie au client A les informations suivantes (étape 7).
Tout d'abord, il envoie les différents paramètres nécessaires à un abonnement multicast, afin de réceptionner les données relatives au fichier requis. Ensuite, il peut informer le client de la taille et du nom du fichier en cours d'émission.
L'abonnement est notamment réalisé selon la procédure IGMP. Il s'agit d'un protocole utilisé pour accéder à un groupe multicast IP ou pour le quitter. Tous les hôtes IP supportant le mode multicast doivent supporter le protocole IGMP dont il existe plusieurs versions. Elles font toutes l'objet de nombreuses RFC auprès de l'organisme de normalisation W3C. Le client, sur réception des paramètres du gestionnaire de ressources GR crée un fichier vide, notamment du même nom que celui indiqué dans les paramètres fournis par ledit gestionnaire et de la taille indiquée également par celui-ci. Parallèlement à cette étape, le serveur de diffusion SERV débute la diffusion en mode multicast du fichier (étape 8).
Pour ce faire, le contenu du fichier est élaboré sous la forme de paquets et chaque paquet est ensuite émis sur le réseau.
Ensuite, le client fait une demande de connexion IGMP (étape 9) en utilisant les paramètres de connexion transmis par le gestionnaire de ressources GR.
Le client se connecte ainsi en mode UDP multicast afin de recevoir les paquets du fichier considéré, à savoir le fichier « mise-à-jour-logiciel » (étape 10). L'abonnement IGMP n'est acquitté par le serveur de diffusion au client qu'après la demande d'ouverture d'un point de connexion (ou « socket ») UDP avec pour paramètres une adresse IP dans la plage des adresses multicast et un port (Ce mécanisme est intrinsèque au TCP).
Le mécanisme d'adhésion est géré par les couches basses des couches ISO. Du point de vue du développeur, il s'agit uniquement d'ouvrir un socket avec les paramètres multicast définis par la normalisation.
Le protocole UDP ne gérant pas l'ordonnancement des paquets de données émis et reçus, les paquets diffusés par le serveur de diffusion SERV doivent contenir une information déterminant la place relative de chaque paquet dans le fichier considéré.
En outre, le protocole UDP ne gérant pas l'intégrité des données transmises, les paquets contiennent une information de vérification de l'intégrité des données reçues, permettant ainsi la détection des paquets non correctement reçus. Pour toutes ces raisons, le serveur de diffusion émet des paquets, notamment des paquets d'une taille constante, comprenant une entête (21) indiquant la position du paquet à insérer dans le fichier à la réception chez le client, les données support d'information (22) et une information (23), telle qu'un code CRC (« Cyclic Redundancy Check » en terminologie anglo-saxonne) permettant de vérifier l'intégrité des données reçues, comme représenté en Figure 2. Le code CRC, aussi appelé « contrôle de redondance cyclique » est un type de redondance de hachage utilisé pour produire une somme de contrôle (appelée « checksum » en terminologie anglo-saxonne) qui est un entier calculé à partir d'un bloc de données dans le but de détecter les erreurs de transmission ou de copie. Il peut également permettre la réparation de ces erreurs.
Lorsque le client reçoit les paquets (étape 10 de la figure 1), ces derniers sont mémorisés à leur position relative dans le fichier après contrôle de l'intégrité du contenu de chaque paquet reçu, notamment par le code CRC contenu dans le paquet. En cas d'échec lors de la vérification de l'intégrité, la position du paquet dans le fichier est mémorisée dans un fichier d'erreurs, aussi appelé « logs d'erreurs ».
Le fichier susmentionné contient, notamment, l'identifiant des paquets perdus ou des paquets reçus mais erronés. Ces paquets sont appelés paquets « non correctement reçus ». Le fichier d'erreurs est utilisé ultérieurement pour récupérer les paquets ainsi détectés et identifiés comme non correctement reçus.
Au fur et à mesure, le client mémorise les paquets relatifs au fichier demandé dans le fichier initialement vide et qui est créé tel qu'illustré en Figure 3.
Selon un mode de réalisation, durant le transfert des paquets du fichier requis, le client reste connecté de manière permanente au gestionnaire de ressources GR. Ce dernier effectue, de manière périodique, un test sur le client pour vérifier que celui-ci est toujours connecté et est en cours de réception des paquets diffusés. Selon une alternative de réalisation, le client envoie, régulièrement ou non, une trame d'information (notification) au gestionnaire de ressources GR pour lui signaler qu'il est toujours en cours de réception d'un fichier.
Il est à noter que ces alternatives ne sont pas mutuellement exclusives.
Ce mécanisme permettant de vérifier que le client est toujours en cours en réception du fichier émis en mode multicast est aussi appelé « keep alive ».
Cette connexion est réalisée notamment selon le protocole TCP, ce qui permet d'éviter des déconnexions accidentelles et la perte de paquets. En effet, le protocole TCP définit un ensemble de règles qui permettent la bonne communication entre deux ordinateurs à travers un ou plusieurs réseaux interconnectés. Le protocole TCP agit en mode connecté et offre une communication bidirectionnelle simultanée. En outre, c'est un service de transport fiable. Pour cela, il définit la structure des données et des acquittements échangés et spécifie comment détecter et corriger une perte ou une duplication de paquets.
En cas de déconnexion volontaire ou accidentelle d'un client, le gestionnaire de ressources GR met à jour le nombre de clients du fichier en cours de diffusion. En outre, le gestionnaire de ressources GR commande, lors d'une déconnexion, la suppression de la connexion multicast du client correspondant. Cette déconnexion peut signifier, par exemple, que le client est déconnecté et donc qu'il ne peut plus rien recevoir.
La gestion du « keep alive » concerne l'interrogation du client par le gestionnaire de ressources ou par le client émettant des trames d'information à destination du gestionnaire de ressources. Cette gestion est réalisée en utilisant la connexion initialement créée lors de la connexion du client au gestionnaire de ressources en vue d'obtenir un fichier, c'est-à-dire en utilisant le même port de connexion (ou socket). La Figure 4 illustre la connexion d'un second client au système de diffusion, le serveur de diffusion étant en cours d'émission du fichier requis par un premier client et, ce dernier étant toujours en cours de réception dudit fichier. Tel qu'illustré en Figure 2, le second client (client B) émet une première requête (étape 41) afin de consulter la liste des fichiers disponibles sur le gestionnaire de ressources GR. Ce dernier, en réponse, lui envoie la liste des fichiers disponibles (étape 42). Ensuite, le client B émet une requête au gestionnaire de ressources GR contenant l'identifiant du fichier qu'il souhaite charger (étape 43). Dans l'exemple considéré, il s'agit du fichier « mise_a_jour_logiciel ».
Sur réception de cette requête, le gestionnaire de ressources GR constate que ce fichier est déjà en cours d'émission par les serveurs de diffusion SERV.
Sans dialoguer avec le serveur de diffusion, le gestionnaire de ressources GR répond au client B en lui transmettant les mêmes paramètres de connexion que pour le client A (étape 44), à condition toutefois, que le client B puisse supporter la réception du fichier au débit en cours. Sur réception de ces paramètres, le client B, comme le client A, crée un fichier vide, par exemple du même nom que le nom du fichier émis et de la taille indiquée dans les paramètres.
Ensuite, le client B effectue une demande de connexion en mode UDP multicast afin de se mettre en réception des paquets du fichier demandé (étape 45).
Le fichier n'étant pas nécessairement en début de diffusion par le serveur de diffusion lors du début de la réception par le client B, le premier paquet reçu par le client B (étape 46) est inséré dans le fichier à la place indiquée par les informations d'en-tête du paquet, tel qu'illustré sur la Figure 5. La partie manquante, à savoir le début du fichier, ne sera reçue qu'au cycle suivant d'émission du fichier.
Les différentes étapes illustrées en Figure 4, et décrites précédemment, sont applicables à tout client souhaitant télécharger un fichier en cours de diffusion par le serveur de diffusion SERV. La Figure 6 illustre la gestion des déconnexions des clients du gestionnaire de ressources GR, et incidemment du serveur de diffusion SERV. La gestion des connexions et déconnexions des clients permet de demander au serveur de diffusion le début et l'arrêt de la diffusion du fichier à diffuser. Cette gestion des connexions a pour avantage de faire circuler sur le réseau des données seulement lorsque le fichier est requis, • ce qui limite l'encombrement du réseau.
Pour ce faire, lorsqu'un client a fini de recevoir le fichier, il le notifie au gestionnaire de ressources GR par l'émission d'un message (étape 61 ).
Sur réception d'un tel message, le gestionnaire de ressources GR décrémente alors le nombre d'abonnés selon le protocole IGMP sur le fichier en cours de diffusion.
Lorsque le gestionnaire de ressources GR détecte qu'il n'y a plus de clients qui sont en cours de chargement du fichier émis, il envoie une notification au serveur de diffusion SERV pour que ce dernier arrête l'émission cyclique du fichier (étape 62). Le serveur de diffusion SERV stoppe donc l'émission du fichier
(étape 63), sans attendre la fin du cycle de diffusion. Ce fichier n'est donc plus diffusé en carrousel.
Comme précédemment décrit, tous les clients sont connectés en mode unicast avec le gestionnaire de ressources GR. Ce mode de connexion permet au gestionnaire de ressources GR de déterminer si les clients sont toujours connectés et réceptionnent le fichier en cours de diffusion.
Si la connexion est interrompue, le gestionnaire de ressources GR considère que le client a abandonné la réception du fichier (étape 64).
Selon un mode de réalisation particulier, le gestionnaire de ressources émet une requête à destination des clients qui sont connectés à lui en mode unicast.
Selon une alternative, les clients émettent des trames d'information au gestionnaire de ressources (étape 65).
On détermine de la sorte si la connexion est toujours en cours et, par conséquent, si le client est toujours en cours de réception du fichier émis en mode multicast de manière cyclique. II est à noter qu'un gestionnaire de ressources GR peut gérer une pluralité de serveurs de diffusion, ces serveurs pouvant être répartis en différents endroits sur le réseau.
En support de la Figure 1, il a été décrit que le client détecte les paquets non correctement reçus, et que l'identifiant de ces paquets est mémorisé dans un fichier d'erreurs.
Dans la plupart des cas, le client ne peut pas s'abstraire des paquets non correctement reçus, puisqu'un fichier contenant un logiciel n'est pas exécutable si des parties sont erronées ou manquantes. Le client doit donc gérer les paquets non correctement reçus en vue de les récupérer ultérieurement.
Un mode de réalisation d'un tel procédé de gestion des paquets non correctement reçus est maintenant décrit en support de la Figure 7.
L'algorithme débute à l'étape 71 par la gestion des paquets non correctement reçus.
Cette étape est suivie de l'étape 72 qui constitue une étape de décision quant au mode de récupération des paquets identifiés comme non correctement reçus.
L'étape de décision dépend d'un critère, ce dernier étant notamment fonction du nombre de paquets identifiés comme non correctement reçus et de la période de cycle d'émission des paquets du fichier.
Si les paquets non correctement reçus sont contigus et si la période de cycle de diffusion du fichier n'est pas excessivement longue, alors l'algorithme se poursuit par une étape 73. Au cours de cette étape, la récupération des paquets identifiés comme non correctement reçus est effectuée au cours du cycle suivant de diffusion du fichier.
L'algorithme se termine par l'étape 74, au cours de laquelle le client se déconnecte du serveur de diffusion et notifie au gestionnaire de ressources GR que la réception a pris fin.
Si le nombre de paquets non correctement reçus est faible, si les paquets sont peu contigus et si la période de cycle de diffusion du fichier est élevée, alors la récupération des paquets peut être réalisée de la manière indiquée aux étapes suivantes 75 à 79.
Tout d'abord, le client se déconnecte du serveur de diffusion et le notifie au gestionnaire de ressources GR (étape 75). Ensuite, le client établit une connexion en mode unicast avec un serveur pour récupérer les paquets identifiés comme non correctement reçus (étape 76).
On notera que la connexion en mode unicast peut être réalisée sur le serveur de diffusion ou sur un autre serveur, notamment un serveur miroir du serveur de diffusion.
Cette connexion est réalisée notamment en mode TCP de manière à s'assurer de l'intégrité des données.
Au cours de l'étape suivante 77, le client émet au moins une requête contenant l'identifiant d'au moins un paquet à récupérer. Le serveur, sur réception de la ou des requêtes, répond en envoyant au client les paquets qui ont déjà été émis en mode multicast mais, cette fois, les paquets sont envoyés en mode unicast.
L'étape 78 correspond à la réception des paquets chez le client et à la mémorisation, dans le fichier, des données support d'information contenues dans le paquet, notamment après vérification de l'intégrité des données.
L'algorithme se termine à l'étape 79 par la déconnexion du serveur.
Dans une variante de réalisation non représentée, la connexion du client au serveur de diffusion ou à un autre serveur en vue de récupérer les paquets non correctement reçus peut être réalisée selon le protocole UDP. Dans ce cas, à l'issue de l'étape 78, le client doit vérifier l'intégrité des données, et si ce dernier détecte des problèmes, il doit réémettre une requête. Dans ce cas, l'algorithme boucle à l'étape 77 jusqu'à l'obtention de l'ensemble des paquets non correctement reçus.
Selon une autre variante de réalisation non représentée, la connexion du client à un serveur de diffusion ou à un autre serveur en vue de récupérer les paquets non correctement reçus est réalisée simultanément à la connexion multicast au serveur de diffusion. Cette variante présente l'avantage d'obtenir les paquets non correctement reçus identifiés lors du début de la réception d'un fichier avant la fin d'un cycle de transmission multicast du fichier. Cette variante est particulièrement intéressante lors de la réception de fichier de taille importante. Cette variante de réalisation peut nécessiter la mise en œuvre d'une gestion particulière pour compter les paquets perdus, notamment, d'une gestion statistique du nombre de paquets perdus. Cette gestion doit permettre, notamment, de déterminer si la connexion unicast est maintenue durant toute la réception du fichier en mode multicast, ou si la connexion unicast est établie plusieurs fois durant des périodes plus étroites.
Selon une variante de réalisation, le serveur de diffusion peut émettre le fichier selon un débit qui peut être adapté, notamment en fonction des charges maximum supportées par chacun des clients.
Différentes adaptations peuvent être réalisées. Une première méthode consiste à réadapter le débit de diffusion en prenant en compte la plus faible capacité en termes de ressources parmi les clients, à condition, toutefois, que l'écart avec les capacités des autres clients ne soit pas trop contraignant pour ces derniers.
Une seconde méthode consiste à créer un nouveau canal de diffusion multicast avec un débit différent. Quand un nouveau client se connecte, on lui affecte le canal de diffusion le plus approprié à ses capacités de débit.
Si un client n'est pas apte à recevoir les paquets émis avec un débit donné, alors le gestionnaire de ressources GR peut créer un nouveau canal de diffusion multicast avec un débit inférieur.
Le gestionnaire de ressources GR peut également gérer plusieurs plages de débit sur lesquelles il affecte les différents clients, par exemple, 4Mb/s, 2Mb/s, 512kb/s, 128kb/s. Les différentes plages peuvent être paramétrées par le gestionnaire de ressources GR. Selon encore un autre mode de réalisation non représenté, on dispose d'au moins deux serveurs de diffusion multicast, chacun étant apte à émettre le même flux de données selon des débits différents. Ceci permet de répondre à des contraintes techniques liées aux capacités de réception des différents clients.
Selon cette configuration, les informations émises par le serveur de diffusion haut débit sont émises par un serveur de diffusion de plus faible débit avec un certain décalage temporel.
Ainsi, selon cette configuration, un client en réception d'un flux émis par le serveur de diffusion haut débit peut également utiliser le serveur de diffusion de plus faible débit et se connecter à celui-ci, en vue de récupérer tout ou partie des paquets identifiés comme non correctement reçus. La Figure 8 représente un exemple d'architecture matérielle et/ou logicielle d'un client conformément à l'invention et qui est mise en œuvre de la façon décrite en référence aux Figures 1 , 4, 6 et 7.
Un client 81 , notamment le client A, comprend, d'une part, des moyens de gestion d'une communication 82 en vue de recevoir un fichier en mode multicast, et d'autre part, des moyens de gestion d'une communication en mode unicast 83 en vue de recevoir les paquets non correctement reçus.
Plus particulièrement, les moyens de gestion 82 comprennent des moyens d'établissement d'une connexion en mode unicast avec le gestionnaire de ressources 84 et des moyens d'émission d'une requête 85 en vue de demander l'obtention d'un fichier donné.
Les moyens de gestion 82 comprennent également des moyens de réception 86 des paramètres de réception du fichier permettant la connexion au serveur de diffusion, et des moyens d'établissement de la connexion en mode multicast 87 en utilisant les paramètres de réception reçus. Les moyens de gestion 82 comprennent en outre des moyens de réception et de mémorisation 88 du fichier diffusé en mode multicast par un serveur de diffusion et des moyens de détection 89 des paquets non correctement reçus parmi les paquets du fichier qui ont été émis.
En outre, les moyens de gestion 82 comprennent des moyens d'émission 90 d'une notification de fin de réception du fichier. Enfin, les moyens de gestion 82 comprennent des moyens d'émission 91 de trames d'information afin d'indiquer que le client est en cours de réception d'un fichier émis en mode multicast.
Les moyens de gestion de la communication unicast 83 comprennent, quant à eux, des moyens de décision 92 de l'émission d'au moins une requête en mode unicast auprès d'un serveur de téléchargement.
En outre, les moyens de gestion 83 comprennent des moyens d'établissement d'une connexion unicast 93 avec un serveur de chargement en vue d'obtenir les paquets non correctement reçus, des moyens d'émission 94 d'au moins une requête unicast à ce serveur de chargement, ainsi que des moyens de réception et de mémorisation 95 des paquets requis.
La Figure 9 représente un exemple d'architecture matérielle et/ou logicielle d'un système d'émission de paquets de données conformément à l'invention et qui est mise en œuvre de la façon décrite en référence aux Figures 1 , 4 et 6.
Le système d'émission de paquets de données 100 comprend au moins un serveur de diffusion 101 , au moins un gestionnaire de ressources 102 et au moins un serveur de téléchargement 103. On notera que ledit au moins un serveur de diffusion 101 , ledit au moins un gestionnaire de ressources 102 et ledit au moins un serveur de téléchargement 103 peuvent être réalisés selon un seul composant matériel et / ou logiciel.
Le serveur de diffusion 101 est apte à diffuser de manière cyclique en mode multicast des paquets formant un fichier vers au moins un destinataire. Il comprend, notamment, des moyens d'émission de paquets 104, des moyens de démarrage 105 de l'émission des paquets d'un fichier donné et des moyens d'arrêt 106 de l'émission du fichier.
En outre, le serveur de diffusion 101 comprend des moyens d'adaptation 107 du débit de l'émission des paquets en fonction des charges supportées par les destinataires des paquets. Le gestionnaire de ressources 102 comprend des moyens de réception 108 d'une requête pour obtenir un fichier en mode multicast. En outre, le gestionnaire de ressources 102 comprend des moyens 109 d'incrémentation du nombre de destinataires du fichier en cours d'émission par un serveur de diffusion associé au gestionnaire de ressources.
Le gestionnaire 102 comprend également, des moyens de détermination 110 du nombre de destinataires en cours de réception du fichier émis, ces moyens de détermination étant aptes à décrémenter le nombre de destinataires du fichier sur réception d'une notification de fin de réception du fichier. De plus, il comprend des moyens 111 pour informer le serveur de diffusion qu'il doit arrêter l'émission d'un fichier. Le serveur de téléchargement 103 comprend des moyens de réception 112 d'au moins une requête émise en mode unicast en vue d'obtenir des paquets déjà émis vers le destinataire émetteur de la requête et des moyens d'émission 113 en mode unicast des paquets requis.
Selon un exemple de réalisation, le serveur de téléchargement 103 peut être également un serveur de diffusion 102.

Claims

REVENDICATIONS
1. Procédé de réception de paquets de données relatifs à un fichier, le fichier étant composé d'une pluralité de paquets, le procédé comprenant une étape de réception (10, 46) de paquets émis de manière cyclique en mode multicast, caractérisé en ce que le procédé comprend les étapes suivantes :
- détection des paquets non correctement reçus parmi les paquets du fichier qui ont été émis ;
- pour au moins une partie des paquets identifiés comme non correctement reçus : o émission d'au moins une requête (77) en mode unicast pour obtenir lesdits paquets ; et o réception desdits paquets (78).
2. Procédé de réception selon la revendication 1 , caractérisé en ce que les paquets étant identifiés par leur position relative dans le fichier, le procédé comprend en outre une étape de mémorisation des paquets reçus à leur position relative dans le fichier.
3. Procédé de réception selon la revendication 1 ou la revendication 2, caractérisé en ce que les paquets comprennent au moins une information de vérification de l'intégrité des données.
4. Procédé de réception selon l'une quelconque des revendications précédentes, caractérisé en ce que l'étape d'émission de ladite au moins une requête en mode unicast est subordonnée à une étape préalable de décision (72) dont la réalisation dépend d'un critère prédéterminé.
5. Procédé de réception selon l'une quelconque des revendications précédentes, caractérisé en ce qu'il comprend, préalablement à l'étape de réception de paquets, une étape d'émission (4, 43), à destination d'un gestionnaire de ressources, d'une requête pour obtenir ledit fichier.
6. Procédé de réception selon la revendication 5, caractérisé en ce qu'il comprend, préalablement à l'étape d'émission d'une requête pour obtenir ledit fichier, une étape d'établissement d'une connexion en mode unicast (1) avec le gestionnaire de ressources.
7. Procédé de réception selon la revendication 5 ou 6, caractérisé en ce qu'il comprend une étape de réception (7, 44), en provenance du gestionnaire de ressources, de paramètres de réception dudit fichier.
8. Procédé selon l'une quelconque des revendications précédentes, caractérisé en ce qu'il comprend en outre une étape d'émission (65) en mode unicast d'une notification informant d'une réception en cours dudit fichier.
9. Procédé de réception selon l'une quelconque des revendications précédentes, caractérisé en ce qu'il comprend en outre une étape d'émission d'une notification de fin de réception (61) dudit fichier.
10. Procédé d'émission de paquets de données relatifs à un fichier, le fichier étant composé d'une pluralité de paquets, lesdits paquets ayant été préalablement émis de manière cyclique en mode multicast vers au moins un destinataire (8), caractérisé en ce que le procédé comprend les étapes suivantes :
- réception d'au moins une requête émise en mode unicast en vue d'obtenir des paquets déjà émis vers ledit au moins un destinataire et non correctement reçus par ce dernier ; et
- émission en mode unicast des paquets requis.
11. Procédé d'émission selon la revendication 10, caractérisé en ce que les paquets comprennent une information identifiant leur position relative dans le fichier.
12. Procédé d'émission selon la revendication 10 ou la revendication 11 , caractérisé en ce que les paquets comprennent en outre au moins une information de vérification de l'intégrité des données.
13. Procédé d'émission selon l'une quelconque des revendications
10 à 12, caractérisé en ce qu'il comprend une étape préalable de réception d'une requête (4, 43) pour obtenir le fichier en mode multicast.
14. Procédé d'émission selon la revendication 13, caractérisé en ce qu'il comprend une étape d'incrémentation du nombre de destinataires du fichier, consécutivement à la réception d'une requête pour obtenir le fichier.
15. Procédé d'émission selon l'une quelconque des revendications 10 à 14, caractérisé en ce qu'il comprend les étapes suivantes : - détermination du nombre de destinataires en cours de réception dudit fichier ; et
- si le nombre de destinataires est égal à zéro, arrêt de l'émission du fichier (62).
16. Procédé d'émission selon l'une quelconque des revendications
10 à 15, caractérisé en ce qu'il comprend, en outre, une étape d'adaptation du débit de l'émission des paquets en fonction des charges supportées par des destinataires.
17. Procédé d'émission selon l'une quelconque des revendications
10 à 16, caractérisé en ce que l'étape de réception d'au moins une requête en mode unicast en vue d'obtenir des paquets déjà émis vers au moins un destinataire et non correctement reçus par ce dernier et l'étape d'émission en mode unicast des paquets requis sont effectuées par un serveur de téléchargement.
18. Procédé d'émission selon l'une quelconque des revendications 13 à 15, caractérisé en ce que, au moins l'une des étapes suivantes :
- de réception d'une requête pour obtenir le fichier en mode multicast, - d'incrémentation du nombre de destinataires du fichier,
- de détermination du nombre de destinataires en cours de réception dudit fichier, est effectuée par un gestionnaire de ressources.
19. Dispositif de réception de paquets de données relatifs à un fichier, le fichier étant composé d'une pluralité de paquets, le dispositif comprenant des moyens de réception (86) de paquets émis de manière cyclique en mode multicast, caractérisé en ce que le dispositif comprend :
- des moyens de détection (89) des paquets non correctement reçus parmi les paquets du fichier qui ont été émis ;
- des moyens d'émission (94) d'au moins une requête en mode unicast pour obtenir lesdits paquets ; et
- des moyens de réception (95) desdits paquets.
20. Dispositif de réception selon la revendication 19, caractérisé en ce que le dispositif comprend des moyens d'établissement (93) d'une connexion en mode unicast avec un serveur de téléchargement en vue d'obtenir les paquets non correctement reçus.
21. Dispositif de réception selon la revendication 20, caractérisé en ce que le serveur de téléchargement est un dispositif de diffusion des paquets en mode multicast.
22. Système d'émission de paquets de données relatifs à un fichier, le fichier étant composé d'une pluralité de paquets, lesdits paquets ayant été préalablement émis de manière cyclique en mode multicast vers au moins un destinataire, caractérisé en ce que le système comprend : - des moyens de réception (112) d'au moins une requête émise en mode unicast en vue d'obtenir des paquets déjà émis vers ledit au moins un destinataire et non correctement reçus par ce dernier ; et
- des moyens d'émission (113) en mode unicast des paquets requis.
23. Système d'émission selon la revendication 22, caractérisé en ce que le serveur de téléchargement est un dispositif de diffusion des paquets en mode multicast.
24. Programme d'ordinateur stocké sur un support d'informations, ledit programme contenant des instructions permettant la mise en œuvre du procédé de réception de paquets de données relatifs à un fichier selon l'une quelconque des revendications 1 à 9, lorsque ce programme est chargé et exécuté par un système informatique.
25. Programme d'ordinateur stocké sur un support d'informations, ledit programme contenant des instructions permettant la mise en œuvre du procédé d'émission de paquets de données relatifs à un fichier selon l'une quelconque des revendications 10 à 18, lorsque ce programme est chargé et exécuté par un système informatique.
26. Composant programmable adapté à exécuter les instructions d'un programme d'ordinateur selon la revendication 24.
EP07731853A 2006-03-31 2007-04-02 Procede et dispositif d'emission et de reception de paquets de donnees relatifs a un fichier emis de maniere cyclique en mode multicast Withdrawn EP2005647A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR0651160A FR2899410A1 (fr) 2006-03-31 2006-03-31 Procede et dispositif d'emission et de reception de paquets de donnees relatifs a un fichier emis de maniere cyclique en mode multicast
PCT/FR2007/051049 WO2007113447A1 (fr) 2006-03-31 2007-04-02 Procede et dispositif d'emission et de reception de paquets de donnees relatifs a un fichier emis de maniere cyclique en mode multicast

Publications (1)

Publication Number Publication Date
EP2005647A1 true EP2005647A1 (fr) 2008-12-24

Family

ID=37763780

Family Applications (1)

Application Number Title Priority Date Filing Date
EP07731853A Withdrawn EP2005647A1 (fr) 2006-03-31 2007-04-02 Procede et dispositif d'emission et de reception de paquets de donnees relatifs a un fichier emis de maniere cyclique en mode multicast

Country Status (3)

Country Link
EP (1) EP2005647A1 (fr)
FR (1) FR2899410A1 (fr)
WO (1) WO2007113447A1 (fr)

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
PL2335381T3 (pl) 2008-09-30 2013-06-28 France Telecom Sposób przesyłania danych przez źródło przesyłania grupowego z przesyłaniem identyfikatora strategii przesyłania w kanale sygnalizacji przesyłania grupowego

Family Cites Families (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP1185033A4 (fr) * 2000-04-06 2004-06-23 Ntt Docomo Inc Procede et systeme de multidiffusion, station mobile et station de base
US7143132B2 (en) * 2002-05-31 2006-11-28 Microsoft Corporation Distributing files from a single server to multiple clients via cyclical multicasting

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
None *
See also references of WO2007113447A1 *

Also Published As

Publication number Publication date
FR2899410A1 (fr) 2007-10-05
WO2007113447A1 (fr) 2007-10-11

Similar Documents

Publication Publication Date Title
WO2006016055A2 (fr) Procede et serveur de referencement de diffusion poste a poste de fichiers demandes par telechargement a ce serveur
FR2805112A1 (fr) Procede et unite de controle de flux d&#39;une connexion tcp sur un reseau a debit controle
WO2006111635A1 (fr) Procede et systeme de transmission d’un flux multicast en reseau d’echange de donnees
EP3603024B1 (fr) Procédé de recommandation d&#39;une pile de communication
FR2824930A1 (fr) Procede de communication et/ou de partage de ressources machines, au sein d&#39;un reseau de communication, entre une pluralite de membres d&#39;une communaute
FR2949931A1 (fr) Procedes et dispositifs de transmission d&#39;un flux de donnees, produit programme d&#39;ordinateur et moyen de stockage correspondants.
FR2870022A1 (fr) Procede et dispositif de distribution de donnees numeriques notamment pour reseau pair-a-pair
WO2008087364A2 (fr) Procede de transmission/reception en temps reel de donnees par paquets entre un serveur et un terminal client, serveur et terminal correspondants
FR3029376A1 (fr) Procede de traitement d&#39;une requete de livraison de donnees, dispositif, module proxy, terminal client et programme d&#39;ordinateur associes
FR3034943A1 (fr) Procede de lecture en continu sur un equipement client d&#39;un contenu diffuse au sein d&#39;un reseau pair a pair
FR2946164A1 (fr) Procede de telechargement de donnees de grande taille vers un grand nombre de machines clientes en reseau a partir d&#39;un serveur unique
EP2005647A1 (fr) Procede et dispositif d&#39;emission et de reception de paquets de donnees relatifs a un fichier emis de maniere cyclique en mode multicast
EP3231190B1 (fr) Procédé et dispositifs permettant une transmission d&#39;un flux de données selon un mode de transmission multipoint
WO2020193429A1 (fr) Procédé d&#39;obtention d&#39;un segment de données par un dispositif client apte à communiquer avec une pluralité de réseaux de diffusion de contenu
WO2019220034A1 (fr) Gestion du téléchargement progressif adaptatif d&#39;un contenu numérique au sein d&#39;un terminal de restitution d&#39;un réseau de communication local
FR2904503A1 (fr) Procede d&#39;acces par un client a un service au travers d&#39;un reseau, par utilisation combinee d&#39;un protocole de configuration dynamique et d&#39;un protocole point a point, equipement et programme d&#39;ordinateur correspondants
EP3414873B1 (fr) Procédé de transmission de données dans une communication multi-chemin
WO2020260825A1 (fr) Procede de gestion d&#39;une communication entre terminaux dans un reseau de communication, et dispositifs et systeme pour la mise en oeuvre du procede
EP1647125A1 (fr) Description de contenu de paquets dans un reseau de communication par paquets
EP2446608B1 (fr) Technique de contrôle d&#39;accès par une entité cliente à un service
WO2016055645A1 (fr) Procédé de diffusion de contenus en streaming dans un réseau pair à pair
EP4272449A2 (fr) Contrôle de la transmission d&#39;au moins un contenu depuis un equipement fournisseur vers un noeud d&#39;ingestion
WO2013144494A1 (fr) Dispositif et procede de gestion pour un service reseau
FR3124668A1 (fr) Procédé de contrôle de la livraison partagée d’un contenu
FR2951045A1 (fr) Procede de gestion de la taille de paquets de donnees d&#39;un flux de donnees, produit programme d&#39;ordinateur, moyen de stockage, et tete de tunnel correspondants.

Legal Events

Date Code Title Description
PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

17P Request for examination filed

Effective date: 20081021

AK Designated contracting states

Kind code of ref document: A1

Designated state(s): AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HU IE IS IT LI LT LU LV MC MT NL PL PT RO SE SI SK TR

17Q First examination report despatched

Effective date: 20120210

DAX Request for extension of the european patent (deleted)
RAP1 Party data changed (applicant data changed or rights of an application transferred)

Owner name: ORANGE

GRAP Despatch of communication of intention to grant a patent

Free format text: ORIGINAL CODE: EPIDOSNIGR1

INTG Intention to grant announced

Effective date: 20171025

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE APPLICATION IS DEEMED TO BE WITHDRAWN

18D Application deemed to be withdrawn

Effective date: 20180306