FR3078850A1 - METHOD, DEVICE AND SYSTEM FOR ACCESSING AN APPLICATION DEPLOYED IN A CONTAINER - Google Patents

Abstract

Device (DA) enabling a client device (CLT) to access an application (APP), the device (DA) executing a container, called "interface container (C_IF)" and comprising: - a processing module ( s_disp, s_snd, s_prn) configured to obtain an event (ev_disp, ev_snd, ev_prn) for an output device (DISP, PRN, SND_out) of the client device (CLT) and generated by an application (APP) running in a application container (C_APP); and a communication module (comm_disp, comm_snd, comm_prn) configured to generate and send, on obtaining an said event (ev_disp, ev_snd, ev_prn), at least one message (MSG_CLT) obtained from the event , intended for and interpretable by the client device (CLT).

Description

Invention background

The invention relates to the general field of access, from a user's terminal, to a remote executed application.

Among the existing solutions allowing access to a remote application, solutions are known which run in a virtual machine running on a remote server and accessible via a virtual desktop VDI (Virtual Desktop Infrastructure).

These solutions have the disadvantage of consuming significant resources (memory, computing capacity, etc.) at the server level, the use of a virtual machine requiring in addition the resources necessary for the execution of the application it -same, resources for the execution of a complete operating system, for the management of libraries and possibly for the scheduling of applications.

A solution is also known which consists of installing and executing (in other words “deploying”) an application in an application container hosted on a server. The container of an application contains only the binary code of the application and the libraries required by the application, in other words its dependencies. This solution makes it possible to optimize system resources compared to the installation of a virtual machine since only the application code and the libraries necessary for its execution are installed.

However, it is not possible, in the current state of the art, to allow a user to interact via a graphical interface of his client device, with an application executing in an application container.

The invention relates to a solution for accessing a remote application which does not have the drawbacks of existing solutions.

Subject and summary of the invention

More particularly, the invention relates to a method allowing a client device to access an application. The method is implemented in a container, called an "interface container", and comprises the following steps:

- start of a processing module capable of obtaining at least one event intended for an output device of the client device and generated by an application executing in an application container; and - on obtaining such an event, sending at least one message obtained from this event, intended for and interpretable by this client device.

Recall that a container, executed by a machine, is a set of processes isolated from the rest of the other processes executing on the same machine. A container runs from an image that provides the files necessary to support its processes.

As is known, an image is a set of files.

A container shares the operating system of the physical machine running it.

A container of an application contains the binary code of the application and the libraries required by the application. Therefore the container ensures the portability and consistency of the application between various environments. The container of an application is autonomous and self-sufficient to run.

An interface container according to the invention comprises the binary code of one or more functionalities ensured by this interface container, such as a binary code of a software server, of a daemon or of a communication function or conversion, and libraries required by the functionality.

The client device that can be used in the context of the invention is a device allowing access to a website, such as a computer, a tablet, a telephone or any other connected user terminal.

The invention makes it possible to manage different types of event, for example display, printing, sound events, etc.

After the execution of the start-up step of a processing module according to the invention, the interface container offers a software layer allowing access, to a user, via an interface of his client device, to an application deployed in an application container and capable of processing events coming from input devices of the client device and / or generating events intended for output devices of the client device.

The interface container then constitutes an interface between the client device and an application of an application container, the application being chosen by the user. This makes it safer to use the application by providing isolation between the interface container and the application container.

The invention makes it possible to remotely use applications requiring communication with peripherals of the client device, without requiring all of the resources necessary for the use of a virtual machine.

The invention can be used for teleworking. An employer with a client device can remotely and securely use applications hosted on an internal company network, without having to install these applications on an employer client device or install a virtual machine on a server of the internal company network. The employer can access an application hosted on the internal network via a web browser from their client device. The web browser provides various interface functions, for example a display function, by processing events, for example display events, generated by the application.

The invention can also be used to allow a service provider external to a company, temporary access to applications used within the internal network of the company without the need to use a client device of the company. The invention indeed allows the provision of a secure workstation. The provider only needs to connect to the interface container to be able to access a containerized application.

The invention can also be used for training sessions. The invention makes it possible to offer an online workstation to each Internet user, having several applications necessary for working.

In one embodiment, the application deployed in an application container is accessible via a web browser of the client device. A user consults, by means of a client device, a predefined website via a web browser of the client device, for example by means of a predefined address, and authenticates himself in order to connect to an interface container. The interface container can communicate with one or more application containers at the request of the user, via the client device. A user can thus interact with an application deployed in an application container through the interface container.

Therefore, access to an application according to the invention is simple and quick.

The application container and the interface container can be implemented in a cloud network.

In one embodiment of the invention, a user accesses, using a client device, a website that can be viewed on a web browser, for example of the HTML type, for example a browser of the Google Chrome, Firefox, Opera 12 or Safari type. 6 (registered trademarks) supporting the HTML5 language (version 5.2 of HTML dated December 21, 2017).

In a particular embodiment of the invention, an application container deploys only one application, which guarantees an additional level of security. In fact, the containers are tight relative to each other. For example, if an application deployed in a dedicated container is corrupted (virus, spy, or other security breach), the spread of corruption is limited to the execution environment of the corrupted application, therefore to its own container. , and does not impact other applications deployed in another container.

However, it is also conceivable that an application container deploys several applications. A spread of corruption of an application deployed in a container is limited to other applications deployed in the same container.

The interface container can communicate with several application containers.

Correlatively, the invention relates to a device allowing a client device to access an application, this device executes a container, called an interface container and comprises:

- a processing module configured to obtain an event intended for an output device of the client device and generated by an application executing in an application container; and - a communication module configured to generate and send, on obtaining an event intended for an output device of the client device, at least one message obtained from the event, intended for and interpretable by the client device.

