FR3078850A1 - Procede, dispositif et systeme permettant l'acces a une application deployee dans un conteneur - Google Patents

Procede, dispositif et systeme permettant l'acces a une application deployee dans un conteneur Download PDF

Info

Publication number
FR3078850A1
FR3078850A1 FR1852048A FR1852048A FR3078850A1 FR 3078850 A1 FR3078850 A1 FR 3078850A1 FR 1852048 A FR1852048 A FR 1852048A FR 1852048 A FR1852048 A FR 1852048A FR 3078850 A1 FR3078850 A1 FR 3078850A1
Authority
FR
France
Prior art keywords
application
clt
client device
app
disp
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Granted
Application number
FR1852048A
Other languages
English (en)
Other versions
FR3078850B1 (fr
Inventor
Alexandre Devely
Jeremy Petit
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Orange SA
Original Assignee
Orange SA
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Orange SA filed Critical Orange SA
Priority to FR1852048A priority Critical patent/FR3078850B1/fr
Publication of FR3078850A1 publication Critical patent/FR3078850A1/fr
Application granted granted Critical
Publication of FR3078850B1 publication Critical patent/FR3078850B1/fr
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/02—Protocols based on web technology, e.g. hypertext transfer protocol [HTTP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/10—Protocols in which an application is distributed across nodes in the network
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/2866—Architectures; Arrangements
    • H04L67/289—Intermediate processing functionally located close to the data consumer application, e.g. in same machine, in same home or in same sub-network
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/56—Provisioning of proxy services
    • H04L67/565—Conversion or adaptation of application format or content
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/56—Provisioning of proxy services
    • H04L67/567—Integrating service provisioning from a plurality of service providers

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Information Transfer Between Computers (AREA)
  • Stored Programmes (AREA)

Abstract

Dispositif (DA) permettant à un dispositif client (CLT) d'accéder à une application (APP), le dispositif (DA) exécutant un conteneur, dit "conteneur d'interface (C_IF)" et comportant : - un module de traitement (s_disp, s_snd, s_prn) configuré pour obtenir un événement (ev_disp, ev_snd, ev_prn) destiné à un périphérique de sortie (DISP, PRN, SND_out) du dispositif client (CLT) et généré par une application (APP) s'exécutant dans un conteneur d'application (C_APP); et - un module de communication (comm_disp, comm _snd, comm _prn) configuré pour générer et envoyer, sur obtention d'un dit événement (ev_disp, ev_snd, ev_prn), au moins un message (MSG_CLT) obtenu à partir de l'événement, destiné à et interprétable par le dispositif client (CLT).

Description

Arrière-plan de l'invention
L'invention se rapporte au domaine général de l'accès, depuis un terminal d'un utilisateur, à une application exécutée distante.
Parmi les solutions existantes permettant l'accès à une application distante, on connaît les solutions s'exécutant dans une machine virtuelle s'exécutant sur un serveur distant et accessible via un bureau virtuel VDI (Virtual Desktop Infrastructure).
Ces solutions présentent l'inconvénient de consommer des ressources (mémoire, capacité de calcul, ...) importantes au niveau du serveur, l'utilisation d'une machine virtuelle nécessitant en plus des ressources nécessaires à l'exécution de l'application elle-même, des ressources pour l'exécution d'un système d'exploitation complet, pour la gestion des librairies et éventuellement pour l'ordonnancement (scheduling) des applications.
On connaît également une solution consistant à installer et à exécuter (autrement dit à « déployer ») une application dans un conteneur d'application hébergé dans un serveur. Le conteneur d'une application ne comporte que le code binaire de l'application et les librairies requises par l'application, autrement dit ses dépendances. Cette solution permet d'optimiser les ressources système par rapport à l'installation d'une machine virtuelle puisque seuls le code de l'application et les librairies nécessaires à son exécution sont installés.
Cependant, il n'est pas possible, dans l'état actuel de la technique, de permettre à un utilisateur, d'interagir via une interface graphique de son dispositif client, avec une application s'exécutant dans un conteneur d'application.
L'invention vise une solution d'accès à une application distante qui ne présente pas les inconvénients des solutions existantes.
Objet et résumé de l'invention
Plus particulièrement, l'invention vise un procédé permettant à un dispositif client d'accéder à une application. Le procédé est mis en œuvre dans un conteneur, dit « conteneur d'interface », et comporte les étapes suivantes :
— démarrage d'un module de traitement susceptible d'obtenir au moins un événement destiné à un périphérique de sortie du dispositif client et généré par une application s'exécutant dans un conteneur d'application; et — sur obtention d'un tel événement, envoi d'au moins un message obtenu à partir de cet événement, destiné à et interprétable par ce dispositif client.
On rappelle qu'un conteneur, exécuté par une machine, est un ensemble de processus isolés du reste des autres processus s'exécutant sur la même machine. Un conteneur s'exécute à partir d'une image qui fournit les fichiers nécessaires à la prise en charge de ses processus.
De façon connue, une image est un ensemble de fichiers.
Un conteneur partage le système d'exploitation de la machine physique qui l'exécute.
Un conteneur d'une application comporte le code binaire de l'application et les librairies requises par l'application. De ce fait le conteneur assure la portabilité et la cohérence de l’application entre divers environnements. Le conteneur d'une application est autonome et autosuffisant pour s'exécuter.
Un conteneur d'interface selon l'invention comporte le code binaire d'une ou plusieurs fonctionnalités assurées par ce conteneur d'interface, tels qu'un code binaire d'un serveur logiciel, d'un démon ou d'une fonction de communication ou de conversion, et des librairies requises par la fonctionnalité.
Le dispositif client pouvant être utilisé dans le contexte de l'invention est un dispositif permettant l'accès à un site web, tel qu'un ordinateur, une tablette, un téléphone ou tout autre terminal utilisateur connecté.
L'invention permet de gérer différents types d'événement, par exemple des événements d’affichage, d’impression, de son...
Après l'exécution de l'étape de démarrage d'un module de traitement selon l'invention, le conteneur d'interface offre une couche logicielle permettant l’accès, à un utilisateur, via une interface de son dispositif client, à une application déployée dans un conteneur d’application et pouvant traiter des événements provenant de périphériques d'entrée du dispositif client et/ou générer des événements destinés à des périphériques de sortie du dispositif client.
Le conteneur d'interface constitue alors une interface entre le dispositif client et une application d'un conteneur d'application, l'application étant choisie par l'utilisateur. Ceci permet de renforcer la sécurité de l'utilisation de l'application en fournissant une isolation entre le conteneur d'interface et le conteneur d'application.
L'invention permet d'utiliser à distance des applications nécessitant de communiquer avec des périphériques du dispositif client, sans nécessiter l'ensemble des ressources nécessaires à l'utilisation d'une machine virtuelle.
L'invention peut être utilisée pour le télétravail. Un employeur ayant un dispositif client peut utiliser à distance et d'une façon sécurisée, des applications hébergées dans un réseau interne de l'entreprise, sans avoir besoin d'installer ces applications sur un dispositif client de l'employeur ou d'installer une machine virtuelle sur un serveur du réseau interne de l'entreprise. L'employeur peut accéder à une application hébergée dans le réseau interne via un navigateur web de son dispositif client. Le navigateur web assure différentes fonctions d'interface, par exemple une fonction d'affichage, en traitant des événements, par exemple des évènements d'affichage, générés par l'application.
L'invention peut aussi être utilisée pour permettre à un prestataire externe à une entreprise, un accès temporaire à des applications utilisées au sein du réseau interne de l'entreprise sans avoir besoin d'utiliser un dispositif client de l'entreprise. L'invention permet en effet la mise à disposition d'un poste de travail sécurisé. Le prestataire n'a besoin que de se connecter au conteneur d'interface pour pouvoir accéder à une application conteneurisée.
L'invention peut aussi être utilisée pour des sessions de formation. L'invention permet de proposer un poste de travail en ligne à chaque internaute, disposant de plusieurs applications nécessaires pour travailler.
Dans un mode de réalisation, l'application déployée dans un conteneur d'application est accessible via un navigateur web du dispositif client. Un utilisateur consulte, au moyen d'un dispositif client, un site web prédéfini via un navigateur web du dispositif client, au moyen par exemple d'une adresse prédéfinie, et s'authentifie pour se connecter à un conteneur d'interface. Le conteneur d'interface peut communiquer avec un ou plusieurs conteneurs d'application sur requête de l'utilisateur, via le dispositif client. Un utilisateur peut ainsi interagir avec une application déployée dans un conteneur d'application à travers le conteneur d'interface.
De ce fait, l'accès à une application selon l'invention est simple et rapide.
Le conteneur d'application et le conteneur d'interface peuvent être mis en œuvre dans un réseau en nuage.
Dans un mode de réalisation de l'invention, un utilisateur accède, en utilisant un dispositif client, à un site web consultable sur un navigateur web par exemple de type HTML, par exemple un navigateur de type Google Chrome, Firefox, Opéra 12 ou Safari 6 (marques déposées) supportant le langage HTML5 (version 5.2 du HTML datée du 21 décembre 2017).
Dans un mode particulier de réalisation de l'invention, un conteneur d'application ne déploie qu'une seule application, ce qui garantit un niveau de sécurité supplémentaire. En effet, les conteneurs sont étanches les uns par rapport aux autres. Par exemple, si une application déployée dans un conteneur dédié est corrompue (virus, espionnage, ou autre faille de sécurité), la propagation de la corruption se limite à l'environnement d’exécution de l'application corrompue, donc à son propre conteneur, et n'impacte pas les autres applications déployées dans un autre conteneur.
Toutefois, on peut aussi envisager qu'un conteneur d'application déploie plusieurs applications. Une propagation de la corruption d’une application déployée dans un conteneur se limite aux autres applications déployées dans le même conteneur.
Le conteneur d'interface peut communiquer avec plusieurs conteneurs d'application.
Corrélativement, l'invention vise un dispositif permettant à un dispositif client d'accéder à une application, ce dispositif exécute un conteneur, dit conteneur d’interface et comporte :
— un module de traitement configuré pour obtenir un événement destiné à un périphérique de sortie du dispositif client et généré par une application s'exécutant dans un conteneur d'application ; et — un module de communication configuré pour générer et envoyer, sur obtention d'un événement destiné à un périphérique de sortie du dispositif client, au moins un message obtenu à partir de l’événement, destiné à et interprétable par le dispositif client.
Dans un mode de réalisation, le module de traitement du conteneur d'interface est un module logiciel.
Les caractéristiques et avantages du dispositif selon l'invention présentés ci-après s'appliquent de la même façon au procédé selon l'invention.
Dans un mode de réalisation, le dispositif permettant à un dispositif client d'accéder à une application comporte en outre :
— un module de communication configuré pour obtenir un événement généré par un périphérique d'entrée du dispositif client; et — un module de traitement configuré pour générer et envoyer, sur obtention d'un événement généré par un périphérique d'entrée, au moins un message obtenu à partir de l'événement, destiné pour et pouvant être traité par une application s'exécutant dans un conteneur d'application.
Le dispositif conforme à l'invention permet au dispositif client d'utiliser une application, générant ou traitant des événements relatifs à des périphériques d'entrée ou de sortie du dispositif client, sans qu'elle soit installée sur le dispositif client et sans avoir besoin d'installer une machine virtuelle sur un serveur accessible par le dispositif client.
Dans un mode de réalisation, les modules de traitement et de communication exécutent des démons s'exécutant dans le conteneur d'interface.
On rappelle qu'un démon est un processus qui n'a pas d'interface avec un utilisateur et peut être référé comme un processus machine à machine (M2M).
Dans un mode de réalisation, le module de traitement configuré pour obtenir un événement destiné à un périphérique de sortie du dispositif client est le même que le module de traitement configuré pour générer et envoyer au moins un message obtenu à partir d’un événement généré par un périphérique d'entrée du dispositif client.
Dans un mode de réalisation, le module de communication configuré pour générer et envoyer au moins un message obtenu à partir d'un événement destiné à un périphérique de sortie du dispositif client, est le même que le module de communication configuré pour obtenir un événement généré par un périphérique d'entrée du dispositif client.
Le dispositif selon l'invention peut être mis en œuvre dans un réseau en nuage (cloud).
Il peut être placé en coupure entre le dispositif client et une machine exécutant un conteneur d’application.
Dans un mode de réalisation, le dispositif selon l'invention comporte en outre un module de conversion placé en coupure entre un module de traitement et un module de communication, le module de conversion étant configuré pour:
— convertir le format d'un événement généré par une application et destiné à un périphérique de sortie, en un format supporté par le module de communication; ou/et pour — convertir le format d'un événement généré par un périphérique d'entrée du dispositif client en un format supporté par le module de traitement.
Le module de conversion joue alors le rôle d'intermédiaire entre un module de traitement et un module de communication ne supportant pas un même standard de communication. Le dispositif conforme à l'invention peut donc présenter des ports côté dispositif client et des ports côté machine exécutant un conteneur d'application de natures différentes.
Dans un mode de réalisation, des communications internes au dispositif permettant à un dispositif client d’accéder à une application sont régies par des sockets de type fichier. Ces communications internes sont les communications entre le module de communication et le module de traitement, et éventuellement entre le module de communication et le module de conversion et entre le module de conversion et le module de traitement.
Comme il est plus difficile d’intercepter des sockets de type fichier que des sockets exportés du dispositif permettant l'accès à une application vers un réseau, tels que des sockets TCP, ce mode de réalisation permet alors de renforcer la sécurité informatique de l'invention.
Dans un mode de réalisation de l'invention, le conteneur d'interface, exécuté par le dispositif permettant d’accéder à une application, assure au moins un service parmi un service d'affichage, un service d'impression, un service de son, et un service de transfert de fichiers. Cette liste de services est non limitative. En pratique, chacun de ces services peut être mis en œuvre par un démon s'exécutant dans le conteneur d'interface.
L'invention permet donc de centraliser des modules de traitement des événements d'affichage, d'impression, de son, de transfert de fichiers ou autres serveurs logiciels, au niveau du conteneur d'interface, et d'implémenter des clients à ces modules de traitement, en fonction du besoin de chaque application, au niveau des conteneurs d'application.
De ce fait, un démon requis pour au moins deux applications différentes, tel qu'un module de traitement d'un événement d'impression, peut être partagé, en déployant le démon partagé dans le conteneur d'interface et en connectant le conteneur d'interface à au moins deux conteneurs d'application, déployant chacun une application.
Dans un mode de réalisation, le module de traitement est un serveur d'affichage configuré pour obtenir au moins un événement d'affichage généré par l’application et destiné à un écran du dispositif client.
Le conteneur d'interface offre une interface graphique avec laquelle l'utilisateur peut interagir.
L'utilisateur du dispositif client peut ainsi bénéficier d'une interface graphique de l'application déployée dans un conteneur.
Conformément à l'invention un écran du dispositif client désigne un écran physique, éventuellement tactile, ou un vidéo projecteur, ou autre périphérique d'affichage.
Dans un exemple d'implémentation de l'invention, le module de traitement d'un événement d'affichage est un serveur X.org, version Xll, v.11.0 (marque déposée).
Ce module de traitement implémente la gestion de l'écran, de la souris et du clavier du dispositif client.
Dans un mode de réalisation, le dispositif permettant à un dispositif client d’accéder à une application comporte en outre, un module configuré pour adapter le message obtenu à partir d'un événement d'affichage et destiné à l'écran du dispositif client à un paramètre d'affichage dudit écran (taille, résolution,...).
L'invention peut donc être utilisée par des dispositifs clients de différents tailles d'écran et ayant différentes résolutions graphiques. De plus, pour un dispositif client donné, l'affichage s'adapte à une modification ou un changement générés par une action de l'utilisateur, par exemple une modification de la résolution d'écran du dispositif client ou un changement de taille d'une fenêtre du navigateur.
Le module configuré pour adapter le message obtenu à partir de l'événement d'affichage peut contrôler l’exécution de l’application, par exemple en fermant une fenêtre d’interface graphique de l’application.
Dans une implémentation particulière, le module d’adaptation relatif à l’affichage est de type RPC (Remote Procedure Call).
Dans un mode de réalisation, le module de traitement est un serveur de son configuré pour obtenir au moins un événement de type son généré par l’application et destiné à un périphérique de sortie de son du dispositif client.
Dans un mode de réalisation, le module de traitement est un serveur d'impression configuré pour obtenir au moins un événement d'impression généré par l’application et destiné à une imprimante connectée au dispositif client.
Ce mode permet l'impression, par le dispositif client ou par une imprimante connectée au dispositif client, des documents obtenus par une application déployée dans un conteneur.
Dans un mode de réalisation, le dispositif permettant à un dispositif client d'accéder à une application comporte en outre un module configuré pour transférer au moins un fichier du dispositif client vers ou depuis un espace de stockage.
L’espace de stockage peut être compris dans un réseau en nuage et repéré par une adresse logique d'une ressource réseau de stockage, par exemple un chemin d'accès réseau à un dossier.
L’espace de stockage peut être un volume local au dispositif permettant à un dispositif client d'accéder à une application, par exemple un répertoire.
Ce mode de réalisation permet à un utilisateur de stocker des fichiers ou des documents dans un espace de stockage externe au dispositif client et de récupérer des fichiers de l’espace de stockage d’une façon sécurisée à travers le conteneur d’interface.
L’espace de stockage peut être partagé par plusieurs utilisateurs.
L'invention vise aussi un système permettant à un dispositif client d'accéder à une application, le système comportant :
— un dispositif permettant à un dispositif client d'accéder à une application, tel que décrit précédemment; et — un dispositif serveur comportant un module de gestion apte à gérer :
o un conteneur d'interface tel que décrit précédemment; et o au moins un conteneur d'une application accessible par le dispositif client, ladite application étant configurée pour générer des événements destinés à des périphériques de sortie du dispositif client via le conteneur d'interface.
Le dispositif serveur est ici une machine physique, par exemple un ordinateur. On utilise l'expression « dispositif serveur » pour le distinguer d'un serveur logiciel tel qu'un module de traitement compris dans un conteneur d'interface.
Dans un mode de réalisation de l'invention, le site web permettant l'accès au conteneur d'interface est hébergé dans le dispositif serveur du système selon l'invention.
Dans un mode de réalisation de l'invention, le dispositif serveur comporte un module d'authentification de l'utilisateur du dispositif client et un module configuré pour créer, autrement dit instancier, le conteneur d’interface, pour cet utilisateur, suite à une authentification de l’utilisateur.
Le dispositif serveur crée le conteneur d’interface à partir d’une image de référence compatible avec son système d’exploitation.
Le conteneur d'interface et le conteneur d'application peuvent être exécutés par des machines physiques distinctes.
Le conteneur d'interface et le conteneur d'application peuvent être tous les deux exécutés par le dispositif serveur, ou par une autre même machine physique, par exemple mise en œuvre dans un réseau cloud. Dans ce cas, la latence de communication entre les conteneurs d'interface et d'application est donc réduite.
Dans un mode de réalisation, l'authentification d'un utilisateur du dispositif client est régie par un protocole choisi parmi les protocoles oAuth, Kerberos (Active Directory) et LDAP.
Différents niveaux de sécurité d'utilisation de l'invention peuvent ainsi être envisagés.
L'invention vise également un programme d'ordinateur sur un support d'enregistrement, ce programme étant susceptible d'être mis en œuvre dans un dispositif selon l'invention, ou plus généralement dans un ordinateur, ce programme comportant des instructions adaptées à la gestion d'au moins une application telle que décrite ci-dessus.
Ce programme peut utiliser n'importe quel langage de programmation, et être sous la forme de code source, code objet, ou de code intermédiaire entre code source et code objet, tel que dans une forme partiellement compilée, ou dans n'importe quelle autre forme souhaitable.
L'invention vise aussi des supports d’information ou d'enregistrement lisibles par un ordinateur, et comportant des instructions du programme d’ordinateur tel que mentionné cidessus.
Les supports d'information ou d'enregistrement peuvent être n'importe quelle entité ou dispositif capable de stocker le programme. Par exemple, les supports peuvent comporter un moyen de stockage, tel qu'une ROM, par exemple un CD ROM ou une ROM de circuit microélectronique, ou encore un moyen d'enregistrement magnétique, par exemple une disquette (floppy dise), un disque dur ou une mémoire flash.
D'autre part, les supports d’information ou d'enregistrement peuvent être des supports transmissibles tels qu'un signal électrique ou optique, qui peut être acheminé via un câble électrique ou optique, par lien radio, par lien optique sans fil ou par d'autres moyens. Les programmes selon l'invention peuvent être en particulier téléchargés sur un réseau de type Internet.
Alternativement, chaque support d'informations ou d'enregistrement peut être un circuit intégré dans lequel le programme est incorporé, le circuit étant adapté pour exécuter ou pour être utilisé dans l'exécution de la méthode en question.
Brève description des dessins
D'autres caractéristiques et avantages de la présente invention ressortiront de la description faite ci-dessous, en référence aux dessins annexés qui en illustrent un exemple de réalisation dépourvu de tout caractère limitatif. Sur les figures :
— La figure 1 illustre une architecture d'un dispositif selon l'invention et d'un système selon l'invention selon un mode de réalisation;
— La figure 2 est un organigramme représentant des étapes d'un procédé conforme à un mode de réalisation de l'invention dans un contexte particulier de mise en œuvre;
— La figure 3 illustre l'architecture matérielle d'un dispositif selon un mode de réalisation de l'invention;
— La figure 4 présente l'architecture fonctionnelle d'un dispositif selon un mode de réalisation de l'invention; et — La figure 5 présente une architecture fonctionnelle d'un dispositif serveur compris dans un système selon un mode de réalisation de l'invention.
Description détaillée
La figure 1 présente l'architecture fonctionnelle d'un conteneur d'interface C_IF, d'un conteneur d'application C_APP, et l'architecture d'un dispositif DA et d'un système SA conformes à un mode de réalisation de l'invention, ce dispositif DA et ce système SA permettant à un dispositif client CLT d’accéder à une application APP distante.
On se place ici dans un contexte dans lequel les différents modules de traitement du conteneur d'interface ont été démarrés suite à l'authentification d'un utilisateur du dispositif client. Ces étapes sont décrites ultérieurement en référence à la figure 2.
Dans ce mode de réalisation, le dispositif client CLT est un ordinateur comportant des périphériques d'entrée, tels qu'une souris, un clavier KB et un microphone MICRO, et des périphériques de sortie tels qu'un écran DISP, une imprimante PRN et un haut-parleur SND.
Le dispositif client CLT communique avec un dispositif serveur SRV mis en œuvre dans un réseau en nuage selon le protocole HTTPS. En variante, il est notamment possible d'utiliser le protocole HTTP. D'autres protocoles sont envisageables.
En particulier, le dispositif client CLT consulte, via un navigateur web installé sur le dispositif client, un site web prédéfini accessible via le dispositif serveur SRV.
Le dispositif serveur SRV comporte un module de gestion de conteneurs MGC (figure 5). Suite à une demande du dispositif client CLT exprimée sur le site web, ce module instancie un conteneur d'interface C_IF. Dans ce mode de réalisation, le serveur SRV communique avec le conteneur d'interface C_IF en HTTPS.
Le conteneur d'interface C_IF est exécuté par le dispositif DA conforme à l'invention. Ce dispositif DA permet à l'utilisateur du dispositif client d'accéder, via son navigateur web et le serveur SRV, à une application APP s'exécutant dans un conteneur d'application C_APP.
Dans le mode de réalisation décrit, l'application APP s'exécute sur une machine physique MPhy.
Plus précisément, d'une façon générale et comme ultérieurement décrit en référence à la figure 2, dans ce mode de réalisation, plusieurs démons sont démarrés dans le conteneur d'interface C-IF, pour l'utilisateur suite à son authentification, chacun de ces démons étant configuré pour attendre des événements de différents types (affichage, son, impression, ...) susceptibles d'être générés par des applications s'exécutant dans des conteneurs d'application, et pour envoyer, sur réception de tels événements, des messages au dispositif client pour que les événements soient restitués par des périphériques de sortie.
Ce dispositif DA peut être mis en œuvre dans un réseau cloud.
Le dispositif DA peut être le dispositif serveur SRV lui-même.
Dans cet exemple, le conteneur d'interface C_IF comporte un module d'affichage MOD_disp qui comporte un serveur d'affichage s_disp apte à traiter des requêtes comportant des événements d'affichage ev_disp en provenance d'un client d'affichage c_disp de l'application APP. Dans l'exemple de réalisation décrit ici, ce serveur d'affichage s_disp est un démon démarré après l'authentification de l'utilisateur, en attente d'événements d'affichage destinés au dispositif client CLT.
On suppose que le conteneur d'application C_APP exécute l'application APP comportant un module graphique se présentant sous la forme d'un client d'affichage c_disp.
Le client d'affichage c-disp implémente la gestion des périphériques de base du dispositif client CLT, tels que l'écran DISP, la souris et le clavier KB
Dans ce mode de réalisation, le serveur d'affichage s_disp est un serveur X Windows System dont l'implémentation est X.org. Le serveur X utilise le module xf86-video-dummy pour créer un environnement graphique virtuel, dépourvu de carte d'écran physique.
Le serveur d'affichage s_disp implémenté sous la forme de X.org peut être démarré selon la commande :
X.org -nolisten tcp -dpi 96 +extension RANDR -logfile /home/balloon/.logs/X.org.log -config /composer/X.org.conf :0
Dans ce mode de réalisation, le serveur X Windows System utilise le protocole Xll et le conteneur d'interface C_IF communique selon le protocole HTTPS avec le dispositif serveur SRV.
Dans ce mode de réalisation, le module d'affichage MOD_disp déployé par le conteneur d'interface C_IF comporte, comme présenté sur la figure 1 :
le serveur d'affichage s_disp;
un module de conversion conv-disp configuré pour convertir des données reçues selon un premier protocole du client d'affichage c-disp, via le serveur d'affichage s-disp en des données destinées au dispositif client CLT et formatées selon un deuxième protocole et vice versa; et un module de communication comm_disp configuré pour communiquer avec le dispositif client CLT. Il est notamment configuré pour transmettre au navigateur web du dispositif client CLT des messages MSG_CLT générés par le serveur d'affichage s_disp
Dans le mode de réalisation décrit, le module de conversion conv-disp exécute le logiciel xllvnc pour convertir des données selon le protocole Xll en des données en protocole RFB (Remote Frame Buffer) et vice versa, RFB étant le protocole utilisé pour un serveur VNC (Virtual Network Computing)(non représenté sur la figure 2) ; par défaut un serveur VNC envoie/reçoit des sockets de type TCP.
Dans le mode de réalisation décrit, le module de communication comm_disp exécute une application Websockify qui permet de convertir des sockets de type TCP en des websockets supportées par le protocole HTTPS et interprétables par le navigateur web HTML5 du dispositif client CLT.
Dans ce mode de réalisation, le module de conversion conv-disp exécute la version 0.9.14 du processus xllvnc.
Dans ce mode de réalisation, le module de communication comm-disp exécute la version 1.0 du processus websokify.
Dans ce mode de réalisation, le serveur d'affichage s_disp, le module de conversion conv_disp et le module de communication comm_disp sont des démons compris dans le conteneur d'interface C-IF et exécutés par le dispositif DA. Le module d'affichage MOD_disp comporte ces trois démons s_disp, comv_disp et comm_disp permettant la gestion des événements d'affichage.
Pour réduire la surface d'attaque et optimiser la charge du réseau, le serveur s_disp communique avec le client c_disp déployé par le conteneur d'application C_APP par des sockets ; les communications internes au module d'affichage MOD_disp sont aussi régies par des sockets ; le module de communication comm_disp est le seul à exporter ses services à l'extérieur du module MOD_Disp.
Dans ce mode de réalisation, ce module comm_disp communique en RFB avec le dispositif serveur SRV via le portTCP/IP 6081.
Dans ce mode de réalisation, la ligne de commande permettant le lancement de l'exécution du logiciel xllvnc du conteneur d'interface C_IF est : xllvnc -display :0 -xkb -noxinerama -shared -xrandr -nolookup -nopw -forever -unixsockonly /tmp/.unixxllvnc
Dans ce mode de réalisation, la ligne de commande permettant l'exécution de websockify au démarrage du conteneur d'interface C_IF est : python /composer/noVNC/utils/websockify/websockify.py -unix-target /tmp/.unixxllvnc 6081
Le navigateur web du dispositif client CLT est configuré pour recevoir des messages MSG-CLT transmis par le module comm_disp. Ces messages sont par exemple transmis via une librairie javascript VNC « no-vnc » du navigateur. La librairie no-vnc se charge de la réception des messages MSG_CLT relatifs à l'affichage sur l'écran DISP du dispositif client, et de la transmission au serveur SRV, d'événements ev_lect émis par le clavier KB ou par la souris du dispositif client CLT.
Dans ce mode de réalisation, le module graphique c_disp du conteneur d'application C_APP comporte un client c_disp de type application Xll. Ce client de type application Xll communique par des sockets avec le serveur X.org tel que décrit précédemment.
Le client de type application Xll communique avec le serveur d'affichage X.org soit par des sockets de type fichier présents dans un volume temporaire partagé entre le conteneur d'interface C_IF et le conteneur d'application C_APP, par exemple un volume tmp, soit par des sockets de type réseau TCP/IP. Les communications entre le serveur s_disp et le client d'affichage c_disp sont plus sécurisées dans le cas où les sockets sont de type fichier.
Conformément au procédé d'accès selon l'invention décrit ultérieurement en référence à la figure 2, le conteneur d'interface C_IF, et plus précisément son module s_disp, obtient les événements d'affichage ev_disp générés par l'application déployée par le conteneur C_APP et envoyées par le module c_disp du conteneur C_APP. Chacun de ces événements ev_disp est destiné au périphérique d'affichage DISP du dispositif client CLT.
L'événement peut être transmis sous forme de socket par le conteneur d'application C_APP. En effet, dans ce mode de réalisation, le conteneur d’interface comporte un volume partagé, nommé tmp. Dans ce volume partagé, le client d'affichage c_disp crée une socket de type fichier nommé X0 dans un répertoire /tmp/.Xll-unix dans le volume partagé tmp. Le serveur d'affichage s_disp détecte la présence de la socket fichier XO dans le répertoire /tmp/.Xll-unix , récupère la socket et obtient l'événement ev_disp.
Suite à l'obtention de l'événement ev_disp, le conteneur d'interface C_IF, et plus précisément son module comm_disp, génère un message MSG_CLT obtenu à partir de l'événement ev_disp et interprétable par le dispositif client CLT et envoie ce message MSG_CLT à destination du dispositif client CLT en passant par le dispositif serveur SRV.
En addition, le conteneur d'interface C_IF peut recevoir des événements, générés par des périphériques d'entrée du dispositif client CLT.
Par exemple, le module comm_disp obtient, via le dispositif serveur SRV, un événement evject présentant un flux de données entrées par le clavier KB.
Suite à la réception de cet événement evject généré par un périphérique d'entrée, le module de communication comm_disp le transmet au module de traitement s_disp via le module de conversion conv_disp. Le module de conversion assure la conformité des communications entre le module de communication comm_disp et le module de traitement s_disp, en convertissant, au besoin, le format de ces communications.
Le module s_disp génère au moins un message MSG_APP obtenu à partir de l'événement evject et interprétable par l'application APP déployée par le conteneur C_APP. Le module s_disp du conteneur d'interface C_IF envoie le message MSG_APP au module ç_disp du conteneur d'application C_APP.
L'utilisateur peut bénéficier d'un écran virtuel du conteneur d'interface C_IF affiché sur le navigateur web de son dispositif client CLT.
Dans l'exemple de la figure 1, le conteneur d'interface C_IF déploie un module s_dim configuré pour adapter un message MSG_CLT à transmettre au dispositif client CLT en fonction d'un paramètre d'affichage de l'écran DISP du dispositif client CLT obtenu à partir d'un événement d'affichage ev_disp transmis par le dispositif client CLT
Ce paramètre d'affichage peut être une valeur de résolution graphique de l'écran DISP, la taille de la fenêtre du navigateur web du dispositif client CLT, la taille de l'écran DISP ou tout autre paramètre lié à l'affichage sur l'écran DISP du dispositif client CLT.
Dans ce mode de réalisation, le module s_dim exécute un logiciel assurant un service de type RPC.
Le module s-dim permet l'utilisation de dispositifs clients CLT de différents types : smartphone, tablette, ordinateur, MAC, etc. L'écran virtuel du conteneur d'interface C_IF affiché sur le navigateur web du dispositif client CLT est redimensionné dynamiquement.
A la première connexion du dispositif client CLT au site web accessible via le serveur SRV, ainsi à chaque modification d'un paramètre d'affichage, par exemple lors d'un redimensionnement de la fenêtre du navigateur web du dispositif client CLT, le navigateur web notifie le conteneur d'interface C_IF de sa nouvelle résolution : le module s_dim obtient, de la part du dispositif client CLT, via le serveur SRV, un événement ev_dim relatif à la résolution graphique.
Suite à l'obtention de l'évènement ev_dim, le module s_dim notifie le module d'affichage MOD_disp du conteneur d'interface C_IF, et plus précisément son module s_disp, des nouvelles résolutions graphiques à appliquer. A son tour, le module de traitement s_disp communique les nouvelles résolutions graphiques au module graphique c_disp.
Dans ce mode de réalisation, le module s_dim déploie un service RPC, nommé dans la suite du document « Spawner » et développé en nodejs (spawner-service.js).
Dans ce mode de réalisation, le module s_dim configuré pour adapter un message MSG_CLT relatif à l'affichage à un paramètre d'affichage de l'écran DISP, écoute sur le port TCP 8001, communique en HTTPS avec le dispositif serveur SRV et communique par des sockets avec le serveur d’affichage s_disp.
Dans ce mode de réalisation, la ligne de commande permettant l'exécution spawnerservice.js au démarrage du conteneur d'interface C_IF est : nodejs /composer/node/spawner-service/spawner-service.js
Le module s_dim configuré pour adapter le message MSG_CLT obtenu à partir de l'événement d'affichage ev_disp à un paramètre d'affichage de l'écran DISP, peut contrôler l'exécution de l'application déployée par le conteneur Ç_APP.
En effet, le module s_dim, à travers le service Spawner, est capable d'activer le focus sur une application, de terminer une application et de lister les applications présentes sur le bureau virtuel du conteneur d'interface C_IF.
Dans le mode de réalisation présenté à la figure 1, le conteneur d'interface C_IF déploie un module MOD_snd pour gérer des applications qui requièrent des interfaces sonores.
Le module MOD_snd comporte :
un module de traitement s_snd configuré pour obtenir au moins un événement de type son ev_snd généré par l'application APP déployée dans le conteneur C_APP et destiné à un périphérique de sortie de son SND du dispositif client CLT, tel que les hauts parleurs SND ; et un module de communication comm_snd configuré pour générer et envoyer au moins un message MSG_CLT obtenu à partir de l'événement ev_snd et destiné à et interprétable par le dispositif client CLT.
Dans ce mode de réalisation, le serveur s_snd et le module de communication comm_snd sont des démons compris dans le conteneur d’interface C_IF et exécutés par le dispositif DA. Le module de son MOD_snd comporte les démons s_snd et comm_snd.
Dans l'exemple décrit ici, on suppose que l'application APP s'exécutant dans le conteneur d'application C_APP comporte un client c_snd du serveur de son s_snd.
Dans le mode de réalisation présenté à la figure 1, le serveur de son s_snd est par exemple de type Pulseaudio (logiciel libre du projet freedesktop, version : PulseAudio Sound Server 8.0).
Afin d'assurer la communication selon le protocole HTTPS entre le conteneur C_IF et le serveur SRV, le module de communication comm_snd exécute un processus de type Live Sound Service.
Le processus Live Sound Service est développé en nodejs.
Le module de communication comm_snd capture le son issu du module s_snd et le transforme en un message MSG_CLT comportant un flux sonore supporté par le navigateur web du dispositif client, par exemple un flux de type WAV ou MP3.
Le module de communication comm_snd envoie le message MSG_CLT aux hautparleurs SND du dispositif client CLT via le dispositif serveur SRV, selon le protocole HTTPS. Le flux sonore contenu dans le message MSG_CLT peut être détecté par le navigateur web du dispositif client CLT, par une simple balise HTML de type audio. Le message MSG_CLT est restitué par les haut-parleurs SND.
De la même façon, le processus Live Sound Service exécuté par le module de communication comm_snd peut convertir un fichier ou un flux sonore ev_micro capté par le microphone MICRO du dispositif client CLT via le dispositif serveur SRV selon le protocole HTTPS en un flux sonore régi par un protocole supporté par le serveur s_snd de type Pulseaudio. Le serveur s_snd génère alors un message MSG_APP obtenu à partir de l'événement ev_micro et interprétable par l'application APP. Le conteneur d'interface C_IF envoie le message MSG_APP au conteneur d'application C_APP pour qu'il soit restitué par la machine physique MPhy.
Dans ce mode de réalisation, la ligne de commande permettant le démarrage de Pulseaudio au démarrage du conteneur d'interface C_IF est :
/usr/bin/pulseaudio
Dans ce mode de réalisation, la ligne de commande permettant le démarrage de Live Sound Service au démarrage du conteneur d'interface C_IF est : nodejs /composer/node/livesound-service/livesound-service.js
Dans ce mode de réalisation, le processus Live Sound Service exporte le port TCP/IP 8000 pour communiquer en HTTPS avec le serveur SRV.
Les communications du serveur de son s_snd avec le module de communication comm_snd et/ou avec le client de son c_snd peuvent être régies par des sockets pour assurer la sécurité de ces communications.
Dans ce mode de réalisation, le serveur (ou démon) pulseaudio crée une socket de type fichier nommé .pulse.sock dans le volume partagé tmp et le démon Live Sound Service détecte la présence de la socket et la récupère.
Dans le mode de réalisation présenté à la figure 1, pour gérer des applications nécessitant un service d'impression, le conteneur d'interface C_IF déploie un module MOD_prn qui comporte :
un module de traitement s_prn configuré pour l'obtention d'un événement d'impression ev_prn généré par l'application APP déployée dans le conteneur C_APP et destiné à une imprimante PRN connectée au dispositif client CLT; et un module de communication comm_prn configuré pour générer et envoyer au moins un message MSG_CLT obtenu à partir de l'événement ev_prn, destiné à et interprétable par le dispositif client CLT.
Dans ce mode de réalisation, le serveur s_prn est un serveur d'impression. En particulier, le serveur d'impression s-prn peut être basé sur la technologie Common Unix Printing System (CUPS, marque déposée par Apple, version : 1.3-4) qui permet de générer des fichiers au format PDF.
Dans ce mode de réalisation, le conteneur d'application C_APP déploie un client d'impression c_prn du serveur d'impression s_prn. Le client c_prn et le serveur s_prn d'impression communiquent par des sockets fichiers partagées dans le volume temporaire tmp.
Le client d'impression c_prn se connecte sur une socket fichier nommée « .cups.sock » et placée dans le répertoire /tmp. Le client d'impression place des données relatives à un événement d'impression ev_prn dans la socket .cups.sock.
Le serveur d'impression s_prn détecte la présence des données à la socket .cups.sock placée dans le volume partagé tmp et reçoit ainsi l'événement d'impression ev_prn.
Suite à la réception de l'événement d'impression ev_prn, le serveur s_prn génère un fichier contenant les données à imprimer reçues du client c_prn. Puis, le serveur s_prn place le fichier généré dans un répertoire, nommé «.printer-queue », contenant une liste de fichiers en attente d'impression.
Le serveur s_prn est par exemple de type CUPS et les fichiers générés sont par exemple au format PDF.
D'autres formats de fichiers peut être générés, par exemple des fichiers de type .jpeg
Le module de communication comm_prn est configuré pour détecter la présence d'un nouveau document dans le répertoire «.printer-queue ».
Par exemple, le module de communication comm_prn est configuré pour assurer un service de type Printer-service. Ce service Printer-service, développé en nodejs (printer-service.js), comporte une fonctionnalité « watcher » de détection des modifications au niveau de la file d'attente du répertoire « .printer-queue ».
En détectant le placement, par le serveur d'impression s_prn, du nouveau fichier dans le répertoire « .printer-queue », le module de communication reçoit l'événement d'impression ev_prn.
Suite à la détection de la présence du nouveau document dans le répertoire « .printerqueue », le module de communication comm_prn génère un message d'impression MSG_CLT à partir de l'événement ev_prn. Le message MSG_CLT est destiné au dispositif client CLT.
Dans ce mode de réalisation, le service printer-service.js n'est pas exporté, autrement dit il ne communique pas en HTTPS avec le dispositif serveur SRV, mais communique directement avec un module MOD_user du conteneur d'interface C_IF. Le module de communication comm_prn envoie le message d'impression MSG_CLT au module MOD_user et c'est ce module MOD_user qui transfère le message d'impression MSG_CLT au dispositif serveur SRV pour qu'il le transfère, à son tour, au dispositif client CLT.
Le module MOD_user, décrit ultérieurement, est configuré pour exécuter un service de partage de sessions, de type « Broadcast Session Service » développé en nodejs (broadcastservice.js).
Dans ce mode de réalisation, le module de communication comm_prn n'est pas exporté et communique avec le serveur SRV via le module MOD_user pour réduire le nombre de sockets ouvertes. Une même socket est utilisée pour le service de partage de sessions et aussi pour le service d'impression.
Dans un autre mode de réalisation, le module de communication comm_prn est exporté et indépendant du module MOD_user.
Dans ce mode de réalisation, lorsque le navigateur web du dispositif client CLT est notifié de la présence d'un nouveau fichier à imprimer, il le télécharge via le service File Service développé en nodejs (file-service.js) et exécuté par le conteneur d'interface C_IF. Une fenêtre de type popup s'affiche alors dans le navigateur web du dispositif client CLT pour notifier l'utilisateur de la présence du nouveau fichier afin de lancer l'impression sur l'imprimante PRN du dispositif client CLT.
Le mode de réalisation basé sur la génération de fichiers PDF offre une comptabilité avec plusieurs natures de dispositifs clients. En effet, le module d'impression MOD_prn est totalement indépendant du pilote (driver) d'impression du dispositif client CLT et de son contexte d'impression.
Lorsque le dispositif client CLT télécharge le fichier PDF à imprimer, il exécute son propre pilote d'impression pour déclencher l'impression sur son imprimante PRN. Le pilote d'impression peut être, à titre d'exemples, Google Cloud Print pour un dispositif client CLT de type smartphone utilisant le système d'exploitation Android (marque déposée par Google), ou AirPrint pour un dispositif client CLT de type smartphone utilisant le système d'exploitation iOS (marque déposée par Apple).
Dans ce mode de réalisation, le service Broadcast Service déployé par le conteneur d'interface C_IF écoute sur le port TCP 8003.
Dans ce mode de réalisation, le service File Service déployé par le conteneur d'interface C_IF écoute sur le port TCP 8080.
Dans ce mode de réalisation, la ligne de commande permettant le démarrage du serveur de type CUPS au démarrage du conteneur d'interface C_IF est :
/usr/sbin/cupsd -c /etc/cups/cupsd.conf-f
Dans ce mode de réalisation, la ligne de commande permettant l'exécution broadcastservice.js au démarrage du conteneur d'interface C_IF est : nodejs /composer/node/broadcast-service/broadcast-service.js
Dans ce mode de réalisation, la ligne de commande permettant l'exécution fileservice.js au démarrage du conteneur d'interface C_IF est : nodejs /composer/node/file-service/file-service.js
Dans ce mode de réalisation, le module d'impression MOD_prn est tout simplement un ensemble logique des modules s_prn et comm_prn relatifs à la gestion des événements d'impression. Le module MOD_prn ne présente pas une couche logicielle supplémentaire, en dessus du serveur s_prn et du module de communication comm_prn.
Dans le mode de réalisation présenté à la figure 1, un même module de traitement du conteneur d'interface C_IF peut être démarré pour plusieurs utilisateurs, qui partagent alors une même session.
Chacun de ces utilisateurs se connecte par son dispositif client CLT, via le dispositif serveur SRV, au même conteneur d'interface C_IF.
Un module MOD_user du conteneur d'interface C_IF est configuré pour assurer la notification du partage de session entre les utilisateurs. Il compte le nombre d'utilisateurs connectés à un même conteneur d'interface et gère les échanges avec chaque disposirif client de ces utilisateurs.
Le module MOD_user est par exemple un serveur de type Broadcast Session Service.
Selon le besoin du fonctionnement d'une application APP, son conteneur d'application Ç_APP déploie un ou plusieurs clients des serveurs déployés par le conteneur d'interface C_IF.
Par exemple, le conteneur d'application C_APP présenté à la figure 1 déploie un client d'affichage c_disp pour générer des événements d'affichage ev_disp et/ou traiter des événements clavier-souris evject, un client de son c_snd pour la génération des événements sonores ev_snd et/ou le traitement des événements sonores ev_micro et un client d'impression c_prn pour générer des événements d'impression ev_prn.
A titre d'alternative, le conteneur d'application C_APP déploie un seul client, par exemple un client d'affichage c_disp.
Les conteneurs de différentes applications sont étanches les uns aux autres et ne communiquent qu'avec le conteneur d'interface C_IF pour assurer une meilleure sécurité. Chaque conteneur d’application C_APP a sa propre adresse, sa propre capacité de calcul CPU, sa propre mémoire et son propre espace de nommage.
Dans le mode de réalisation présenté à la figure 1, le conteneur d'interface C_IF déploie un module de transfert MOD_f configuré pour assurer un service de transfert de fichiers du dispositif client CLT à un espace de stockage Str situé dans un réseau en nuage.
Aucun conteneur d'application C_APP n'est requis pour assurer ce service de transfert de fichiers.
Plusieurs protocoles de communication entre le module de transfert MOD_f du conteneur d'interface C_IF et l'espace de stockage Str peuvent être envisagés, tels que par exemple NFS (Network File System, dévoloppé par Sun Microsystems), S3 (Simple Storage Service, développé par Amazon), Dropbox (marque déposée), etc.
Dans un autre mode de réalisation, l'espace de stockage Str peut être compris dans le dispositif DA conforme à l'invention, exécutant le conteneur d'interface C_IF.
Dans ce mode de réalisation, le module de transfert MOD_f est configuré exposer les fonctions de téléchargement de fichiers entre le navigateur web du dispositif client CLT et l'espace de stockage Str dans le réseau cloud. Ces fonctions de téléchargement sont par exemple une fonction de téléchargement en mode download (de l'espace de stockage vers le navigateur) et une fonction de téléchargement en mode upload (du navigateur vers l'espace de stockage)
Le module de transfert MOD_f comporte par exemple un serveur de type File Manager Service.
Dans un mode de réalisation, un déplacement de type « drag and drop » d'un fichier local du dispositif client CLT dans la fenêtre du navigateur web peut mener à un transfert de ce fichier dans l'espace de stockage Str.
Le serveur File Manager Service peut écouter sur le port TCP 5000 pour ces communications avec le dispositif serveur SRV.
Dans ce mode de réalisation, une fenêtre HTML affichée dans le navigateur web présente l'arborescence de l'espace de stockage Str contenant les documents de l'utilisateur transférés par le module MOD_f.
Dans ce mode de réalisation, la ligne de commande permettant l'exécution de File Manager Service au démarrage du conteneur d'interface C_IF est : nodejs /composer/node/angular-filemanager-nodejs-bridge/server.js
La figure 2 présente différentes étapes du procédé selon l'invention, permettant d'accéder à l'application APP, dans un exemple de mise en œuvre. Sur cette figure, on a représenté différentes étapes mises en œuvre dans cet exemple par le dispositif client CLT, le dispositif serveur SRV, le dispositif DA conforme à l'invention et la machine physique MPhy.
Au cours d'une étape C100, un utilisateur disposant d'un dispositif client CLT accède à un site web prédéfini via un navigateur web du dispositif client CLT, par exemple de type HTML5, au moyen d'une URL (pour « unified Ressource Locator » en anglais) prédéfinie. Ce site web est accessible via le dispositif serveur SRV. En particulier, le site web peut être hébergé sur le dispositif serveur SRV.
Le site web affiche une interface d'authentification, par exemple une interface où l'utilisateur doit renseigner son nom d'utilisateur et son mot de passe.
Au cours d'une étape C101, l'utilisateur s'authentifie, en envoyant par exemple son identifiant et son mot de passe au serveur SRV. Le serveur SRV les reçoit au cours d'une étape
S102 et vérifie, au cours d'une étape S103, si l'authentification est correcte ou non. L'authentification peut être définie selon le protocole oAuth, ou Kerberos (Active Directory), ou LDAP, ou autre protocole d'authentification. Les étapes C101, S102 et S103 se répètent jusqu'à ce que l'authentification soit réussie.
Suite à une authentification réussie, et conformément à l'invention, un conteneur d'interface C_IF est instancié (étape S104) pour l'utilisateur authentifié à partir d'une image de conteneur d'interface compatible avec le système d'exploitation du serveur SRV.
Ce conteneur d'interface C_IF est ainsi dédié au dispositif client CLT.
Le dispositif serveur SRV crée le conteneur d’interface C_IF à partir d’une image de référence compatible avec le système d’exploitation du dispositif serveur SRV, par exemple une image sous Debian, Ubuntu, ou Centos (marques déposées). Cette image de distribution est un fichier compilé comportant le code et les librairies requises par les fonctionnalités assurées par le conteneur d’interface C_IF.
Dans ce mode de réalisation, ce conteneur d'interface C_IF est exécuté dans le dispositif DA mis en œuvre dans un réseau en nuage (cloud) et communique avec le dispositif serveur SRV selon le protocole HTTPS.
Le dispositif DA démarre le conteneur d'interface C_IF au cours d'une étape D105.
Dans le mode de réalisation décrit ici, le conteneur d'interface Ç_IF déploie un démon s_disp offrant un service de serveur d'affichage et des démons s_snd, et s_prn pour le son et l'impression.
Au cours de cette étape S104 de création du conteneur C_IF, le dispositif serveur SRV démarre les serveurs s_disp, s_snd, s_prn susceptibles d’obtenir des événements ev_disp, ev_snd, ev_prn destinés à un périphérique de sortie DISP, PRN, SND du dispositif client CLT et générés par une application APP s'exécutant dans un conteneur d'application C_APP.
Pour chaque type d’événement attendu, le dispositif DA démarre un ou plusieurs démons déployés dans le conteneur d’interface C_IF. Par exemple, pour gérer des événements de type affichage, un serveur d’affichage s_disp, un module de conversion conv_disp, et un module de communication comm_disp tels que décrits à la figure 1 sont démarrés.
A l'issue de l'étape S104 de création du conteneur d'interface C_IF et de démarrage de ses serveurs, un bureau virtuel s'affiche dans le navigateur du dispositif client.
Dans un mode de réalisation, au cours de l'étape S104 de création du conteneur d'interface C_IF, le serveur SRV crée deux volumes de données sur le dispositif DA :
— un volume temporaire, nommé par exemple tmp, utilisé pour stocker des fichiers temporaires, par exemple des sockets de type fichier venants de ou destinés à un conteneur d'application C_APP, ce volume est partagé par le conteneur d'interface C_IF et le conteneur d'application C_APP ; et — un volume dit « home », utilisé pour stocker des données de l'utilisateur, par exemple des fichiers bureautiques ou des images, ce volume est partagé par le conteneur d'interface C_IF et le serveur SRV.
On suppose que l'utilisateur souhaite accéder à une application APP s'exécutant dans un conteneur d'application C_APP.
Au cours d'une étape S106, le serveur SRV commande l'établissement d'une connexion entre le conteneur d’interface C_IF et ce conteneur d'application Ç_APP.
Le conteneur d'application C_APP peut s'exécuter dans le serveur SRV, dans le dispositif DA qui exécute le conteneur d'interface C_IF, ou dans une autre machine physique MPhy.
Dans ce mode de réalisation, une machine physique MPhy héberge le conteneur d'application C_APP.
Au cours de l'étape S106, le serveur SRV envoie au dispositif DA et à la machine MPhy des informations leur permettant d'établir une connexion entre le conteneur d'interface C_IF et le conteneur d'application C_APP. La réception de ces informations est acquittée par le dispositif DA et la machine physique MPhy au cours d'une étape D108 et d'une étape M108 respectivement.
Les informations permettant d'établir la connexion entre les conteneurs C_IF et C_APP sont des sockets fichiers relatives à des démons déployés par le conteneur d'interface C_IF et des variables d'environnement.
Les variables d'environnement présentent par exemple des informations sur l'utilisateur authentifié obtenues au cours de l'étape C101, ce qui permet par la suite d'afficher par exemple un message d'accueil personnalisé, portant le nom de l'utilisateur, quand il accède à l'application APP.
Au cours de l'étape D108 relative à l'établissement de connexion entre le conteneur d'interface C_IF et le conteneur d'application C_APP, le conteneur d'interface C_IF place des sockets fichiers dans le répertoire /tmp pour indiquer au conteneur d'application C_APP quels sont les identifiants des modules serveurs s_disp, s_prn, s_snd du conteneur C_IF avec lesquels le conteneur d'application C_APP peut communiquer.
Les sockets fichiers partagés par le conteneur d'interface pour établir une connexion avec un conteneur d'application sont identiques pour tout conteneur d'application.
Au cours d'une étape Ml 10 du procédé, la machine MPhy exécutant le conteneur d'application C_APP envoie un événement généré par l'application APP et destiné à un périphérique de sortie du dispositif client CLT. L'envoi peut être sous forme d'un placement d'une socket fichier représentant l'événement dans le répertoire partagé tmp par le conteneur d'application C_APP. La socket peut être un fichier X0 ou .pulse.sock ou .cups.sock décrits précédemment.
Au cours d'une étape D120, le conteneur d'interface obtient l'événement destiné au périphérique de sortie, en récupérant par exemple la socket du répertoire tmp.
Au cours d'une étape D130, le conteneur d'interface C_IF obtient un message MSG_CLT à partir de l'événement obtenu au cours de l'étape D120, et l'envoie au dispositif client
CLT via le dispositif serveur SRV. Le message MSG_CLT est destiné à et interprétable par le dispositif client CLT.
Dans le mode de réalisation décrit ici, le dispositif DA a l'architecture d'un ordinateur, telle qu'illustrée à la figure 3. Elle comprend notamment un processeur 7, une mémoire vive 8, une mémoire morte 9, une mémoire flash non volatile 10 dans un mode particulier de réalisation de l'invention, ainsi que des moyens de communication 11. De tels moyens sont connus en soi et ne sont pas décrits plus en détail ici.
La mémoire morte 9 du dispositif DA permettant d'accéder à une application, selon la présente invention constitue un support d'enregistrement conforme à l'invention, lisible par le processeur 7 et sur lequel est enregistré ici un programme d'ordinateur Prog conforme à l'invention. La mémoire 10 du dispositif DA permettant d'accéder à une application permet d'enregistrer des variables utilisées pour l'exécution des étapes de l'invention, telles que le nombre de sessions ouvertes sur un conteneur d'interface, le nombre de conteneurs d'applications connectée au conteneur d'interface ou les identifiants d'un dispositif client.
Le programme d'ordinateur Prog définit des modules fonctionnels et logiciels ici, configurés pour permettre à un dispositif client CLT d’accéder à une application APP. Ces modules fonctionnels s'appuient sur et/ou commandent les éléments matériels 7-11 du dispositif hébergeant un conteneur d'interface cités précédemment.
La figure 4 présente une architecture fonctionnelle du dispositif DA permettant d'accéder à une application selon un mode de réalisation. Le dispositif DA comporte un serveur s_out configuré pour obtenir un événement ev_disp, ev_snd, ev_prn généré par une application et un module de communication comm_out configuré pour générer au moins un message MSG_CLT obtenu à partir de l'événement ev_disp, ev_snd, ev_prn, destiné à et interprétable par le dispositif client CLT.
Dans un mode de réalisation, le serveur s_out peut être un des modules serveurs s_disp, s_snd ou s_prn décrits précédemment et présentés à la figure 1. Le module de communication comm_out peut être l'un des modules comm_disp, comm _snd, comm_prn décrits précédemment.
Le dispositif DA permettant d'accéder à une application comporte aussi un module de communication commjn configuré pour obtenir un événement evject, ev_micro généré par un périphérique d'entrée du dispositif client CLT, et un serveur sjn configuré pour générer et envoyer à l'application déployée dans le conteneur d'application au moins un message MSG_APP obtenu à partir de l'événement evject, ev_micro et interprétable par l'application déployée par le conteneur d'application C_APP.
Dans un mode de réalisation, le serveur s_out est le serveur sjn lui-même.
Dans un mode de réalisation, le module de communication comm_out est le module de communication commjn lui-même.
Dans un mode de réalisation, le serveur s_in peut être un des modules serveurs s_disp ou s_snd décrits précédemment et présentés à la figure 1. Le module de communication commjn peut être l'un des modules comm_disp ou comm _snd décrits précédemment.
La figure 5 présente une architecture fonctionnelle d'un dispositif serveur SRV pouvant être utilisé dans un mode de réalisation de l'invention. Le serveur SRV comporte un module AUTH d'authentification d'un utilisateur d'un dispositif client CLT et un module MGC de gestion de conteneurs. Ce module MGC comporte un module CR_C_IF de création d'un conteneur d'interface, un module CR_C_APP de création d'un conteneur d'application, un module ENR d'enrichissement d'un conteneur d'application par des données et un module CX de commande d'établissement d'une connexion entre le conteneur d'interface C_IF et le conteneur d'application C_APP.
La création d’un conteneur d’application C_APP peut se traduire par un démarrage de ce conteneur C_APP pour un utilisateur, autrement dit par un lancement d’exécution de ce conteneur C_APP.
Dans un mode de réalisation, les fonctionnalités assurées par le dispositif serveur SRV sont des processus déployés dans un conteneur, autres que le conteneur d’interface C_IF ou le conteneur d’application C_APP, et exécutés par le dispositif serveur SRV.
Pour le déploiement, autrement dit l'installation, d'une application APP dans un conteneur d'application C_APP, le serveur SRV crée un conteneur depuis une image de distribution de référence compatible avec son propre système d'exploitation, par exemple une image sous Debian, Ubuntu, ou Centos (marques déposées), puis installe l'application APP dans ce conteneur C_APP.
Dans un mode de réalisation, l'image de l'application APP est enrichie de métadonnées, telles que :
icon: nom du fichier icône représentant l'application APP ;
icondata: contenu du fichier icône encodé ;
keyword: mots clef de l'application APP utilisés pour la recherche ;
cat: catégorie de l'application APP ;
launch: nom de la classe Xll Windows Class ;
template: modèle utilisé lors de la création du conteneur C_APP ;
name: nom de l'application APP ;
- displayname : nom de l'application APP affiché par une interface graphique ;
type : chaîne de caractères précisant le type du conteneur (« app » pour un conteneur d'application) ;
mimetype : Type de format de données (mime) supporté par l'application ;
fileextensions : extension de fichiers pouvant être supportés par l'application ; et legacyfileextensions : extension native des fichiers.
Dans un mode de réalisation, une application au format GNU/Linux Xll est supportée nativement par un conteneur d'application, alors qu'une application au format Microsoft Windows 5 est supportée via un émulateur Wine.
Dans un mode de réalisation, le conteneur d’interface C_IF et/ou le conteneur d’application C_APP sont développés par le logiciel Docker (marque déposée par Docker, version 18.02.0 datée du 08 février 2018) ou par le logiciel LXC (Linux Containers, marque déposée par Linux, version 2.1.1 datée du 19 octobre 2017).

Claims (15)

  1. REVENDICATIONS
    1. Procédé permettant à un dispositif client (CLT) d'accéder à une application (APP), ledit procédé étant mis en œuvre dans un conteneur (C_IF), dit « conteneur d'interface », le procédé comportant les étapes suivantes :
    — démarrage (D105) d'un module de traitement (s_disp, s_snd, s_prn) susceptible d'obtenir au moins un événement (ev_disp, ev_snd, ev_prn) destiné à un périphérique de sortie (DISP, PRN, SND_out) dudit dispositif client (CLT) et généré par une application (APP) s'exécutant dans un conteneur d'application (C_APP) ; et — sur obtention (D120) d'un dit événement (ev_disp, ev_snd, ev_prn), envoi (D130) d'au moins un message (MSG_CLT) obtenu à partir dudit événement (ev_disp, ev_snd, ev_prn), destiné à et interprétable par ledit dispositif client (CLT).
  2. 2. Procédé selon la revendication 1, dans lequel la dite application (APP) est accessible (Cl 12) via un navigateur web du dispositif client (CLT).
  3. 3. Dispositif (DA) permettant à un dispositif client (CLT) d'accéder à une application (APP), ledit dispositif (DA) exécutant un conteneur, dit conteneur d'interface (C_IF) et comportant :
    — un module de traitement (s_disp, s_snd, s_prn) configuré pour obtenir un événement (ev_disp, ev_snd, ev_prn) destiné à un périphérique de sortie (DISP, PRN, SND_out) dudit dispositif client (CLT) et généré par une application (APP) s'exécutant dans un conteneur d'application (C_APP); et — un module de communication (comm_disp, comm _snd, comm _prn) configuré pour générer et envoyer, sur obtention d'un dit événement (ev_disp, ev_snd, ev_prn), au moins un message (MSGJ2LT) obtenu à partir dudit événement, destiné à et interprétable par ledit dispositif client (CLT).
  4. 4. Dispositif (DA) permettant à un dispositif client (CLT) d'accéder à une application (APP) selon la revendication 3 comportant :
    — un module de communication (comm_disp, comm_snd) configuré pour obtenir un événement (evject, ev_micro) généré par un périphérique d'entrée (KB, MICRO) dudit dispositif client (CLT); et — un module de traitement (s_disp, s_snd) configuré pour générer et envoyer, sur obtention d'un dit événement (evject, ev_micro) généré par un dit périphérique d'entrée (KB, MICRO), au moins un message (MSG_APP) obtenu à partir dudit événement (evject, ev_micro), destiné pour et pouvant être traité par une application (APP) s'exécutant dans un conteneur d'application (C_APP).
  5. 5. Dispositif (DA) permettant à un dispositif client (CLT) d'accéder à une application (APP) selon la revendication 3 ou 4, dans lequel des communications internes audit dispositif (DA) sont régies par des sockets de type fichier.
  6. 6. Dispositif (DA) permettant à un dispositif client (CLT) d'accéder à une application (APP) selon l’une quelconque des revendications 3 à 5, dans lequel un dit module de traitement est un serveur d'affichage (s_disp) configuré pour obtenir au moins un événement d'affichage (ev_disp) généré par ladite application (APP) et destiné à un écran (DISP) dudit dispositif client (CLT).
  7. 7. Dispositif (DA) permettant à un dispositif client (CLT) d'accéder à une application (APP) selon la revendication 6, dans lequel ledit dispositif (DA) comporte en outre un module (s_dim) configuré pour adapter ledit message (MSG_CLT) obtenu à partir de l'événement d'affichage (ev_disp) et destiné à l'écran (DISP) du dispositif client à un ' paramètre d'affichage dudit écran.
  8. 8. Dispositif (DA) permettant à un dispositif client (CLT) d'accéder à une application (APP) selon la revendication 7, dans lequel ledit module (s_dim) configuré pour adapter ledit message obtenu à partir de l'événement d'affichage (ev_disp) contrôle l'exécution de ladite application (APP).
  9. 9. Dispositif (DA) permettant à un dispositif client (CLT) d'accéder à une application (APP) selon l’une quelconque des revendications 3 à 8, dans lequel un dit module de traitement est un serveur de son (s_snd) configuré pour obtenir au moins un événement de type son (ev_snd) généré par ladite application (APP) et destiné à un périphérique de sortie de son (SND) dudit dispositif client (CLT).
  10. 10. Dispositif (DA) permettant à un dispositif client (CLT) d'accéder à une application (APP) selon l’une quelconque des revendications 3 à 9, dans lequel un dit module de traitement est un serveur d'impression (s_prn) configuré pour obtenir au moins un événement d'impression (ev_prn) généré par ladite application (APP) et destiné à une imprimante (PRN) connectée audit dispositif client (CLT).
  11. 11. Dispositif (DA) permettant à un dispositif client (CLT) d'accéder à une application (APP) selon l’une quelconque des revendications 3 à 10, dans lequel ledit dispositif (DA) comporte en outre un module (MOD_f) configuré pour transférer au moins un fichier dudit dispositif client (CLT) vers ou depuis un espace de stockage (Str).
  12. 12. Système (SA) permettant à un dispositif client (CLT) d'accéder à une application (APP), ledit système comportant :
    — un dispositif (DA) permettant à un dispositif client (CLT) d'accéder à une application (APP) selon l'une des revendications 3 à 11; et — un dispositif serveur (SRV) comportant un module (MGC) de gestion apte à gérer :
    o un conteneur d'interface (C_IF) exécuté par ledit dispositif permettant d'accéder à une application, et o au moins un conteneur (C„APP) d'une application (APP) accessible par ledit dispositif client (CLT) et configurée pour générer des événements (ev_disp, ev_snd, ev_prn) destinés à des périphériques de sortie (DISP, KB, PRN) dudit dispositif client (CLT).
  13. 13. Système (SA) à un dispositif client (CLT) d'accéder à une application (APP) selon la revendication 12 caractérisé en ce que ledit dispositif serveur (SRV) comporte :
    — un module (AUTH) d'authentification (C101, S102, S103) d'un utilisateur dudit dispositif client (CLT); et — un module (CR_C_IF) configuré pour créer (S104) ledit conteneur d'interface (C_IF) sur authentification dudit utilisateur.
  14. 14. Programme d'ordinateur (Prog) comportant des instructions pour l'exécution des étapes d'un procédé à un dispositif client (CLT) d'accéder à une application (APP) selon une des revendications 1 ou 2, lorsque ledit programme est exécuté par un ordinateur (DA).
  15. 15. Support d'enregistrement lisible par un ordinateur (DA) sur lequel est enregistré un programme d'ordinateur (Prog) comprenant des instructions pour l'exécution des étapes d'un procédé à un dispositif client (CLT) d'accéder à une application (APP) selon une des revendications 1 ou 2.
FR1852048A 2018-03-09 2018-03-09 Procede, dispositif et systeme permettant l'acces a une application deployee dans un conteneur Active FR3078850B1 (fr)

Priority Applications (1)

Application Number Priority Date Filing Date Title
FR1852048A FR3078850B1 (fr) 2018-03-09 2018-03-09 Procede, dispositif et systeme permettant l'acces a une application deployee dans un conteneur

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR1852048 2018-03-09
FR1852048A FR3078850B1 (fr) 2018-03-09 2018-03-09 Procede, dispositif et systeme permettant l'acces a une application deployee dans un conteneur

Publications (2)

Publication Number Publication Date
FR3078850A1 true FR3078850A1 (fr) 2019-09-13
FR3078850B1 FR3078850B1 (fr) 2021-08-27

Family

ID=62873441

Family Applications (1)

Application Number Title Priority Date Filing Date
FR1852048A Active FR3078850B1 (fr) 2018-03-09 2018-03-09 Procede, dispositif et systeme permettant l'acces a une application deployee dans un conteneur

Country Status (1)

Country Link
FR (1) FR3078850B1 (fr)

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20120324358A1 (en) * 2011-06-16 2012-12-20 Vmware, Inc. Delivery of a user interface using hypertext transfer protocol
US20130003106A1 (en) * 2011-06-29 2013-01-03 Canon Kabushiki Kaisha Print control device, print control method, information processing system, information processing apparatus, information processing method, and storage medium
US20140046904A1 (en) * 2012-08-13 2014-02-13 Commvault Systems, Inc Lightweight mounting of a secondary copy of file system data
EP2704446A1 (fr) * 2012-08-31 2014-03-05 Samsung Electronics Co., Ltd Appareil de partage de contenu utilisant un protocol acoustique pour la découverte d'appareil périphériques
US20150309704A1 (en) * 2014-04-28 2015-10-29 Samsung Electronics Co., Ltd Method and electronic device for managing object

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20120324358A1 (en) * 2011-06-16 2012-12-20 Vmware, Inc. Delivery of a user interface using hypertext transfer protocol
US20130003106A1 (en) * 2011-06-29 2013-01-03 Canon Kabushiki Kaisha Print control device, print control method, information processing system, information processing apparatus, information processing method, and storage medium
US20140046904A1 (en) * 2012-08-13 2014-02-13 Commvault Systems, Inc Lightweight mounting of a secondary copy of file system data
EP2704446A1 (fr) * 2012-08-31 2014-03-05 Samsung Electronics Co., Ltd Appareil de partage de contenu utilisant un protocol acoustique pour la découverte d'appareil périphériques
US20150309704A1 (en) * 2014-04-28 2015-10-29 Samsung Electronics Co., Ltd Method and electronic device for managing object

Also Published As

Publication number Publication date
FR3078850B1 (fr) 2021-08-27

Similar Documents

Publication Publication Date Title
US10827004B2 (en) Native viewer use for service results from a remote desktop
US8037191B2 (en) Low-level remote sharing of local devices in a remote access session across a computer network
KR102121626B1 (ko) 네트워크 스토리지 서비스에서 어플리케이션과 파일타입의 관련
EP2936782B1 (fr) Procédé de traitement de requêtes d'accès et navigateur web
EP2795878B1 (fr) Procédé de partage d'un contenu multimédia entre utilisateurs
EP3119060B1 (fr) Procédé et dispositif d'établissement de communications webrtc
EP2107723B1 (fr) Commande d'un dispositif a distance par un terminal
FR2842377A1 (fr) Systeme et procede de configuration automatique et de lancement d'applications clients telnet 3270 dans un environnement windows
FR2946168A1 (fr) Procede de navigation sur le reseau internet, support d'enregistrement, serveur d'acces et poste d'utilisateur pour la mise en oeuvre de ce procede.
FR3078850A1 (fr) Procede, dispositif et systeme permettant l'acces a une application deployee dans un conteneur
EP2395422A1 (fr) Service d'impression ou de numérisation pour téléphone mobile
EP3714588B1 (fr) Procede de gestion a distance d'un dispositif connecte a une passerelle residentielle
EP2575327B1 (fr) Procédé de partage d'une application web entre plusieurs terminaux informatiques reliés à un réseau de communication
EP2647177B1 (fr) Procédé et dispositif pour l'appairage d'un terminal et d'un compte utilisateur
FR2918527A1 (fr) Procede et dispositif d'insertion d'une adresse dans une requete
FR2814020A1 (fr) Procede et dispositif de traitement d'un document electronique dans un reseau de communication
WO2023275475A1 (fr) Procede de gestion d'une passerelle d'acces a un reseau sur un terminal mobile
EP1906625B1 (fr) Procédé et système de partage de fichiers sur un réseau, utilisant des capacités de stockage d'un boîtier de connexion au réseau
EP4115579A1 (fr) Procédé de gestion d'une requête d'accès à un site internet depuis un dispositif d'accès
FR2857191A1 (fr) Systeme de transmission de parametres caracteristiques d'une session de communication d'un terminal vers un serveur distant
EP1650684A1 (fr) Dispositif de médiation pour accéder à des applications non Internet depuis des applications Internet
CN113852666A (zh) 一种通过ftp协议实时获取http资源的方法
FR2862145A1 (fr) Procede de communication entre bureaux virtuels par l'intermediaire d'un reseau, serveur de bureaux virtuels et utilisation de ce serveur
EP2311223A2 (fr) Mise à jour de critères de recherche de contenu définis pour un fournisseur de service
WO2013092569A2 (fr) Procédé de gestion d'un document enrichi

Legal Events

Date Code Title Description
PLFP Fee payment

Year of fee payment: 2

PLSC Publication of the preliminary search report

Effective date: 20190913

PLFP Fee payment

Year of fee payment: 3

PLFP Fee payment

Year of fee payment: 4

PLFP Fee payment

Year of fee payment: 5

PLFP Fee payment

Year of fee payment: 6

PLFP Fee payment

Year of fee payment: 7