FR2899410A1 - 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

Abstract

L'invention concerne 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 (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 : émission (77) d'au moins une requête en mode unicast pour obtenir lesdits paquets ; et réception desdits paquets (78).

Description

10 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 15 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). 20 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 25 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 30 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 1 2

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 10 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 15 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 20 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é. 25 Il 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, 30 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. 3

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 4

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 5 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. 6

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 30 réception, notamment les paramètres de connexion des clients en mode multicast qui leur permettent de recevoir des paquets. 7

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. 8

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. 9

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 10 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. 15 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 : 20 - 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. 25 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 30 manière cyclique en mode multicast vers au moins un destinataire, caractérisé en ce que le système comprend : 10

- 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 oeuvre 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 oeuvre 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 25 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 30 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 11

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.

15 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 20 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 25 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 30 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. 10 12

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 oeuvre, 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é. 13

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.

Il 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). 14

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. 15

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 paquetest 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 16

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. 17

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. 18

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. 19

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. 20

Il 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 20 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. 25 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 30 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 21

é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. 22

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 oeuvre 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 23

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 oeuvre 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. 24

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 oeuvre 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. 25

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 (25)

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 10 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). 15

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. 20

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 25 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 30 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. 15

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, 20 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 25 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 30 que les paquets comprennent une information identifiant leur position relative dans le fichier.10

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 10 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 : 15 - 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). 20

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. 25

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 30 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 5 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. 10

24. Programme d'ordinateur stocké sur un support d'informations, ledit programme contenant des instructions permettant la mise en oeuvre 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 15 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 oeuvre du procédé d'émission de paquets de données relatifs à un fichier selon l'une 20 quelconque des revendications 10 à 18, lorsque ce programme est chargé et exécuté par un système informatique.