In one embodiment, the processing module of the interface container is a software module.

The characteristics and advantages of the device according to the invention presented below apply in the same way to the method according to the invention.

In one embodiment, the device allowing a client device to access an application further comprises:

- a communication module configured to obtain an event generated by an input device of the client device; and a processing module configured to generate and send, on obtaining an event generated by an input device, at least one message obtained from the event, intended for and capable of being processed by an application executing in an application container.

The device according to the invention allows the client device to use an application, generating or processing events relating to input or output devices of the client device, without it being installed on the client device and without needing install a virtual machine on a server accessible by the client device.

In one embodiment, the processing and communication modules execute daemons running in the interface container.

It is recalled that a daemon is a process which has no interface with a user and can be referred to as a machine to machine (M2M) process.

In one embodiment, the processing module configured to obtain an event intended for an output device of the client device is the same as the processing module configured to generate and send at least one message obtained from an event generated by an input device of the client device.

In one embodiment, the communication module configured to generate and send at least one message obtained from an event intended for an output device of the client device, is the same as the communication module configured to obtain a generated event by an input device of the client device.

The device according to the invention can be implemented in a cloud network (cloud).

It can be placed in a break between the client device and a machine running an application container.

In one embodiment, the device according to the invention further comprises a conversion module placed in the cut-off between a processing module and a communication module, the conversion module being configured for:

- convert the format of an event generated by an application and intended for an output device, into a format supported by the communication module; or / and to - convert the format of an event generated by an input device of the client device into a format supported by the processing module.

The conversion module then acts as an intermediary between a processing module and a communication module that does not support the same communication standard. The device according to the invention can therefore have ports on the client device side and ports on the machine side executing an application container of different types.

In one embodiment, communications internal to the device allowing a client device to access an application are governed by file type sockets. These internal communications are the communications between the communication module and the processing module, and possibly between the communication module and the conversion module and between the conversion module and the processing module.

As it is more difficult to intercept file type sockets than sockets exported from the device allowing access to an application to a network, such as TCP sockets, this embodiment then makes it possible to reinforce the computer security of the invention.

In one embodiment of the invention, the interface container, executed by the device allowing access to an application, provides at least one service from a display service, a print service, a sound service , and a file transfer service. This list of services is not exhaustive. In practice, each of these services can be implemented by a daemon running in the interface container.

The invention therefore makes it possible to centralize modules for processing display, printing, sound, file transfer or other software server events, at the interface container level, and to implement clients for these modules. processing, depending on the need for each application, at the level of the application containers.

As a result, a daemon required for at least two different applications, such as a print event processing module, can be shared, by deploying the shared daemon in the interface container and connecting the container d interface to at least two application containers, each deploying an application.

In one embodiment, the processing module is a display server configured to obtain at least one display event generated by the application and intended for a screen of the client device.

The interface container provides a graphical interface with which the user can interact.

The user of the client device can thus benefit from a graphical interface of the application deployed in a container.

According to the invention, a screen of the client device designates a physical screen, possibly a touch screen, or a video projector, or other display device.

In an exemplary implementation of the invention, the module for processing a display event is an X.org server, version Xll, v.11.0 (registered trademark).

This processing module implements the management of the screen, the mouse and the keyboard of the client device.

In one embodiment, the device allowing a client device to access an application further comprises a module configured to adapt the message obtained from a display event and intended for the screen of the client device to a display parameter for said screen (size, resolution, etc.).

The invention can therefore be used by client devices of different screen sizes and having different graphic resolutions. In addition, for a given client device, the display adapts to a modification or change generated by a user action, for example a modification of the screen resolution of the client device or a change in screen size. a browser window.

The module configured to adapt the message obtained from the display event can control the execution of the application, for example by closing a window in the application's graphical interface.

In a particular implementation, the display adaptation module is of the RPC (Remote Procedure Call) type.

In one embodiment, the processing module is a sound server configured to obtain at least one sound type event generated by the application and intended for a sound output device of the client device.

In one embodiment, the processing module is a print server configured to obtain at least one print event generated by the application and intended for a printer connected to the client device.

This mode allows documents obtained by an application deployed in a container to be printed by the client device or by a printer connected to the client device.

In one embodiment, the device allowing a client device to access an application further comprises a module configured to transfer at least one file from the client device to or from a storage space.

The storage space can be included in a cloud network and identified by a logical address of a storage network resource, for example a network path to a folder.

The storage space can be a volume local to the device allowing a client device to access an application, for example a directory.

This embodiment allows a user to store files or documents in a storage space external to the client device and to recover files from the storage space in a secure manner through the interface container.

The storage space can be shared by several users.

The invention also relates to a system allowing a client device to access an application, the system comprising:

- a device allowing a client device to access an application, as described above; and a server device comprising a management module capable of managing:

o an interface container as described above; and o at least one container of an application accessible by the client device, said application being configured to generate events intended for output devices of the client device via the interface container.

The server device here is a physical machine, for example a computer. The expression “server device” is used to distinguish it from a software server such as a processing module included in an interface container.

In one embodiment of the invention, the website allowing access to the interface container is hosted in the server device of the system according to the invention.

In one embodiment of the invention, the server device comprises a module for authenticating the user of the client device and a module configured to create, in other words instantiate, the interface container, for this user, following a user authentication.

The server device creates the interface container from a reference image compatible with its operating system.

The interface container and the application container can be run by separate physical machines.

The interface container and the application container can both be executed by the server device, or by another same physical machine, for example implemented in a cloud network. In this case, the communication latency between the interface and application containers is therefore reduced.

In one embodiment, the authentication of a user of the client device is governed by a protocol chosen from the oAuth, Kerberos (Active Directory) and LDAP protocols.

Different levels of security of use of the invention can thus be envisaged.

