FR2924241A1

FR2924241A1 - Serveur de telechargement a deux ports et procede associe

Info

Publication number: FR2924241A1
Application number: FR0708211A
Authority: FR
Inventors: Eric Pageron
Original assignee: Thales SA
Current assignee: Thales SA
Priority date: 2007-11-23
Filing date: 2007-11-23
Publication date: 2009-05-29
Anticipated expiration: 2027-11-23
Also published as: FR2924241B1; US20090138550A1

Abstract

L'invention divulgue un dispositif et un procédé de chargement de fichiers vers un applicatif distant qui utilise un protocole standard de type http tout en permettant un suivi d'avancement dudit chargement. A cet effet, il est prévu un deuxième port qui permet l'affichage de la mesure de l'avancement effectuée sur le serveur où est localisé l'applicatif. L'invention est particulièrement utile pour l'exploitation et la maintenance des applications embarquées sur aéronef pour lesquelles les normes prescrites par les compagnies aériennes imposent un suivi d'avancement pour les transferts dans les deux directions.

Description

SERVEUR DE TELECHARGEMENT A DEUX PORTS ET PROCEDE ASSOCIE

La présente invention appartient au domaine des dispositifs et procédés de téléchargement de fichiers vers un applicatif distant. Plus particulièrement, l'invention permet de mettre à disposition de l'utilisateur une fonctionnalité importante de suivi d'avancement de l'export de fichier vers cet applicatif distant dans le cadre de l'utilisation du protocole http, standard des échanges sur Internet. Aujourd'hui, seul l'import de fichiers peut faire l'objet d'un suivi d'avancement sur le client. Ainsi, ce protocole n'est pas utilisable pour les applications qui imposent un suivi d'avancement pour les chargements de fichiers dans les deux directions. C'est notamment le cas pour la maintenance des applications embarquées sur aéronef, qu'elles soient critiques ou non. La norme applicable aux téléchargements sur applications embarquées sur un aéronef liées à un réseau Ethernet est la norme ARINC (Aeronautical Radio Inc.) 615A ayant pour titre Software data loader using Ethernet interface , ie Logiciel de chargement de données utilisant une interface Ethernet . La norme 665-1 sur les logiciels téléchargeables est également applicable en ce qu'elle détermine les formats d'échanges, notamment les en-têtes de fichier, et les processus de contrôle d'intégrité. La norme ARINC 615A impose en particulier le contrôle d'avancement pour les transferts dans les deux sens. Http n'étant pas de ce fait applicable, la norme recommande l'utilisation d'un protocole spécifique, TFTP (Trivial File Transfer Protocol ou Protocole élémentaire de transfert de fichiers). Cette spécificité impose l'usage de clients propriétaires dont les licences ont un coût élevé ce qui pose problème à de nombreux utilisateurs La présente invention résout ce problème en permettant le suivi d'avancement du téléchargement de fichiers vers une application distante par le protocole standard http.

A cet effet l'invention divulgue un serveur de téléchargement de fichiers sur un module applicatif à partir d'un poste client résident sur un équipement informatique connecté au serveur par un réseau de communication, ledit serveur utilisant un protocole de type http, caractérisé en ce que l'état d'avancement des transactions sur un premier port est transmis au client par une communication sur un deuxième port.

L'invention divulgue également un procédé de téléchargement associé au serveur. L'invention qui utilise un protocole standard et ouvert présente en outre l'avantage de pallier un autre inconvénient du protocole propriétaire TFTP dont l'évolutivité est faible, les clients de maintenance n'étant pas dotés d'outils de programmation d'interfaces (API) permettant une adaptation aux besoins de l'utilisateur. L'invention sera mieux comprise et ses différentes caractéristiques et avantages ressortiront de la description qui suit de plusieurs exemples de réalisation dans les cas d'application de la norme A615A et de ses figures annexées dont : - La figure 1 représente l'architecture du serveur de téléchargement selon l'invention ; La figure 2 représente l'enchaînement des traitements du procédé selon l'invention ; - La figure 3 représente l'enchaînement des traitements du procédé selon l'invention dans le mode chargement d'un fichier vers l'applicatif distant ; La figure 4 représente l'enchaînement des traitements du procédé selon l'invention dans le mode déchargement d'un fichier de l'applicatif distant ; La figure 5 représente l'enchaînement des traitements du procédé selon l'invention dans le mode déchargement d'une liste de fichiers de l'applicatif distant ; - La figure 6 représente l'enchaînement des traitements du procédé selon l'invention dans le mode fourniture d'informations sur les fichiers présents sur l'applicatif distant.

