FR2946164A1 - Procede de telechargement de donnees de grande taille vers un grand nombre de machines clientes en reseau a partir d'un serveur unique - Google Patents

Abstract

La présente invention exploite les capacités de multidiffusion des réseaux associées à un protocole fiable orienté connexion. Le procédé de l'invention permet de ne transférer un fichier qu'une fois. Les données, qui représentent un gros volume d'information, empruntent les canaux de multidiffusion, alors que les échanges relatifs au contrôle de la qualité de la communication empruntent un médium fiable en mode connecté. Afin d'éliminer les transferts (réseau) et l'activité (serveur et client) inutiles, un calcul établi sur l'intégralité des données du fichier est effectué pour l'identifier à coup sûr.

Description

PROCEDE DE TELECHARGEMENT DE DONNEES DE GRANDE TAILLE VERS UN GRAND NOMBRE DE MACHINES CLIENTES EN RESEAU A PARTIR D'UN SERVEUR UNIQUE La présente invention se rapporte à un procédé de téléchargement de données de grande taille vers un grand nombre de machines clientes en réseau à partir d'un serveur unique. Les systèmes utilisés dans le domaine du transfert de fichiers sans limite de taille dans un environnement fortement distribué sur réseau W sont généralement composés d'un terminal serveur source et de nombreux terminaux clients cibles connectés par des switches et/ou des routeurs. On a schématisé en figure 1 un système du type de celui auquel s'applique l'invention. Dans un tel système, un serveur 1 comporte un fichier 2 devant être transféré via un réseau de transmission 3 à un ensemble de clients 4 qui enregistrent ce fichier sur un disque correspondant, l'ensemble des fichiers ainsi enregistrés étant référencé 5. Sur ce schéma, pour la clarté du dessin, on n'a pas représenté les switches et/ou routeurs faisant partie du réseau 3. Le téléchargement des informations doit être effectué le plus vite possible, de manière sûre, en réduisant le temps d'usage du réseau et en évitant les transferts inutiles. Les solutions actuelles FTP, ssh/scp proposent un temps de transfert proportionnel au nombre de clients. En utilisant une arborescence de machines comportant des brins réseau distincts, les temps de transfert sont proportionnels au logarithme à base 2 du nombre total de machines : t = tu x log2(N) avec t le temps total de chargement de toutes les machines cibles, tu le temps de transfert d'un fichier de point à point et N le nombre de machines cibles. Cela reste insuffisant dans les contextes d'utilisation où le temps d'indisponibilité du système informatique est coûteux (avionique civile), ou directement lié à la sécurité des personnes (santé, défense).

Des solutions plus rapides, utilisant des protocoles non connectés et des adresses de diffusion, existent mais ne garantissent pas que les données envoyées seront reçues et ne proposent pas de mécanismes de ré-émission. Leur manque de fiabilité les confine à des applications de niches.

Quand les fichiers préexistent sur les cibles, il est nécessaire de déterminer s'ils sont à jour ou s'il est indispensable de transférer une nouvelle version de ces fichiers ; il n'existe pas de comparaison fiable de fichiers, avant transfert, intégrée aux protocoles existants. Il est donc souvent réalisé des transferts inutiles.