The invention also relates to a computer program on a recording medium, this program being capable of being implemented in a device according to the invention, or more generally in a computer, this program comprising instructions adapted to the management of at least one application as described above.

This program can use any programming language, and be in the form of source code, object code, or intermediate code between source code and object code, such as in a partially compiled form, or in any other desirable form.

The invention also relates to information or recording media readable by a computer, and comprising instructions of the computer program as mentioned above.

The information or recording media can be any entity or device capable of storing the program. For example, the supports may include a storage means, such as a ROM, for example a CD ROM or a microelectronic circuit ROM, or else a magnetic recording means, for example a floppy disk, a disc hard drive or flash memory.

On the other hand, the information or recording media can be transmissible media such as an electrical or optical signal, which can be routed via an electrical or optical cable, by radio link, by wireless optical link or by other ways. The programs according to the invention can in particular be downloaded from a network of the Internet type.

Alternatively, each information or recording medium can be an integrated circuit in which the program is incorporated, the circuit being adapted to execute or to be used in the execution of the method in question.

Brief description of the drawings

Other characteristics and advantages of the present invention will emerge from the description given below, with reference to the appended drawings which illustrate an embodiment thereof devoid of any limiting character. In the figures:

- Figure 1 illustrates an architecture of a device according to the invention and of a system according to the invention according to an embodiment;

- Figure 2 is a flowchart representing steps of a method according to an embodiment of the invention in a particular context of implementation;

- Figure 3 illustrates the hardware architecture of a device according to an embodiment of the invention;

- Figure 4 shows the functional architecture of a device according to an embodiment of the invention; and - Figure 5 shows a functional architecture of a server device included in a system according to an embodiment of the invention.

detailed description

FIG. 1 presents the functional architecture of an interface container C_IF, of an application container C_APP, and the architecture of a device DA and of a system SA conforming to an embodiment of the invention, this device DA and this system SA allowing a client device CLT to access a remote APP application.

We place ourselves here in a context in which the various processing modules of the interface container were started following the authentication of a user of the client device. These steps are described later with reference to Figure 2.

In this embodiment, the CLT client device is a computer comprising input devices, such as a mouse, a KB keyboard and a MICRO microphone, and output devices such as a DISP screen, a PRN printer and an SND speaker.

The CLT client device communicates with an SRV server device implemented in a cloud network according to the HTTPS protocol. As a variant, it is in particular possible to use the HTTP protocol. Other protocols are possible.

In particular, the CLT client device consults, via a web browser installed on the client device, a predefined website accessible via the SRV server device.

The SRV server device includes a MGC container management module (Figure 5). Following a request from the CLT client device expressed on the website, this module instantiates a C_IF interface container. In this embodiment, the SRV server communicates with the interface container C_IF in HTTPS.

The interface container C_IF is executed by the device DA according to the invention. This DA device allows the user of the client device to access, via their web browser and the SRV server, an APP application executing in an application container C_APP.

In the embodiment described, the APP application is executed on a physical machine MPhy.

More specifically, in general and as subsequently described with reference to FIG. 2, in this embodiment, several daemons are started in the interface container C-IF, for the user following his authentication, each of these daemons being configured to wait for events of different types (display, sound, printing, etc.) capable of being generated by applications executing in application containers, and to send, upon receipt of such events, messages to the client device for events to be output by output devices.

This DA device can be implemented in a cloud network.

The DA device can be the SRV server device itself.

In this example, the C_IF interface container includes a MOD_disp display module which includes an s_disp display server capable of processing requests comprising ev_disp display events originating from a c_disp display client of the APP application. In the exemplary embodiment described here, this display server s_disp is a daemon started after authentication of the user, awaiting display events intended for the client device CLT.

It is assumed that the application container C_APP executes the application APP comprising a graphics module in the form of a display client c_disp.

The c-disp display client implements the management of the basic devices of the CLT client device, such as the DISP screen, the mouse and the KB keyboard.

In this embodiment, the s_disp display server is an X Windows System server, the implementation of which is X.org. The X server uses the xf86-video-dummy module to create a virtual graphics environment, devoid of a physical screen card.

The s_disp display server implemented as X.org can be started according to the command:

X.org -nolisten tcp -dpi 96 + RANDR extension -logfile /home/balloon/.logs/X.org.log -config /composer/X.org.conf: 0

In this embodiment, the Windows System X server uses the Xll protocol and the C_IF interface container communicates according to the HTTPS protocol with the SRV server device.

In this embodiment, the MOD_disp display module deployed by the C_IF interface container comprises, as shown in FIG. 1:

the s_disp display server;

a conv-disp conversion module configured to convert data received according to a first protocol from the display client c-disp, via the display server s-disp into data intended for the client device CLT and formatted according to a second protocol and vice versa; and a comm_disp communication module configured to communicate with the CLT client device. It is notably configured to transmit to the web browser of the CLT client device MSG_CLT messages generated by the display server s_disp

In the embodiment described, the conv-disp conversion module executes the xllvnc software to convert data according to the Xll protocol into data in RFB (Remote Frame Buffer) protocol and vice versa, RFB being the protocol used for a VNC server (Virtual Network Computing) (not shown in Figure 2); by default a VNC server sends / receives TCP type sockets.

In the embodiment described, the comm_disp communication module executes a Websockify application which makes it possible to convert TCP type sockets into websockets supported by the HTTPS protocol and interpretable by the HTML5 web browser of the CLT client device.

In this embodiment, the conv-disp conversion module runs version 0.9.14 of the xllvnc process.

In this embodiment, the comm-disp communication module executes version 1.0 of the websokify process.

In this embodiment, the display server s_disp, the conversion module conv_disp and the communication module comm_disp are daemons included in the interface container C-IF and executed by the device DA. The MOD_disp display module includes these three s_disp, comv_disp and comm_disp daemons for managing display events.