Sur la figure 1, le serveur 10 implanté sur un premier équipement informatique 20 sert à gérer les téléchargements de fichiers nécessaires à la maintenance ou à l'exploitation d'un module applicatif implanté sur l'équipement 20. Ces téléchargements sont gérés par un utilisateur qui utilise pour ce faire un module de téléchargement 30 implanté sur un deuxième équipement informatique 40 qui peut être un PC portable ou fixe ou un matériel spécifique. Les équipements informatiques 20, 40 sont reliés entre eux par une connexion 50 qui peut être par exemple un réseau Ethernet. D'autres réseaux sont envisageables, par exemple un réseau téléphonique filaire de type RTC (Réseau Téléphonique Commuté) ou ADSL (Asymetric Digital Subscriber Line) ou bien une connexion hertzienne (Wi-Fi, réseau privé ou réseau téléphonique public). Le protocole http permet l'échange de pages entre un client (ici le module 30 implanté sur l'équipement 40) et un serveur (ici le serveur 10 implanté sur l'équipement 20). Un utilisateur de 40 est en mesure de décharger des fichiers résidant sur l'équipement 20 (fonction Download ). Il peut également transférer des fichiers de son poste vers l'équipement 20 (fonction Upload ). Dans le premier cas, il n'y a aucune difficulté à assurer le suivi d'avancement du transfert du fichier car le module de téléchargement est informé dès le début du transfert de la taille du fichier attendu et la mesure d'avancement est effectuée à la réception sur le poste client qui peut afficher en permanence le ratio de transfert et/ou sa valeur absolue. Connaissant en outre le débit moyen du réseau connectant les équipements, il est aussi possible d'afficher la durée attendue au moment du début du transfert et le temps restant en cours de transfert. Dans le second cas de transfert du client vers le serveur, la connaissance par le poste client de l'avancement du transfert vers le serveur supposerait la communication du serveur vers le client d'informations élaborées sur ledit serveur. En effet, l'avancement réel de l'upload n'est disponible qu'en sortie de réseau sur l'équipement 20. Toute information élaborée sur le client sans information sur ce qui est réellement arrivé sur le serveur est nécessairement fausse. Or, le transfert de fichiers sous http serait forcément interrompu par l'envoi d'une information sur l'état d'avancement de 20 vers 40 sur le même port de communication. D'où l'idée de l'invention d'utiliser un deuxième port 81 pour transférer les informations d'avancement de 20 vers 40, alors que le transfert utilise lui-même un premier port 80. Il est possible d'ouvrir plusieurs ports de communication sur un serveur http. De fait, pour des raisons de sécurité, il est souvent préférable de limiter les possibilités de communications entre un serveur connecté au réseau Internet à un seul port. Cette limitation n'existe pas dans le cas de serveurs connectés à un réseau privatif. En outre, dans le cas de serveurs connectés à Internet, il est possible d'ouvrir plusieurs ports, à condition de prendre les précautions nécessaires pour filtrer les accès via tous les ports ouverts. Comme indiqué sur la figure 1, dans le cas où deux ports sont ouverts sur le serveur http implanté sur l'équipement 20, l'un 80 (c'est en fait l'adresse par défaut d'un port ouvert sur un serveur http) est dédié à l'échange de données, l'autre 81 à la communication au client de l'information de suivi, élaborée et mise en forme sur le serveur http. La page comprenant cette information de suivi (taux d'avancement, volume et éventuellement estimation d'un temps restant) est transmise sur le réseau au poste client 40 en réponse à des requêtes GET envoyées périodiquement, par exemple toutes les 5 secondes, par le module 30 au serveur 10. Le procédé de téléchargement de l'invention pallie un inconvénient important du protocole http, par exemple lorsqu'un utilisateur doit transférer des fichiers volumineux vers un site Internet, comme c'est le cas pour les particuliers des '15 sites de réalisation d'albums de photographies. Il est également très avantageux dans le cas des applications qui imposent, pour des raisons de contrôle, un suivi de l'avancement dans les deux sens de téléchargement, comme c'est le cas des applications avioniques. Aujourd'hui, en raison des limitations indiquées ci-dessus du protocole http, le standard ARINC 615A 20 prescrit l'utilisation d'un protocole propriétaire TFTP. Aux inconvénients déjà indiqués précédemment (coût des licences, absence d'API), il faut ajouter une certaine lenteur d'évolution qui fait que ce protocole n'intègre qu'avec retard les derniers mécanismes de sécurité les plus fiables d'authentification et de transfert sécurisé. L'invention permet se dispenser de l'utilisation de ce 25 protocole propriétaire et d'utiliser le protocole http tout en satisfaisant aux autres contraintes du standard A615A. La solution proposée est la création d'un serveur http à double entrée (2 ports d'écoute) utilisant les fichiers des normes A615A et A665 pour gérer les téléchargements : • le 1 er port (dont la valeur est 80 par défaut) est le port principal 30 d'échange des données • le 2ème port (dont la valeur est libre) est un port qui sert uniquement à la remontée des informations de suivi (statut, avancement de téléchargement...) Le serveur répond à toutes les requêtes http sur son 1 er port. Sur le 2eme port, 35 il accepte tout type de requête mais renvoie toujours la même page html contenant les informations nécessaires au suivi du déroulement de la transaction réalisée sur le 1 er port. Avec ce type de serveur, l'utilisation du protocole http et de clients Web devient possible pour le téléchargement des logiciels sur un module avionique. II est possible d'utiliser n'importe quel ordinateur équipé d'une interface Ethernet et d'un système d'exploitation type Windows. L'application embarquée (le serveur http) se charge de gérer l'interface homme/machine et tous les aspects du transfert. Enfin, le fabricant du module a la possibilité de personnaliser à volonté l'interface proposée à l'opérateur chargé du téléchargement et d'offrir des services évolués comme l'accès sécurisé par exemple. Les coûts de réalisation d'interface Web sont très faibles. Cette interface peut être très simple ou très sophistiquée. Le standard A615A prévoit la réalisation au minimum de quatre fonctions : une fonction upload , une fonction download , une fonction Media defined download de déchargement collectif d'une liste prédéterminée de fichiers résidant sur le module applicatif et une fonction informations de mise à disposition sur le client d'informations relatives aux fichiers présents sur le module applicatif. Ainsi cinq adresses URL (Uniform Resource Locator) au minimum seront disponibles sur le port 80, les adresses elles-mêmes étant données à titre purement illustratif : - L'index (Ex : http://10.0.3.1/ ) : Page d'accueil du logiciel de téléchargement. Cette page affiche les caractéristiques du module (Identification TARGET HW_ID, TARGET TYPE, Nom et Logo du constructeur), les services proposés (upload, download, Media defined download, information) ; - Upload (Ex : http://10.0.3.1/upload) : Page permettant le téléchargement d'un fichier du client vers le module applicatif; - Download (Ex : http://10.0.3.1/download ) : Page permettant le téléchargement d'un fichier du module applicatif vers le client. Cette page ne doit proposer que les logiciels autorisés pour ce type de transfert (Event Log, Fault Log, Databases) ; - Information (Ex : http://10.0.3.1/information ) : Page affichant la liste détaillée des logiciels présents dans le module avec leur part-number, leur description, etc... - Media defined download (Ex : http://10.0.3.1/mediadefineddownload ) : Page permettant le téléchargement d'une liste prédéfinie de logiciels du client vers le module. Lorsque la liste est entièrement reçue, le serveur renvoie les fichiers demandés vers le client.

L'organigramme des traitements permettant l'initialisation de ces quatre fonctions est représenté sur la figure 2. L'utilisateur initialise une connexion sur son navigateur Web en rentrant l'URL de l'index ou en lançant la fonction GET.index.html. Cette connexion peut être précédée d'une phase d'authentification. Le serveur http génère alors la page html d'accueil comportant au minimum les quatre fonctions des standards, la page étant ensuite envoyée vers le client. L'utilisateur choisit alors l'opération à réaliser. Ce choix génère une commande GET vers le serveur qui génère alors la page correspondante.

La figure 3 représente l'organigramme des traitements de la fonction Upload . La page Upload générée sur le serveur est transmise au client. Elle permet à l'utilisateur de sélectionner le fichier à transférer du client vers le serveur. A la validation de la sélection, une requête POST Fichier encodée au format multipart/form-data est transmise sur le port 80 vers le serveur. Dans le cas des applications avioniques pour lesquelles le format des fichiers est régi par la norme ARINC 665, un fichier d'encapsulation, par exemple un fichier TAR (Tape ARchiver ou Bande archive), est généré à partir de tous les fichiers constituant le LOAD au sens de la norme. Le premier fichier du paquet doit obligatoirement être un fichier équivalent au fichier LUH (Load Upload Header) de cette norme qui a un format déterminé.

La fonction de récupération et d'analyse de données est alors activée sur le serveur. En début de transfert, l'en-tête de fichier est analysé pour vérifier la compatibilité du fichier à transférer avec l'applicatif sur lequel est implanté le serveur de téléchargement. En cours de transfert des CRC (Cyclic Redundancy Code) sont calculés par bloc de données. En fin de transfert, un CRC global est calculé à partir des CRC partiels de manière à valider l'intégrité des données transférées. En parallèle, sur le port 81 transitent des requêtes périodiques GET Status qui génèrent le calcul du taux d'avancement sur le serveur et le renvoi au client d'une page html comportant cette information. Lorsqu'une opération a démarré, le serveur doit renvoyer systématiquement à toute requête GET sur le deuxième port une page Web indiquant : - la progression du téléchargement le temps restant estimé - un bouton permettant l'annulation de l'opération Le premier port sert uniquement au transfert des données. Aucune page ne peut être transmise par le serveur sur ce port durant l'opération. Les données affichées sur la page transférée sur le deuxième port proviennent du processus qui gère le transfert en cours sur le premier port. Cette page peut être - soit affichée dans une fenêtre pop- up différente de la fenêtre principale du navigateur Web. Cette fenêtre pop-up doit être créée automatiquement par la page d'accueil à la 1 ère connexion. L'utilisateur pouvant fermer cette pop-up par erreur, la page d'accueil doit proposer un moyen de la restaurer. - soit affichée dans un cadre différent du cadre de la page d'accueil. Dans ce cas, l'écran principal du navigateur est divisé en 2 parties distinctes. L'utilisateur ne risque pas de faire disparaître la page. - soit affichée à la demande si l'utilisateur tape l'URL du 2ème port dans 20 une nouvelle fenêtre de son navigateur WEB. L'entête http de la page doit obligatoirement contenir un mécanisme permettant de demander automatiquement le rafraîchissement des données de la page au serveur : -soit par du code HTML comme <META HTTP-EQUIV="Refresh" 25 CONTENT="3;URL=http://10.0.3.1:81/"> soit par du code javascript avec la commande setTimeout.

La figure 4 représente l'organigramme des traitements de la fonction Download . Le fichier à transférer par le serveur est sélectionné sur une 30 page html générée sur le serveur http et transmise au client qui comporte la liste des liens aux fichiers transférables. Un clic sur un des liens génère une commande GET vers le serveur qui enclenche le transfert du fichier sélectionné. Dans ce sens, le suivi d'avancement peut être réalisé sur le même port car les informations sont disponibles sur le client. 35 La figure 5 représente l'organigramme des traitements de la fonction Media defined download . Cette fonction permet le déchargement groupé de plusieurs fichiers correspondant à des procédures usuelles définies par applicatif. Ces fichiers sont regroupés dans des fichiers LNR qui sont sélectionnés par l'utilisateur sur une liste transmise du serveur vers le client par une page html. L'envoi est précédé d'un contrôle d'erreurs (nom de fichier inconnu).

La figure 6 représente l'organigramme des traitements de la fonction Informations . Cette fonction permet la consultation d'une page html élaborée sur le serveur qui comprend une liste d'informations spécifiées par la norme 615A.

Les exemples de réalisation donnés ne viennent en rien diminuer la généralité de l'invention revendiquée qui s'applique à tout contexte applicatif à partir du moment où une information de suivi d'avancement du chargement d'un client vers un serveur utilisant un premier port http est élaborée sur le serveur et transmise sur un deuxième port dudit serveur. 25 30

Claims

REVENDICATIONS

1. Serveur de téléchargement de fichiers (10) sur un module applicatif (20) à partir d'un poste client (30) résidant sur un équipement informatique (40) connecté au serveur par un réseau de communication (50), ledit serveur utilisant un protocole de type http, caractérisé en ce que l'état d'avancement des transactions sur un premier port (80) est transmis au client (30) par une communication sur un deuxième port (81) .

2. Serveur de téléchargement selon la revendication 1 caractérisé en ce que le chargement des fichiers sur le module applicatif est soumis à autorisation préalable avant le début du transfert.

3. Serveur de téléchargement selon la revendication 2 caractérisé en ce que ladite autorisation préalable est notamment donnée à partir d'une analyse de la compatibilité des fichiers transférés avec l'applicatif distant.

4. Serveur de téléchargement selon la revendication 1 caractérisé en ce que le chargement des fichiers sur le module applicatif distant est soumis à acquittement après la fin du transfert.

5. Serveur de téléchargement selon la revendication 4 caractérisé en ce que l'acquittement après la fin de transfert est fourni après contrôle d'intégrité des éléments de fichier transférés.

6. Serveur de téléchargement selon la revendication 1 caractérisé en ce qu'il comporte au moins un mode choisi dans le groupe des fonctions chargement de fichiers vers l'applicatif distant, déchargement de fichiers de l'applicatif distant, déchargement d'un ensemble de fichiers de l'applicatif distant, fourniture d'informations sur les fichiers présents sur l'applicatif distant.

7. Procédé de téléchargement de fichiers sur un module applicatif (20) à partir d'un poste client (30) résident sur un équipement informatique (40) connecté au serveur par un réseau de communication (50), ledit serveur utilisant un protocole de type http, caractérisé en ce que l'état d'avancement des transactions sur un premier port (80) est transmis au client (30) par une communication sur un deuxième port (81).

8. Procédé de téléchargement selon la revendication 7 caractérisé en ce que le chargement des fichiers sur le module applicatif distant est soumis à autorisation préalable avant le début du transfert.

9. Procédé de téléchargement selon la revendication 8 caractérisé en ce que ladite autorisation préalable est notamment donnée à partir d'une analyse de la compatibilité des fichiers transférés avec l'applicatif distant.

10. Procédé de téléchargement selon la revendication 7 caractérisé en ce que le chargement des fichiers sur le module applicatif distant est soumis à acquittement après la fin du transfert.

11. Procédé de téléchargement selon la revendication 10 caractérisé en ce que l'acquittement après la fin de transfert est fourni après contrôle d'intégrité des éléments de fichier transférés.

12. Procédé de téléchargement selon la revendication 7 caractérisé en ce qu'il comporte au moins un mode choisi dans le groupe des fonctions chargement de fichiers vers l'applicatif distant, déchargement de fichiers de l'applicatif distant, déchargement d'un ensemble de fichiers de l'applicatif distant, fourniture d'informations sur les fichiers présents sur l'applicatif distant.