La réémission pour chaque client des mêmes informations implique que, vu du réseau, le fichier transite un grand nombre de fois, ce qui implique des performances médiocres et des problèmes de sécurité informatique. La présente invention a pour objet un procédé de téléchargement de données de grande taille, par exemple de plusieurs centaines de Mo, vers un grand nombre de machines clientes en réseau à partir d'un serveur unique, procédé réduisant le temps d'usage du réseau et en évitant les transferts inutiles, à temps de transfert le plus réduit possible et garantissant que les données envoyées seront reçues, tout en proposant des mécanismes de ré-émission et assurant une bonne sécurité informatique. La présente invention a également pour objet un système de mise en oeuvre de ce procédé. Le procédé conforme à l'invention est caractérisé en ce qu'il consiste à transmettre les fichiers de grande taille sur un media multidiffusant, et les informations de contrôle sur une liaison fiable en point-à-point. Selon une caractéristique de l'invention, le protocole de diffusion sur média 20 diffusant est de type MCastFTP. La présente invention sera mieux comprise à la lecture de la description détaillée d'un mode de réalisation, pris à titre d'exemple non limitatif et illustré par le dessin annexé, sur lequel : - la figure 1 est un bloc-diagramme simplifié d'un système connu dans 25 lequel peut être mise en oeuvre l'invention, et - la figure 2 est un bloc-diagramme simplifié d'un système de mise en oeuvre du procédé conforme à la présente invention. La présente invention est décrite en détail ci-dessous en référence à la diffusion de vidéo à la demande (VOD), mais il est bien entendu qu'elle n'est pas 30 limitée à cette application, et qu'elle peut être mise en oeuvre dans différentes applications nécessitant la transmission de flots d'information importants (par exemple des fichiers d'au moins plusieurs centaines de Mo) entre un média multidiffusant et une liaison fiable point-à-point. Cette diffusion est faite par un serveur, comportant au moins un ordinateur, vers plusieurs (au moins trois, mais ce nombre peut même être supérieur à 100) ordinateurs clients. Un exemple d'application peut être la diffusion de vidéo à bord d'un aéronef.

Le système conforme à l'invention et schématisé en figure 2 est similaire à celui représenté en figure 1, les mêmes éléments ou des éléments similaires étant affectés des mêmes références numériques. La différence entre ces deux systèmes réside essentiellement dans le processus de transmission de fichiers (par multidiffusion) et d'informations de contrôle via des moyens de transmission différents, ces informations de contrôle étant transmises par une liaison fiable pointà-point, et sont en particulier des informations relatives au contrôle de la qualité de la réception des fichiers, comme décrit en détail ci-dessous. Le serveur 1 possède la liste 6 de tous ses clients potentiels 4 et la gère en temps réel de façon à connaitre les clients connectés (sous-ensemble de la liste 6). Il informe, par transmission point-à-point, ces clients de l'émission imminente d'un fichier 2. Chaque client connecté peut vérifier, au moyen de données de contrôle, qui sont ici des données d'information relatives au fichier 2 à diffuser et transmises par le serveur, le besoin réel de mise à jour du fichier 5 qu'il a reçu précédemment. Le serveur émet, sur un réseau de multidiffusion classique, ces données par paquets de longueur fixe (13), à un débit régulé, au moyen d'un protocole diffusant (par exemple selon le protocole MCastFTP qui peut être la combinaison des protocoles TCP et UDP). La longueur des paquets ainsi transmis est déterminée de façon évidente pour l'homme du métier à la lecture de la présente description, car elle est fonction de la qualité du média physique assurant la transmission et du nombre de réémissions nécessaires pour que le plus grand nombre possible de clients puissent recevoir l'intégralité des fichiers attendus. Cette longueur des paquets est fixe pour au moins chaque fichier transmis, mais peut être ajustée dynamiquement pour chaque fichier suivant si les conditions de transmission varient au cours du temps, mais cela nécessite une communication par question/réponse entre le serveur et les clients par les liens connectés, qui sont fiables. De façon générale, plus une liaison est bonne, plus il est préférable de transmettre de gros paquets, car, quand les paquets sont trop petits, le protocole utilise trop de données pour sa synchronisation au détriment des données utiles. Les clients réceptionnent les données, reconstituent (14) le fichier à partir de ces paquets, et établissent au fur et à mesure un bilan des pertes (10) de données du fichier. En fin d'émission du fichier, le serveur 1 obtient le bilan de réception de chaque client connecté en utilisant le protocole orienté connexion (12). Le serveur opère l'union des bilans (11) et détermine ainsi les paquets à réémettre. La réémission suit le même principe qu'exposé précédemment. Quand un client dispose de tous les paquets, il vérifie la validité de la reconstitution locale du fichier (14) et émet le résultat au moyen du protocole orienté connexion à l'attention du serveur. Quand tous les clients ont reçu le fichier, le serveur est de nouveau prêt à émettre un autre fichier. De façon à garantir une efficacité globale, des temporisations aux différents étages du protocole sont armées pour éliminer les clients qui sont dans l'impossibilité de le respecter (trop lents, en panne, etc).

On décrit ci-dessous un exemple d'application selon lequel un utilisateur souhaite mettre à jour un ensemble de vidéos numériques sur plusieurs de ses serveurs, par exemple sur une dizaine de serveurs de VOD (Video On Demand, non représentés sur le dessin). Il émet alors une demande de connexion (7) selon un protocole orienté connexion, par exemple TCP pour les réseaux W. Cette demande est traitée dans le serveur 1 par une application 8 de gestion des connexions, et le serveur identifie cet utilisateur à l'aide de sa liste 6 de clients. Une application dédiée du serveur 1 (connue en soi) est alors utilisée pour déposer les films (découpés à la volée) dans un répertoire déterminé 9 sur le serveur. Considérons que le réseau, les routeurs sont opérationnels, que les logiciels participants MCastFTP (clients et serveur) ont été démarrés et qu'ils sont en veille. L'utilisateur indique au serveur MCastFTP la liste des fichiers à distribuer sur ses propres serveurs de VOD (ensemble 4). Dans un premier temps, les participants MCastFTP (clients et serveur) établissent leurs connexions puis le serveur 1 émet (en mode connecté) une notification de départ d'émission imminente contenant le nom du fichier, sa taille et sa somme de contrôle MD5 (MD5: Message Digest 5 , explicité par: http://www.ietf.org/rfc/rfc1321.txt), et les clients doivent acquitter réception de cette notification. Sous contrôle d'une temporisation R1, les accusés de réception des clients sont acheminés vers le serveur par le réseau grâce aux connexions point-à-point de ce réseau. Les clients n'ayant pas accusé réception dans un temps imparti sont éliminés de ce transfert, mais ils seront contactés pour le prochain transfert. Un client MCastFTP peut acquitter de deux façons différentes : soit il possède déjà ce fichier, dans la version du serveur, contrôlé par MD5, et dans ce cas il acquitte par la négative, soit il ne le possède pas, ou pas dans la version requise, et il acquitte positivement. La valeur de la temporisation R1 doit prendre en compte le temps nécessaire au calcul MD5, non négligeable sur de très gros fichiers (>2Go par exemple). Le serveur 1 enchaîne par la suite l'envoi de paquets de taille fixe (ce paramètre doit être ajusté aux capacités du réseau, de façon connue en soi), numérotées, sur le media diffusant (UDP pour les réseaux W) et la réception des acquittements des clients se fait au moyen des connexions point-à-point du réseau 3.

L' attente des acquittements est limitée par une temporisation R2. Les clients écrivent les paquets reçus dans un fichier local à un emplacement calculé à partir de l'index du paquet (son rang dans l'ensemble des paquets à transmettre). L'emplacement des paquets manquants ou erronées est donc réservé et rempli de valeurs zéro ou aléatoires selon le système de fichiers utilisé. Une fois l'envoi du fichier terminé, le serveur recommence avec les paquets perdus par au moins un client (On observe sur les réseaux W que rares sont les pertes localisées, en général 30 à 50% des clients sont impactés, la réémission reste donc efficace sur lien diffusant plutôt qu'en pointà-point.), jusqu'à complétude. Les clients qui ne font pas remonter d'acquittement sont éliminés du transfert de ce fichier, ils seront contactés lors de l'émission du prochain fichier. En fin de réception du fichier, chaque client calcule la somme MD5, la compare et la remonte au serveur, et ce, pendant le laps de temps imparti par la temporisation R1. Les fichiers suivants sont traités de la même façon. En fin de transfert de tous les fichiers, le serveur 1 MCastFTP a la connaissance de l'état des transferts de tous les clients. En fonction d'un tableau de bord, constitué de la liste des clients, de leur état (joignable ou non, réactif ou non), de la liste des fichiers transmis avec succès et de la liste des fichiers dont le transfert a échoué et la raison de chaque échec affiché à l'utilisateur, celui-ci peut décider de relancer l'opération jusqu'à complétude si les pannes observées sont transitoires.

Ainsi, en exploitant les capacités de multidiffusion des réseaux associées à un protocole fiable orienté connexion, le procédé de l'invention permet de ne transférer un fichier qu'une fois. Les données, qui représentent un gros volume d'information, empruntent les canaux de multidiffusion, alors que les échanges relatifs au contrôle de la qualité de la communication empruntent un médium fiable en mode connecté.

Afin d'éliminer les transferts (réseau) et l'activité (serveur et client) inutiles, un calcul établi sur l'intégralité des données du fichier est effectué pour l'identifier à coup sûr. Après que l'identifiant a été propagé, chaque client informe le serveur du besoin réel de transfert. Ceci permet ne réduction drastique du temps de transfert de fichiers, proportionnel à la taille du fichier, et non pas proportionnel au nombre de clients. Le calcul du temps de transfert devient : T = Tf . (1 + ps + pr + pj Avec : T le temps de transfert du fichier Tf le temps de transfert d'un paquet F~ le nombre de paquets du fichier Ps la probabilité de perte de paquet à l'émission : saturation de la file de paquets, collisions... Pr la probabilité de perte de paquet par le réseau : liens, routeurs, ponts... la probabilité de perte de paquet par un client : incapacité à dépiler les paquets suffisamment vite, goulets d'étranglement dans la chaîne de reconstitution du fichier et d'écriture sur disque... Cette probabilité met en lumière l'influence du nombre de client sur la performance globale. PC25 On notera que dans la pratique, sur réseau W, le terme (1+ ps + pr + p.) est très inférieur à F, , ce qui permet d'affirmer que le temps de transfert est proportionnel à la taille du fichier (nombre de paquets).

Claims (10)

1. REVENDICATIONS1. Procédé de téléchargement de données de grande taille vers un grand nombre de machines clientes en réseau à partir d'un serveur unique, caractérisé en ce qu'il consiste à transmettre les fichiers de grande taille sur un media multidiffusant, et les informations de contrôle sur une liaison fiable en point-à-point.
2. 2. Procédé selon la revendication 1, caractérisé en ce que le protocole de diffusion sur média multidiffusant est de type MCastFTP.
3. 3. Procédé selon la revendication 1 ou 2, caractérisé en ce que les informations de contrôle comportent des informations relatives au contrôle de la qualité de la réception des fichiers, des données d'information relatives aux fichiers transmises par le serveur, le bilan de réception de chaque client connecté, la validité de la reconstitution locale du fichier, des accusés de réception des clients.
4. 4. Procédé selon l'une des revendications précédentes, caractérisé en ce que la multidiffusion des fichiers se fait par paquets.
5. 5. Procédé selon l'une des revendications précédentes, caractérisé en ce 20 que le serveur transmet pour chaque fichier sa somme de contrôle de type MD5.
6. 6. Procédé selon l'une des revendications précédentes, caractérisé en ce que pour chaque fichier envoyé, les clients reconstituent le fichier à partir des paquets reçus, établissent au fur et à mesure un bilan des 25 pertes de données du fichier et accusent réception de chaque fichier au serveur.
7. 7. Procédé selon la revendication 6, caractérisé en ce que les clients n'ayant pas accusé réception au serveur dans un temps imparti sont éliminés de ce transfert, mais sont contactés pour le prochain 30 transfert.
8. 8. Procédé selon la revendication 6 ou 7, caractérisé en ce que lorsque le serveur reçoit au moins une demande de connexion d'un client 5 10demandant l'envoi d'un fichier, avant d'envoyer ce fichier, le serveur émet une notification de départ d'émission imminente contenant le nom du fichier, sa taille et sa somme de contrôle.
9. 9. Procédé selon la revendication 8, caractérisé en ce que chaque client acquitte de deux façons différentes : soit il possède déjà ce fichier, dans la version du serveur, et dans ce cas il acquitte par la négative, soit il ne le possède pas, ou pas dans la version requise, et il acquitte positivement.
10. 10. Système de téléchargement de données de grande taille vers un grand nombre de machines clientes en réseau à partir d'un serveur unique, caractérisé en ce qu'il met en oeuvre le procédé selon l'une des revendications précédentes.