To reduce the attack surface and optimize the network load, the s_disp server communicates with the c_disp client deployed by the C_APP application container by sockets; internal communications in the MOD_disp display module are also governed by sockets; the comm_disp communication module is the only one to export its services outside the MOD_Disp module.

In this embodiment, this comm_disp module communicates in RFB with the server device SRV via the portTCP / IP 6081.

In this embodiment, the command line allowing the launch of the execution of the software xllvnc of the interface container C_IF is: xllvnc -display: 0 -xkb -noxinerama -shared -xrandr -nolookup -nopw -forever -unixsockonly / tmp / .unixxllvnc

In this embodiment, the command line allowing the execution of websockify when the C_IF interface container is started is: python /composer/noVNC/utils/websockify/websockify.py -unix-target /tmp/.unixxllvnc 6081

The web browser of the CLT client device is configured to receive MSG-CLT messages transmitted by the comm_disp module. These messages are for example transmitted via a VNC “no-vnc” javascript library of the browser. The no-vnc library is responsible for receiving MSG_CLT messages relating to the display on the DISP screen of the client device, and for transmitting to the SRV server, ev_lect events sent by the KB keyboard or by the device mouse. CLT customer.

In this embodiment, the graphic module c_disp of the application container C_APP comprises a client c_disp of the application type Xll. This Xll application type client communicates by sockets with the X.org server as described above.

The Xll application type client communicates with the X.org display server either by file type sockets present in a temporary volume shared between the C_IF interface container and the C_APP application container, for example a tmp volume, either by TCP / IP network type sockets. Communication between the s_disp server and the c_disp display client is more secure in the case where the sockets are of type file.

According to the access method according to the invention described later with reference to FIG. 2, the interface container C_IF, and more precisely its module s_disp, obtains the display events ev_disp generated by the application deployed by the container C_APP and sent by the module c_disp of the container C_APP. Each of these ev_disp events is intended for the DISP display device of the CLT client device.

The event can be transmitted as a socket by the C_APP application container. In fact, in this embodiment, the interface container has a shared volume, named tmp. In this shared volume, the c_disp display client creates a file type socket named X0 in a /tmp/.Xll-unix directory in the tmp shared volume. The s_disp display server detects the presence of the XO file socket in the /tmp/.Xll-unix directory, retrieves the socket and obtains the ev_disp event.

Following the obtaining of the ev_disp event, the interface container C_IF, and more precisely its comm_disp module, generates a message MSG_CLT obtained from the event ev_disp and interpretable by the client device CLT and sends this message MSG_CLT to destination of the CLT client device via the SRV server device.

In addition, the interface container C_IF can receive events, generated by input devices of the client device CLT.

For example, the comm_disp module obtains, via the SRV server device, an evject event presenting a stream of data entered by the keyboard KB.

Following the reception of this evject event generated by an input device, the comm_disp communication module transmits it to the s_disp processing module via the conv_disp conversion module. The conversion module ensures the conformity of communications between the comm_disp communication module and the s_disp processing module, by converting, if necessary, the format of these communications.

The s_disp module generates at least one MSG_APP message obtained from the evject event and interpretable by the APP application deployed by the C_APP container. The s_disp module of the C_IF interface container sends the MSG_APP message to the ç_disp module of the C_APP application container.

The user can benefit from a virtual screen of the C_IF interface container displayed on the web browser of their CLT client device.

In the example of FIG. 1, the interface container C_IF deploys an s_dim module configured to adapt a message MSG_CLT to be transmitted to the client device CLT as a function of a display parameter of the screen DISP of the client device CLT obtained. from an ev_disp display event transmitted by the CLT client device

This display parameter can be a graphic resolution value of the DISP screen, the size of the web browser window of the CLT client device, the size of the DISP screen or any other parameter related to the display on the DISP screen of the CLT client device.

In this embodiment, the s_dim module executes software providing an RPC type service.

The s-dim module allows the use of CLT client devices of different types: smartphone, tablet, computer, MAC, etc. The virtual screen of the C_IF interface container displayed on the web browser of the CLT client device is dynamically resized.

On the first connection of the CLT client device to the website accessible via the SRV server, thus each time a display parameter is modified, for example when resizing the web browser window of the CLT client device, the web browser notifies the C_IF interface container of its new resolution: the s_dim module obtains, from the CLT client device, via the SRV server, an ev_dim event relating to the graphic resolution.

Following the obtaining of the ev_dim event, the s_dim module notifies the MOD_disp display module of the C_IF interface container, and more precisely its s_disp module, of the new graphic resolutions to be applied. In turn, the s_disp processing module communicates the new graphics resolutions to the c_disp graphics module.

In this embodiment, the s_dim module deploys an RPC service, named in the rest of the document "Spawner" and developed in nodejs (spawner-service.js).

In this embodiment, the s_dim module configured to adapt an MSG_CLT message relating to the display to a display parameter of the DISP screen, listens on TCP port 8001, communicates in HTTPS with the SRV server device and communicates by sockets with the s_disp display server.

In this embodiment, the command line allowing the execution spawnerservice.js when starting the interface container C_IF is: nodejs /composer/node/spawner-service/spawner-service.js

The s_dim module configured to adapt the MSG_CLT message obtained from the ev_disp display event to a display parameter on the DISP screen, can control the execution of the application deployed by the Ç_APP container.

Indeed, the s_dim module, through the Spawner service, is able to activate the focus on an application, to terminate an application and to list the applications present on the virtual desktop of the C_IF interface container.

In the embodiment presented in Figure 1, the C_IF interface container deploys a MOD_snd module to manage applications that require sound interfaces.

The MOD_snd module includes:

a processing module s_snd configured to obtain at least one event of sound type ev_snd generated by the application APP deployed in the container C_APP and intended for a device for outputting its SND from the client device CLT, such as the speakers SND; and a comm_snd communication module configured to generate and send at least one MSG_CLT message obtained from the ev_snd event and intended for and interpretable by the CLT client device.

In this embodiment, the server s_snd and the communication module comm_snd are daemons included in the interface container C_IF and executed by the device DA. The MOD_snd sound module includes the s_snd and comm_snd daemons.

In the example described here, it is assumed that the APP application executing in the application container C_APP comprises a client c_snd of the server of its s_snd.

In the embodiment presented in FIG. 1, the s_snd sound server is for example of the Pulseaudio type (free software of the freedesktop project, version: PulseAudio Sound Server 8.0).

In order to ensure communication using the HTTPS protocol between the container C_IF and the SRV server, the comm_snd communication module executes a Live Sound Service type process.

The Live Sound Service process is developed in nodejs.

The comm_snd communication module captures the sound coming from the s_snd module and transforms it into an MSG_CLT message comprising a sound stream supported by the web browser of the client device, for example a WAV or MP3 type stream.

The comm_snd communication module sends the message MSG_CLT to the speakers SND of the client device CLT via the server device SRV, according to the HTTPS protocol. The sound flow contained in the MSG_CLT message can be detected by the web browser of the CLT client device, by a simple HTML tag of audio type. The message MSG_CLT is reproduced by the speakers SND.

In the same way, the Live Sound Service process executed by the comm_snd communication module can convert an ev_micro file or sound stream picked up by the microphone of the CLT client device via the server device SRV according to the HTTPS protocol into a sound stream governed by a protocol supported by the Pulseaudio type s_snd server. The server s_snd then generates an MSG_APP message obtained from the ev_micro event and interpretable by the APP application. The interface container C_IF sends the message MSG_APP to the application container C_APP so that it is rendered by the physical machine MPhy.

In this embodiment, the command line for starting Pulseaudio when starting the C_IF interface container is:

/ Usr / bin / pulseaudio

In this embodiment, the command line for starting Live Sound Service when starting the C_IF interface container is: nodejs /composer/node/livesound-service/livesound-service.js

In this embodiment, the Live Sound Service process exports the TCP / IP port 8000 to communicate in HTTPS with the SRV server.

The communications of the sound server s_snd with the communication module comm_snd and / or with the client sound c_snd can be governed by sockets to ensure the security of these communications.

In this embodiment, the pulseaudio server (or daemon) creates a file type socket named .pulse.sock in the shared volume tmp and the Live Sound Service daemon detects the presence of the socket and retrieves it.

In the embodiment presented in FIG. 1, to manage applications requiring a printing service, the interface container C_IF deploys a MOD_prn module which comprises:

a processing module s_prn configured to obtain an ev_prn printing event generated by the APP application deployed in the container C_APP and intended for a PRN printer connected to the client device CLT; and a comm_prn communication module configured to generate and send at least one MSG_CLT message obtained from the ev_prn event, intended for and interpretable by the CLT client device.

In this embodiment, the s_prn server is a print server. In particular, the s-prn print server can be based on the Common Unix Printing System technology (CUPS, trademark registered by Apple, version: 1.3-4) which makes it possible to generate files in PDF format.

In this embodiment, the application container C_APP deploys a print client c_prn from the print server s_prn. The c_prn client and the s_prn print server communicate by shared file sockets in the temporary volume tmp.

The c_prn print client connects to a file socket named ".cups.sock" and placed in the / tmp directory. The print client places data about an ev_prn print event in the .cups.sock socket.

The print server s_prn detects the presence of data at the socket .cups.sock placed in the shared volume tmp and thus receives the print event ev_prn.

Following receipt of the ev_prn print event, the s_prn server generates a file containing the print data received from the c_prn client. Then, the s_prn server places the generated file in a directory, named ".printer-queue", containing a list of files waiting to be printed.

The s_prn server is for example of CUPS type and the generated files are for example in PDF format.

Other file formats can be generated, for example .jpeg type files

The comm_prn communication module is configured to detect the presence of a new document in the ".printer-queue" directory.

For example, the comm_prn communication module is configured to provide a Printer-service type service. This Printer-service, developed in nodejs (printer-service.js), includes a "watcher" functionality for detecting changes in the queue of the ".printer-queue" directory.

By detecting the placement, by the print server s_prn, of the new file in the directory “.printer-queue”, the communication module receives the print event ev_prn.

Following the detection of the presence of the new document in the “.printerqueue” directory, the comm_prn communication module generates an MSG_CLT print message from the ev_prn event. The MSG_CLT message is intended for the CLT client device.

In this embodiment, the printer-service.js service is not exported, in other words it does not communicate in HTTPS with the SRV server device, but communicates directly with a MOD_user module of the C_IF interface container. The comm_prn communication module sends the print message MSG_CLT to the MOD_user module and it is this MOD_user module which transfers the print message MSG_CLT to the server device SRV so that it in turn transfers it to the client device CLT.

The MOD_user module, described later, is configured to run a session sharing service, of the "Broadcast Session Service" type developed in nodejs (broadcastservice.js).

In this embodiment, the comm_prn communication module is not exported and communicates with the SRV server via the MOD_user module to reduce the number of open sockets. The same socket is used for the session sharing service and also for the printing service.

In another embodiment, the comm_prn communication module is exported and independent of the MOD_user module.

In this embodiment, when the web browser of the CLT client device is notified of the presence of a new file to be printed, it downloads it via the File Service service developed in nodejs (file-service.js) and executed by the container C_IF interface. A popup window then appears in the web browser of the CLT client device to notify the user of the presence of the new file in order to start printing on the PRN printer of the CLT client device.

The embodiment based on the generation of PDF files offers compatibility with several types of client devices. Indeed, the MOD_prn printing module is completely independent of the printer driver of the CLT client device and its printing context.

When the CLT client device downloads the PDF file to print, it runs its own printer driver to trigger printing on its PRN printer. The print driver can be, for example, Google Cloud Print for a CLT client device of the smartphone type using the Android operating system (trademark registered by Google), or AirPrint for a CLT client device of the smartphone type using the iOS operating system (trademark registered by Apple).

In this embodiment, the Broadcast Service deployed by the C_IF interface container listens on TCP port 8003.

In this embodiment, the File Service service deployed by the C_IF interface container listens on TCP port 8080.

In this embodiment, the command line for starting the CUPS type server when the C_IF interface container is started is:

/ usr / sbin / cupsd -c /etc/cups/cupsd.conf-f

In this embodiment, the command line for executing broadcastservice.js when starting the C_IF interface container is: nodejs /composer/node/broadcast-service/broadcast-service.js

In this embodiment, the command line for executing fileservice.js when starting the C_IF interface container is: nodejs /composer/node/file-service/file-service.js

In this embodiment, the MOD_prn printing module is quite simply a logical set of the s_prn and comm_prn modules relating to the management of printing events. The MOD_prn module does not have an additional software layer, above the s_prn server and the comm_prn communication module.

In the embodiment presented in FIG. 1, the same processing module for the interface container C_IF can be started for several users, who then share the same session.

Each of these users connects via their CLT client device, via the SRV server device, to the same interface container C_IF.

A MOD_user module of the C_IF interface container is configured to provide notification of session sharing between users. It counts the number of users connected to the same interface container and manages the exchanges with each client device of these users.

The MOD_user module is for example a server of the Broadcast Session Service type.

According to the need for the functioning of an APP application, its application container Ç_APP deploys one or more clients of the servers deployed by the interface container C_IF.

For example, the C_APP application container presented in Figure 1 deploys a c_disp display client to generate ev_disp display events and / or process evject keyboard-mouse events, a c_snd sound client for event generation ev_snd sound and / or processing of ev_micro sound events and a c_prn print client to generate ev_prn print events.

As an alternative, the C_APP application container deploys a single client, for example a c_disp display client.

Containers of different applications are sealed to each other and communicate only with the interface container C_IF to ensure better security. Each C_APP application container has its own address, its own CPU computing capacity, its own memory and its own namespace.

In the embodiment presented in FIG. 1, the interface container C_IF deploys a transfer module MOD_f configured to provide a file transfer service from the client device CLT to a storage space Str located in a cloud network.

No C_APP application container is required to provide this file transfer service.

Several communication protocols between the MOD_f transfer module of the C_IF interface container and the Str storage space can be envisaged, such as for example NFS (Network File System, developed by Sun Microsystems), S3 (Simple Storage Service, developed by Amazon), Dropbox (registered trademark), etc.

In another embodiment, the storage space Str can be included in the device DA according to the invention, executing the interface container C_IF.

In this embodiment, the transfer module MOD_f is configured to expose the file downloading functions between the web browser of the client device CLT and the storage space Str in the cloud network. These download functions are for example a download function in download mode (from the storage space to the browser) and a download function in upload mode (from the browser to the storage space)

The MOD_f transfer module comprises for example a server of the File Manager Service type.

In one embodiment, a “drag and drop” type movement of a local file of the client device CLT in the window of the web browser can lead to a transfer of this file in the storage space Str.

The File Manager Service server can listen on TCP port 5000 for these communications with the SRV server device.

In this embodiment, an HTML window displayed in the web browser presents the tree structure of the storage space Str containing the documents of the user transferred by the module MOD_f.

In this embodiment, the command line allowing the execution of File Manager Service when the C_IF interface container is started is: nodejs /composer/node/angular-filemanager-nodejs-bridge/server.js

FIG. 2 presents different steps of the method according to the invention, making it possible to access the APP application, in an exemplary implementation. In this figure, various steps have been shown implemented in this example by the client device CLT, the server device SRV, the device DA according to the invention and the physical machine MPhy.

During a step C100, a user having a CLT client device accesses a predefined website via a web browser of the CLT client device, for example of the HTML5 type, by means of a URL (for “unified Resource Locator "In English) predefined. This website is accessible via the SRV server device. In particular, the website can be hosted on the SRV server device.

The website displays an authentication interface, for example an interface where the user must enter his user name and password.

During a step C101, the user authenticates himself, by sending for example his identifier and his password to the server SRV. The SRV server receives them during a step

S102 and checks, during a step S103, whether the authentication is correct or not. Authentication can be defined using the oAuth protocol, or Kerberos (Active Directory), or LDAP, or other authentication protocol. Steps C101, S102 and S103 are repeated until authentication is successful.

Following a successful authentication, and in accordance with the invention, an interface container C_IF is instantiated (step S104) for the user authenticated from an image of interface container compatible with the operating system of the server. SRV.

This C_IF interface container is thus dedicated to the CLT client device.

The SRV server device creates the C_IF interface container from a reference image compatible with the operating system of the SRV server device, for example an image under Debian, Ubuntu, or Centos (registered trademarks). This distribution image is a compiled file containing the code and the libraries required by the functionalities provided by the interface container C_IF.

In this embodiment, this interface container C_IF is executed in the device DA implemented in a cloud network (cloud) and communicates with the server device SRV according to the HTTPS protocol.

The device DA starts the interface container C_IF during a step D105.

In the embodiment described here, the interface container Ç_IF deploys an s_disp daemon offering a display server service and s_snd, and s_prn daemons for sound and printing.

During this step S104 of creation of the container C_IF, the server device SRV starts the servers s_disp, s_snd, s_prn capable of obtaining events ev_disp, ev_snd, ev_prn intended for an output device DISP, PRN, SND of the client device CLT and generated by an APP application running in a C_APP application container.

For each type of event expected, the DA device starts one or more daemons deployed in the C_IF interface container. For example, to manage display type events, an s_disp display server, a conv_disp conversion module, and a comm_disp communication module as described in Figure 1 are started.

At the end of step S104 of creating the interface container C_IF and starting its servers, a virtual desktop is displayed in the browser of the client device.

In one embodiment, during step S104 of creating the interface container C_IF, the server SRV creates two volumes of data on the device DA:

- a temporary volume, named for example tmp, used to store temporary files, for example file type sockets coming from or intended for a C_APP application container, this volume is shared by the C_IF interface container and the container C_APP application; and - a volume called "home", used to store user data, for example office files or images, this volume is shared by the interface container C_IF and the SRV server.

It is assumed that the user wishes to access an APP application executing in a C_APP application container.

During a step S106, the SRV server controls the establishment of a connection between the interface container C_IF and this application container Ç_APP.

The application container C_APP can run in the SRV server, in the DA device which runs the interface container C_IF, or in another physical machine MPhy.

In this embodiment, a physical machine MPhy hosts the application container C_APP.

During step S106, the server SRV sends information to the device DA and to the machine MPhy allowing them to establish a connection between the interface container C_IF and the application container C_APP. The reception of this information is acknowledged by the device DA and the physical machine MPhy during a step D108 and a step M108 respectively.

The information used to establish the connection between the C_IF and C_APP containers are file sockets relating to daemons deployed by the C_IF interface container and environment variables.

The environment variables present, for example, information on the authenticated user obtained during step C101, which subsequently makes it possible, for example, to display a personalized welcome message bearing the name of the user, when he accesses the APP application.

During step D108 relating to establishing a connection between the interface container C_IF and the application container C_APP, the interface container C_IF places file sockets in the / tmp directory to indicate to the container C_APP application what are the identifiers of the server modules s_disp, s_prn, s_snd of the container C_IF with which the application container C_APP can communicate.

The file sockets shared by the interface container to establish a connection with an application container are identical for any application container.

During a step M10 of the method, the machine MPhy executing the application container C_APP sends an event generated by the application APP and intended for an output device of the client device CLT. The sending can be in the form of a placement of a file socket representing the event in the shared directory tmp by the application container C_APP. The socket can be an X0 or .pulse.sock or .cups.sock file described above.

During a step D120, the interface container obtains the event intended for the output device, by recovering for example the socket of the directory tmp.

During a step D130, the interface container C_IF obtains a message MSG_CLT from the event obtained during step D120, and sends it to the client device

CLT via the SRV server device. The message MSG_CLT is intended for and interpretable by the CLT client device.

In the embodiment described here, the device DA has the architecture of a computer, as illustrated in FIG. 3. It notably comprises a processor 7, a random access memory 8, a read-only memory 9, a non-flash memory volatile 10 in a particular embodiment of the invention, as well as communication means 11. Such means are known per se and are not described in more detail here.

The read-only memory 9 of the device DA allowing access to an application, according to the present invention constitutes a recording medium in accordance with the invention, readable by the processor 7 and on which is recorded here a computer program Prog in accordance with the invention. The memory 10 of the device DA allowing access to an application makes it possible to record variables used for the execution of the steps of the invention, such as the number of sessions opened on an interface container, the number of containers d applications connected to the interface container or the identifiers of a client device.

The Prog computer program defines software and functional modules here, configured to allow a CLT client device to access an APP application. These functional modules are based on and / or control the hardware elements 7-11 of the device hosting an interface container mentioned above.

FIG. 4 presents a functional architecture of the device DA allowing access to an application according to an embodiment. The DA device comprises a server s_out configured to obtain an ev_disp, ev_snd, ev_prn event generated by an application and a comm_out communication module configured to generate at least one MSG_CLT message obtained from the ev_disp, ev_snd, ev_prn event, intended for and interpretable by the CLT client device.

In one embodiment, the server s_out can be one of the server modules s_disp, s_snd or s_prn described above and presented in FIG. 1. The communication module comm_out can be one of the modules comm_disp, comm _snd, comm_prn described above.

The DA device allowing access to an application also includes a commjn communication module configured to obtain an evject event, ev_micro generated by an input device of the CLT client device, and an sjn server configured to generate and send to the application deployed in the application container at least one MSG_APP message obtained from the evject, ev_micro event and interpretable by the application deployed by the application container C_APP.

In one embodiment, the server s_out is the server sjn itself.

In one embodiment, the comm_out communication module is the commjn communication module itself.

In one embodiment, the server s_in can be one of the server modules s_disp or s_snd described above and presented in FIG. 1. The communication module commjn can be one of the modules comm_disp or comm _snd described above.

FIG. 5 presents a functional architecture of an SRV server device which can be used in an embodiment of the invention. The SRV server includes an AUTH module for authenticating a user of a CLT client device and an MGC container management module. This MGC module includes a CR_C_IF module for creating an interface container, a CR_C_APP module for creating an application container, an ENR module for enriching an application container with data and a CX module command for establishing a connection between the interface container C_IF and the application container C_APP.

The creation of a C_APP application container can result in a start of this C_APP container for a user, in other words by launching the execution of this C_APP container.

In one embodiment, the functionalities provided by the SRV server device are processes deployed in a container, other than the C_IF interface container or the C_APP application container, and executed by the SRV server device.

For the deployment, in other words the installation, of an APP application in a C_APP application container, the SRV server creates a container from a reference distribution image compatible with its own operating system, for example an image under Debian, Ubuntu, or Centos (registered trademarks), then install the APP application in this C_APP container.

In one embodiment, the image of the APP application is enriched with metadata, such as:

icon: name of the icon file representing the APP application;

icondata: content of the encoded icon file;

keyword: keywords of the APP application used for research;

cat: category of the APP application;

launch: class name Xll Windows Class;

template: model used when creating the C_APP container;

name: name of the APP application;

- displayname: name of the APP application displayed by a graphical interface;

type: character string specifying the type of container ("app" for an application container);

mimetype: Type of data format (mime) supported by the application;

fileextensions: extension of files that can be supported by the application; and legacyfileextensions: native file extension.

In one embodiment, an application in GNU / Linux Xll format is natively supported by an application container, while an application in Microsoft Windows 5 format is supported via a Wine emulator.

In one embodiment, the C_IF interface container and / or the C_APP application container are developed by Docker software (trademark registered by Docker, version 18.02.0 dated February 08, 2018) or by LXC software (Linux Containers, trademark registered by Linux, version 2.1.1 dated October 19, 2017).

Claims (15)

1. Method allowing a client device (CLT) to access an application (APP), said method being implemented in a container (C_IF), called "interface container", the method comprising the following steps: - start (D105) of a processing module (s_disp, s_snd, s_prn) capable of obtaining at least one event (ev_disp, ev_snd, ev_prn) intended for an output device (DISP, PRN, SND_out) of said client device ( CLT) and generated by an application (APP) running in an application container (C_APP); and - on obtaining (D120) a said event (ev_disp, ev_snd, ev_prn), sending (D130) at least one message (MSG_CLT) obtained from said event (ev_disp, ev_snd, ev_prn), intended for and interpretable by said client device (CLT). 2. Method according to claim 1, wherein said application (APP) is accessible (Cl 12) via a web browser of the client device (CLT). 3. Device (DA) allowing a client device (CLT) to access an application (APP), said device (DA) executing a container, called interface container (C_IF) and comprising: - a processing module (s_disp, s_snd, s_prn) configured to obtain an event (ev_disp, ev_snd, ev_prn) intended for an output device (DISP, PRN, SND_out) of said client device (CLT) and generated by an application (APP ) running in an application container (C_APP); and - a communication module (comm_disp, comm _snd, comm _prn) configured to generate and send, on obtaining a said event (ev_disp, ev_snd, ev_prn), at least one message (MSGJ2LT) obtained from said event, intended to and interpretable by said client device (CLT). 4. Device (DA) allowing a client device (CLT) to access an application (APP) according to claim 3 comprising: - a communication module (comm_disp, comm_snd) configured to obtain an event (evject, ev_micro) generated by an input device (KB, MICRO) of said client device (CLT); and - a processing module (s_disp, s_snd) configured to generate and send, on obtaining a said event (evject, ev_micro) generated by a said input device (KB, MICRO), at least one message (MSG_APP) obtained from said event (evject, ev_micro), intended for and able to be processed by an application (APP) executing in an application container (C_APP). 5. Device (DA) allowing a client device (CLT) to access an application (APP) according to claim 3 or 4, wherein communications internal to said device (DA) are governed by file type sockets. 6. Device (DA) allowing a client device (CLT) to access an application (APP) according to any one of claims 3 to 5, in which a said processing module is a display server (s_disp) configured to obtain at least one display event (ev_disp) generated by said application (APP) and intended for a screen (DISP) of said client device (CLT). 7. Device (DA) allowing a client device (CLT) to access an application (APP) according to claim 6, in which said device (DA) further comprises a module (s_dim) configured to adapt said message (MSG_CLT ) obtained from the display event (ev_disp) and intended for the screen (DISP) of the client device at a 'display parameter of said screen. 8. Device (DA) allowing a client device (CLT) to access an application (APP) according to claim 7, in which said module (s_dim) configured to adapt said message obtained from the display event (ev_disp) controls the execution of said application (APP). 9. Device (DA) allowing a client device (CLT) to access an application (APP) according to any one of claims 3 to 8, in which a said processing module is a configured sound server (s_snd) to obtain at least one sound type event (ev_snd) generated by said application (APP) and intended for a sound output device (SND) of said client device (CLT). 10. Device (DA) allowing a client device (CLT) to access an application (APP) according to any one of claims 3 to 9, in which a said processing module is a print server (s_prn) configured to obtain at least one print event (ev_prn) generated by said application (APP) and intended for a printer (PRN) connected to said client device (CLT). 11. Device (DA) allowing a client device (CLT) to access an application (APP) according to any one of claims 3 to 10, in which said device (DA) further comprises a configured module (MOD_f) to transfer at least one file from said client device (CLT) to or from a storage space (Str). 12. System (SA) allowing a client device (CLT) to access an application (APP), said system comprising: - a device (DA) allowing a client device (CLT) to access an application (APP) according to one of claims 3 to 11; and - a server device (SRV) comprising a management module (MGC) capable of managing: o an interface container (C_IF) executed by said device allowing access to an application, and o at least one container (C „APP) of an application (APP) accessible by said client device (CLT) and configured for generate events (ev_disp, ev_snd, ev_prn) intended for output devices (DISP, KB, PRN) of said client device (CLT). 13. System (SA) to a client device (CLT) to access an application (APP) according to claim 12 characterized in that said server device (SRV) comprises: - an authentication module (AUTH) (C101, S102, S103) of a user of said client device (CLT); and - a module (CR_C_IF) configured to create (S104) said interface container (C_IF) upon authentication of said user. 14. Computer program (Prog) comprising instructions for the execution of the steps of a method for a client device (CLT) to access an application (APP) according to one of claims 1 or 2, when said program is executed by a computer (DA). 15. Computer-readable recording medium (DA) on which a computer program (Prog) is recorded comprising instructions for the execution of the steps of a method to a client device (CLT) to access a application (APP) according to one of claims 1 or 2.