EP2606427A1 - Entité générique de communication à haute vitesse entre composants ccm - Google Patents

Entité générique de communication à haute vitesse entre composants ccm

Info

Publication number
EP2606427A1
EP2606427A1 EP11758513.3A EP11758513A EP2606427A1 EP 2606427 A1 EP2606427 A1 EP 2606427A1 EP 11758513 A EP11758513 A EP 11758513A EP 2606427 A1 EP2606427 A1 EP 2606427A1
Authority
EP
European Patent Office
Prior art keywords
fragment
communication
component
receiver
data
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.)
Withdrawn
Application number
EP11758513.3A
Other languages
German (de)
English (en)
Inventor
Olivier Hachet
Jérôme CHAUVIN
Grégory HAIK
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.)
Thales SA
Original Assignee
Thales 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 Thales SA filed Critical Thales SA
Publication of EP2606427A1 publication Critical patent/EP2606427A1/fr
Withdrawn legal-status Critical Current

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/10—Protocols in which an application is distributed across nodes in the network
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/54—Interprogram communication
    • G06F9/544—Buffers; Shared memory; Pipes

Definitions

  • the subject of the invention is that of communication between two software components respecting the CCM standard.
  • CCM CORBA Component Model
  • OMG Object Management Group
  • a component is a design, implementation, deployment, and execution entity, having an envelope portion, for interfacing, in predefined interaction modes, that entity with other entities within the entity. application, and a portion of business code, encapsulated within the envelope and to specify the particular treatment that performs this software entity.
  • CORBA Common Object Request Broker Architecture
  • ORB for Object Request Broker
  • GIOP General Inter-ORB Protocol
  • An ORB is a software entity of the CORBA middleware able to transform (“serialize") the structure of a data item being processed on a first platform, into a sequence of bytes suitable for being transmitted on the network to a second platform, on which the data, after having undergone the inverse transformation by another ORB, will finish being processed.
  • the CCM standard defines synchronous and asynchronous modes of communication between two components.
  • a first component sending an initial data to a second receiving component suspends the execution of its business code until the second component has returned a response message adapted.
  • This response message may for example comprise an acknowledgment-receipt data of the initial data or a data resulting from a processing of the initial data performed by the second component.
  • a first component sending an initial data to a second receiving component resumes the execution of its business code as soon as the initial data is sent, without waiting for a response message from the second receiver component.
  • Light Weight CORBA Component Model is a subset of the CCM standard that has been defined to meet the special needs of software applications intended to be run on embedded systems. Such a software application must meet strong constraints in terms of size in the memory space and consumption of the computing capabilities (CPU) of the embedded system. It must also lead to low energy consumption.
  • Real time means in the following operation of the application in a characteristic time less than a clean time of the system.
  • a characteristic time less than a clean time of the system.
  • the LwCCM standard does not provide them. necessary means of communication. In addition, it does not allow the exchange of data of varied nature: audio stream, video stream, radio stream, etc.
  • the invention therefore aims to overcome the aforementioned problem by allowing, while remaining in the LwCCM standard, to offer the possibility to developers of real-time embedded applications of a high-speed communication between components.
  • the subject of the invention is a generic entity for high-speed communication between an emitting component and at least one receiving component as defined by claim 1 and its dependent claims.
  • the subject of the invention is also an information recording medium comprising the instructions for the instantiation on a computer installation of an entity of the type presented above, when these instructions are executed by the calculation unit of a computer.
  • the invention also relates to a computer installation comprising at least one platform and at least one instantiation of an entity of the type presented above for high speed communication between an instantiation, on a first platform, of a transmitter component. and at least an instantiation, on a second platform, of a Receiver Component, these components complying with the CORBA Component Model, version 1 .0 standard and the first and second platforms can be either confused or remote and connected to each other. another by a network.
  • the invention also relates to a high-speed communication method between a transmitting component and at least one receiving component, these components respecting the CORBA Component Model, version 1 .0, comprising the steps consisting of:
  • FIG. 1 is a representation in the sense of the standard CCM connector according to the invention for direct communication between two components; and, FIG. 2 is a schematic block diagram of the business code of the connector of FIG. 1.
  • the invention consists of a connector, in the sense of the DDS4LwCCM standard, serving as an interface between an output port of a transmitting component and an input port of a receiving component.
  • the envelope portion of the connector is shown schematically in FIG. 1, while the connector's business code portion is shown in FIG.
  • Connector 10 provides data communication from Transmitter Component 12 to a Receiver Component 14.
  • the transmitter component has an output port 13.
  • the receiving component has an input port 15.
  • the connector is fragmented. It comprises a first emitting fragment and a second receiving fragment.
  • the transmitting fragment includes an input port 23 intended to be connected to the
  • the receiver fragment has an output port 25 for connection to the input port 15 of the receiving component.
  • the transmitter fragment 22 constitutes a service, within the meaning of the DDS4LwCCM standard, of the output port 13 transmitting component.
  • the sending fragment and the sending component are instantiated together on the same platform. This is schematically represented in FIG. 1 by the rectangle 32 encompassing in the same software entity the emitting component and the emitting fragment.
  • the Receiver Fragment is a service, as defined by the DDS4LwCCM standard, associated with the Receiver Component Port.
  • the data exchange is carried out directly by a synchronous method call, the connector managing the mechanism able to make the connection asynchronous.
  • the CORBA middleware is not used.
  • the emitter and receiver fragments communicate directly with each other (arrow F in FIG. 1). This communication is completely transparent from the point of view of the transmitter and receiver components.
  • the transmitter fragment 22 comprises transmission means comprising:
  • acquisition means 52 capable of collecting data published on the input port 23 of the sending fragment, and transmitting it to one of the communication means;
  • a TCP communication means 56 able to receive data from the acquisition means 52 and to transmit it on a NETWORK2 network, in accordance with the TCP protocol;
  • a means of communication in local mode 58 able to receive data from the acquisition means 52 and to publish it by call to a writing means 59;
  • a write means 59 able to reserve, on request of the acquisition means 52, a shared memory space in the buffer 60 of a memory of the platform on which the transmitter fragment is deployed, and to write data thereto; which is transmitted to it by the means of communication in local mode 58.
  • the receiving fragment comprises:
  • a combined UDP communication means 74 able to receive UDP data received on a predetermined channel, and to publish it on the output port 25 of the receiver fragment;
  • a combined means of TCP communication 76 able to receive TCP data received on a predetermined channel, and to publish it on the output port 25 of the receiver fragment;
  • reading means 79 capable of reading data placed in shared memory space of buffer 60, and transmitting this data to means of communication in local mode 78.
  • the connector 10 extends the CCM standard by offering a generic semantics for the exchange of data at high speed between the components. transmitter and receiver.
  • the connector is configured when deploying the application. It is configured according to the deployment plan, but also by means of a configuration file such as file 80 in ".xml" format.
  • the sender and receiver fragments When starting the application, the sender and receiver fragments will automatically detect if they are instantiated on the same platform of the computer installation or on two different platforms. If yes, the mode of communication in local mode is selected. Otherwise, the remote communication mode is selected.
  • This automatic detection is performed as follows in an implementation of the entity 1 to 1.
  • Each fragment retrieves the IP address, machine name, and / or equivalent information from the platform on which it is implemented. Then, the two fragments exchange their respective information to determine if this information is identical or different, that is to say if the two fragments are located on the same platform or on two different platforms.
  • the configuration file 80 comprises a quality of service parameter for the selection of the communication protocol in remote mode: either the TCP mode if the developer wants reliable communication, or the UDP mode if he favors the communication speed.
  • the TCP protocol implements methods of verification of the integrity of the data transmission which increase the quality of the communication, but slow down the speed of this one.
  • the buffer 60 is of the FIFO type (for "First In First Out").
  • the buffer 60 is common to the sending fragment and the receiving fragment.
  • the buffer 60 must be located in a shared memory of the platform on which the receiver and transmitter fragments are deployed. This makes it possible to avoid a copy of the contents of a write buffer associated with the sender fragment, in a read buffer associated with the receiver fragment. As a result, copy errors are avoided and, in the case of a 1-to-N connector, with 1 sender fragment and N receiver fragments, this avoids N copies of the write buffer.
  • the sending fragment 22 and the receiving fragment 24 are instantiated, using the information contained in the deployment plan and the configuration file 80, and, in particular, the selection of the communication protocol (mode and quality of service).
  • the acquisition means 52 acquires new data published on the input port 23 of the sender fragment. It calls the writing means 59 so that it reserves a memory space in the data exchange buffer 60. As soon as a memory space is reserved, the writing means 59 returns an acknowledgment message to the acquisition means 52.
  • the acquisition means 52 transmits the data to the communication means in local mode 58.
  • the communication means in local mode 58 Upon receipt of the data, the communication means in local mode 58 transmits it to the writing means 58.
  • the writing means Upon receipt of this data, the writing means initiates the execution of a method of writing the data in the previously reserved memory space.
  • the reading means 79 successively traverses the different memory spaces of the buffer 60. It accesses a memory space and reads the data contained therein.
  • the reading means 79 transmits to the data read by the local mode communication means 78 of the receiver fragment.
  • the local mode communication means 78 publishes it on the output port 25 of the receiver fragment.
  • the sending fragment 22 and the receiving fragment 24 are instantiated, using the information contained in the configuration file 80, and in particular the selection of the protocol, for example TCP, for the exchange of data on the NETWORK 2 network.
  • the protocol for example TCP
  • the acquisition means 52 acquires new data published on the input port 23 of the sender fragment.
  • the acquisition means 52 transmits the data by means of TCP 56 communication.
  • the TCP communication means 56 Upon receipt of the data, the TCP communication means 56 serializes the data and transmits it over the network.
  • the TCP communication conjugate means 76 scans a predetermined channel and upon receipt of a data item, it performs the reverse transformation of the serialization.
  • the combined TCP communication means 76 publishes the data thus obtained on the output port 25 of the receiving fragment.
  • the connector comprises 1 sending fragment and N receiving fragments for a communication 1 towards N.
  • the applicant has managed, in a video image processing application, to perform video data exchange between connectors at a rate of 160 megabytes per second in local mode, at 50 megabytes. per second in UDP mode, and 30 megabytes per second in TCP mode, and this by consuming about 10% of the CPU.
  • the present solution optimizes the use of hardware resources by managing the flow of data directly within the business code of the connector.
  • the CORBA notification service prohibits data sharing between sending and receiving components via shared memory. It does not offer the possibility of choosing the quality of service.
  • CCM_sink_impl push (FastEvents :: Ev_TrackReader_ptr trackReader) ⁇

Landscapes

  • Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Communication Control (AREA)
  • Computer And Data Communications (AREA)

Abstract

Entité générique de communication à haute vitesse entre composants CCM L'entité de communication à haute vitesse entre des Composants émetteur (12) et récepteur (14) au standard CORBA Component Model comporte un connecteur au standard DDS4Lw CCM ayant : - un Fragment émetteur (22) comportant un Port d'entrée (23) connecté à un Port de sortie (13) du composant émetteur; - un Fragment récepteur (24) comportant un Port de sortie (25) connecté à un Port d'entrée (15) du composant récepteur; - le Fragment émetteur comportant un code métier comportant des moyens d'émission d'une donnée publiée sur le Port d'entrée du Fragment émetteur, à destination du Fragment récepteur; et, - le Fragment récepteur comportant un code métier comportant des moyens de réception de la donnée émise par les moyens d'émission du Fragment émetteur, pour la publication de cette donnée sur le Port de sortie du Fragment récepteur.

Description

Entité générique de communication à haute vitesse entre composants CCM
L'invention a pour domaine celui de la communication entre deux composants logiciels respectant le standard CCM.
Le standard CCM (CORBA Component Model), maintenu par l'OMG (Object Management Group), est une approche de développement d'applications logicielles par assemblage d'entités élémentaires. Ce standard regroupe ainsi la notion de composants logiciels et celle de communication selon le standard CORBA entre deux tels composants.
Un composant est une entité de conception, d'implémentation, de déploiement et d'exécution, comportant une partie d'enveloppe, permettant d'interfacer, selon des modes d'interaction prédéfinis, cette entité avec d'autres entités au sein de l'application, et une partie de code métier, encapsulée à l'intérieur de l'enveloppe et permettant de spécifier le traitement particulier qu'effectue cette entité logicielle.
CORBA (Common Object Request Broker Architecture) est un middleware de communication entre composants, qui permet une gestion transparente de la communication entre deux composants de l'application, et ceci quel que soit le plan déploiement de l'application, c'est-à-dire la manière d'implanter les différentes entités composant l'application sur plusieurs plateformes reliées entre elles par un réseau de manière à constituer une installation informatique. Ainsi, lorsque le plan de déploiement conduit à ce que deux composants devant échanger des données soient exécutés sur deux plateformes différentes, le middleware CORBA gère tous les aspects de la communication sur le réseau reliant ces plateformes.
Dans le cas des interactions de type asynchrone (« events »), cette gestion s'effectue par l'appel au service de notification CosNotification de CORBA. Celui-ci impose l'implémentation du protocole GIOP (pour General Inter-ORB Protocol). Un ORB (pour Object Request Broker) est une entité logicielle du middleware CORBA apte à transformer (« sérialiser ») la structure d'une donnée en cours de traitement sur une première plateforme, en une séquence d'octets propre à être transmise sur le réseau vers une seconde plateforme, sur laquelle la donnée, après avoir subi la transformation inverse par un autre ORB, finira d'être traitée.
Le standard CCM définit des modes synchrones et asynchrones de communications entre deux composants.
En mode synchrone, un premier composant émetteur d'une donnée initiale à destination d'un second composant récepteur, suspend l'exécution de son code métier tant que le second composant ne lui a pas renvoyé un message de réponse adapté. Ce message de réponse peut par exemple comporter une donnée d'accuser-réception de la donnée initiale ou encore une donnée résultant d'un traitement de la donnée initiale effectué par le second composant.
En mode asynchrone, un premier composant émetteur d'une donnée initiale à destination d'un second composant récepteur, reprend l'exécution de son code métier dès l'émission de la donnée initiale, sans attendre de message de réponse de la part du second composant récepteur.
Le standard LwCCM (Light weight CORBA Component Model) est un sous- ensemble du standard CCM qui a été défini pour répondre aux besoins particuliers des applications logicielles destinées à être exécutées sur des systèmes embarqués. Une telle application logicielle doit respecter des contraintes fortes en termes de taille dans l'espace mémoire et de consommation des capacités de calcul (CPU) du système embarqué. Elle doit également conduire à une faible consommation énergétique.
En outre, les applications logicielles destinées aux systèmes embarqués ont souvent pour fonction d'effectuer des prétraitements sur des données acquises, ces prétraitements devant être réalisés en temps réel.
Par temps réel, on entend dans ce qui suit un fonctionnement de l'application dans un temps caractéristique inférieur à un temps propre du système. Par exemple, dans le cas du prétraitement d'une image vidéo haute définition obtenue en sortie d'une caméra fonctionnant à 24 images par seconde, il faut que le prétraitement effectué sur chaque image par l'application logicielle s'effectue en moins de 20 ms. En conséquence, au sein de l'application logicielle, chaque traitement effectué par un composant de l'application, ainsi que la communication entre deux composants de cette application doivent également s'effectuer en moins de 20 ms.
Or, il a été constaté que le Middleware CORBA ne permet pas de réaliser des applications fonctionnant en temps réel, car l'échange de données entre deux composants, fondé sur le service de notification de CORBA, est peu performant et consomme une partie relativement importante du CPU. De ce fait, le temps nécessaire pour effectuer un échange de données entre composants n'est pas négligeable par rapport à un temps propre du système.
Cette lenteur relative des communications entre deux composants est accentuée lorsque la quantité ou la nature des données à échanger entre composants génère un flux important. Par exemple, pour le prétraitement d'une image vidéo haute définition, un flux de données d'environ 50 Mégaoctets doit pouvoir être échangé entre deux composants.
Ainsi, alors que les applications embarquées temps réel ont un besoin de communications asynchrones haute vitesse, le standard LwCCM ne fournit par les moyens de communication nécessaires. De plus, il ne permet pas l'échange de données de nature variée : flux audio, flux vidéo, flux radio, etc.
L'invention a donc pour but de palier au problème précité en permettant, tout en restant dans le standard LwCCM, d'offrir la possibilité aux développeurs des applications embarquées temps réel d'une communication haute vitesse entre composants.
A cet effet, l'invention a pour objet une entité générique de communication à haute vitesse entre un Composant émetteur et au moins un Composant récepteur telle que définie par la revendication 1 et ses revendications dépendantes.
L'invention a également pour objet un support d'enregistrement d'informations comportant les instructions pour l'instanciation sur une installation informatique d'une entité du type de celle présentée précédemment, lorsque ces instructions sont exécutées par l'unité de calcul d'un ordinateur.
L'invention a également pour objet une installation informatique comportant au moins une plateforme et au moins une instanciation d'une entité du type de celle présentée précédemment pour la communication à haute vitesse entre une instanciation, sur une première plateforme, d'un Composant émetteur et au moins une instanciation, sur une seconde plateforme, d'un Composant récepteur, ces composants respectant le standard CORBA Component Model, version 1 .0 et les première et seconde plateformes pouvant être soit confondues, soit distantes et connectées l'une à l'autre par un réseau.
L'invention a également pour objet un procédé de communication à haute vitesse entre un Composant émetteur et au moins un Composant récepteur, ces composants respectant le standard CORBA Component Model, version 1 .0, comportant les étapes consistant en :
- l'instanciation d'une entité du type de celle présentée précédemment ;
- l'acquisition par l'entité d'une donné publiée par le Composant émetteur sur le port d'entrée du Fragment émetteur de l'entité ;
- la communication de la donnée acquise entre les Fragments émetteur et récepteur de l'entité ; et,
- la publication de la donnée sur le Port d'entrée du Composant récepteur via le Port de sortie du Fragment récepteur.
L'invention et ses avantages seront mieux compris à la lecture de la description qui va suivre, donnée uniquement à titre d'exemple, et faite en se référant aux dessins annexés sur lesquels :
- la figure 1 est une représentation au sens du standard CCM du connecteur selon l'invention pour la communication directe entre deux composants ; et, - la figure 2 est une représentation schématique sous forme de blocs du code métier du connecteur de la figure 1 .
La présente description se fonde sur les versions des standards les plus à jour à la date de dépôt de la présente demande de brevet, à savoir CORBA Component Model V4.0, plus particulièrement le document « Formal/06-04-01 », ainsi que les deux standards suivants permettant d'étendre le standard CCM : DDS4LwCCM, V1 .0 betal , plus particulièrement le document « PTC/2009-02-02 ». Ces documents sont en libre accès sur le site de l'OMG à l'adresse www.omq.org.
L'invention consiste en un Connecteur, au sens du standard DDS4LwCCM, servant d'interface entre un Port de sortie d'un Composant émetteur et un Port d'entrée d'un Composant récepteur.
La partie d'enveloppe du Connecteur est représentée schématiquement à la figure 1 , tandis que la partie de code métier du Connecteur est représentée à la figure 2.
En se référant à la figure 1 , le Connecteur 10 assure la communication de données émises par un Composant émetteur 12, vers un Composant récepteur 14.
Le Composant émetteur comporte un Port de sortie 13.
De manière similaire le Composant récepteur comporte un Port d'entrée 15.
Le Connecteur est fragmenté. Il comporte un premier Fragment émetteur et un second fragment récepteur.
Le Fragment émetteur comporte un Port d'entrée 23 destiné à être connecté au
Port de sortie 13 du Composant émetteur. De manière similaire, le Fragment récepteur comporte un Port de sortie 25 destiné à être connecté au Port d'entrée 15 du Composant récepteur.
Le Fragment émetteur 22 constitue un service, au sens du standard DDS4LwCCM, du Port de sortie 13 Composant émetteur. Lors du déploiement de l'application, le Fragment émetteur et le Composant émetteur sont instanciés, ensemble, sur une même plateforme. C'est ce qui est représenté schématiquement sur la figure 1 par le rectangle 32 englobant dans une même entité logicielle le Composant émetteur et le Fragment émetteur.
De manière similaire, le Fragment récepteur constitue un service, au sens du standard DDS4LwCCM, associé au Port d'entrée du Composant récepteur.
Il est à noter qu'entre le Port d'un Composant et le Port correspondant d'un Fragment, l'échange de données s'effectue directement par un appel de méthode synchrone, le connecteur gérant le mécanisme apte à rendre la connexion asynchrone. Le middleware CORBA n'est pas utilisé. Les Fragments émetteur et récepteur communiquent directement entre eux (flèche F sur la figure 1 ). Cette communication est totalement transparente du point de vue des Composants émetteur et récepteur.
En se référant maintenant à la figure 2, la partie de code métier du connecteur permettant de réaliser la communication directe F va être décrite.
Le fragment émetteur 22 comporte des moyens d'émission comportant :
- un moyen d'acquisition 52, propre à collecter une donnée publiée sur le port d'entrée 23 du fragment émetteur, et à la transmettre à l'un des moyens de communication ;
- un moyen de communication UDP 54, apte à recevoir une donnée du moyen d'acquisition 52 et à l'émettre sur un réseau NETWORK"! , conformément au protocole UDP ;
- un moyen de communication TCP 56, apte à recevoir une donnée du moyen d'acquisition 52 et à l'émettre sur un réseau NETWORK2, conformément au protocole TCP ;
- un moyen de communication en mode local 58, apte à recevoir une donnée du moyen d'acquisition 52 et à la publier par appel à un moyen d'écriture 59 ;
- un moyen d'écriture 59, propre à réserver, sur requête du moyen d'acquisition 52, un espace mémoire partagé dans le buffer 60 d'une mémoire de la plateforme sur laquelle est déployé le fragment émetteur, et à y écrire une donnée qui lui est transmise par le moyen de communication en mode local 58.
Quant à lui, le fragment récepteur comporte :
- un moyen conjugué de communication UDP 74, apte à recevoir une donnée UDP reçue sur un canal prédéterminé, et à la publier sur le port de sortie 25 du fragment récepteur ;
- un moyen conjugué de communication TCP 76, apte à recevoir une donnée TCP reçue sur un canal prédéterminé, et à la publier sur le port de sortie 25 du fragment récepteur ;
- un moyen conjugué de communication en mode local 78, apte à publier sur le port de sortie 25 du fragment récepteur, une données qui lui est transmise par un moyen de lecture 79 ;
- un moyen de lecture 79, propre à lire une donnée placée dans un espace mémoire partagée du buffer 60, et à transmettre cette donnée vers le moyen de communication en mode local 78.
Le connecteur 10 selon l'invention étend le standard CCM en offrant une sémantique générique pour l'échange de donnée à haute vitesse entre les composants émetteur et récepteur. Le connecteur est configuré lors du déploiement de l'application. Il est configuré en fonction du plan de déploiement, mais également au moyen d'un fichier de configuration tel que le fichier 80 au format « .xml ».
Lors du démarrage de l'application, les fragments émetteur et récepteur vont automatiquement détecter s'ils sont instanciés sur une même plateforme de l'installation informatique ou sur deux plateformes différentes. Dans l'affirmative, le mode de communication en mode local est sélectionné. A défaut, le mode de communication à distance est sélectionné.
Cette détection automatique s'effectue de la manière suivante dans une implémentation de l'entité 1 vers 1 . Chaque Fragment récupère les informations d'adresse IP, de nom de machine, et/ou l'équivalent, de la plateforme sur laquelle il est implémenté. Puis, les deux fragments échangent leurs informations respectives pour déterminer si ces informations sont identiques ou différentes, c'est-à-dire si les deux fragments sont implantés sur la même plateforme ou sur deux plateformes différentes.
Le fichier de configuration 80 comporte par exemple un paramètre de qualité de service pour la sélection du protocole de communication en mode distant : soit le mode TCP si le développeur souhaite une communication fiable, soit le mode UDP s'il privilégie la vitesse de communication. En effet, le protocole TCP met en œuvre des méthodes de vérification de l'intégrité de la transmission de donnée qui augmentent la qualité de la communication, mais ralentissent la vitesse de celle-ci.
Le buffer 60 est du type FIFO (pour « First In First Out »). Dans le présent mode de réalisation, le buffer 60 est commun au fragment émetteur et au fragment récepteur. Le buffer 60 doit pour cela être situé dans une mémoire partagée de la plateforme sur laquelle sont déployés les fragments récepteur et émetteur. Ceci permet d'éviter une copie du contenu d'un buffer d'écriture associé au fragment émetteur, dans un buffer de lecture associé au fragment récepteur. De ce fait, les erreurs de copie sont évitées et, dans le cas d'un connecteur 1 vers N, comportant 1 fragment émetteur et N fragments récepteurs, cela évite N copies du buffer d'écriture.
La communication en mode local s'effectue de la manière suivante.
Le fragment émetteur 22 et le fragment récepteur 24 sont instanciés, en utilisant les informations contenues dans le plan de déploiement et le fichier de configuration 80, et, en particulier, la sélection du protocole de communication (mode et qualité de service).
Le moyen d'acquisition 52 acquiert une nouvelle donnée publiée sur le Port d'entrée 23 du fragment émetteur. Il appelle le moyen d'écriture 59 afin que celui-ci réserve un espace mémoire dans le buffer 60 d'échange de données. Dès qu'un espace mémoire est réservé, le moyen d'écriture 59 renvoie un message d'acquittement au moyen d'acquisition 52.
Sur ce, le moyen d'acquisition 52 transmet la donnée au moyen de communication en mode local 58.
Dès réception de la donnée, le moyen de communication en mode local 58 la transmet au moyen d'écriture 58.
Lors de la réception de cette donnée, le moyen d'écriture lance l'exécution d'une méthode d'écriture de la donnée dans l'espace mémoire précédemment réservé.
Du côté du fragment récepteur 24, le moyen de lecture 79 parcourt successivement les différents espaces mémoire du buffer 60. Il accède à un espace mémoire et lit la donnée qui y est contenue.
Le moyen de lecture 79 transmet à la donnée lue au moyen conjugué de communication en mode local 78 du fragment récepteur.
Dès réception de la donnée, le moyen de communication conjugué en mode local 78 la publie sur le Port de sortie 25 du fragment récepteur.
Alors que fragment récepteur et fragment(s) récepteur sont instanciés sur des plateformes différentes, reliées entre elles par un réseau, la communication en mode distant s'effectue de la manière suivante :
Le fragment émetteur 22 et le fragment récepteur 24 sont instanciés, en utilisant les informations contenues dans le fichier de configuration 80, et, en particulier la sélection du protocole, par exemple TCP, pour l'échange de données sur le réseau NETWORK 2.
Le moyen d'acquisition 52 acquiert une nouvelle donnée publiée sur le Port d'entrée 23 du fragment émetteur. Le moyen d'acquisition 52 transmet la donnée au moyen de communication TCP 56.
Dès réception de la donnée, le moyen de communication TCP 56 sérialise la données et la transmet sur le réseau.
Du côté du fragment récepteur 24, le moyen conjugué de communication TCP 76 scrute un canal prédéterminé et dès réception d'une donnée, il réalise la transformation inverse de la sérialisation. Le moyen conjugué de communication TCP 76 publie la donnée ainsi obtenue sur le Port de sortie 25 du fragment récepteur.
Alors que le mode de réalisation qui vient d'être décrit permet une communication 1 vers 1 entre un fragment émetteur et un fragment récepteur, en variante, le connecteur comporte 1 fragment émetteur et N fragments récepteurs pour une communication 1 vers N. En mettant en œuvre une implémentation du présent connecteur générique, la demanderesse est parvenue, dans une application de traitement d'image vidéo, à réaliser des échanges de données vidéo entre connecteurs à un débit de 160 mégaoctets par seconde en mode local, à 50 mégaoctets par seconde en mode UDP, et à 30 mégaoctets par seconde en mode TCP, et ceci en consommant environ 10% du CPU.
La présente solution permet d'optimiser l'usage des ressources matérielles en gérant le flux de données directement à l'intérieur du code métier du connecteur.
Ceci permet d'éviter d'avoir recours au service de notification de CORBA qui impose l'implémentation du protocole GIOP. Au contraire, selon l'invention, les données sont sérialisées uniquement lorsque cela s'avère être nécessaire, c'est-à-dire dans le mode distant.
De plus, le service de notification de CORBA interdit le partage de données entre composant émetteur et composant récepteur via une mémoire partagée. Il n'offre pas la possibilité du choix de la qualité de service.
Par ailleurs, le fait de coder des moyens de communication haute vitesse dans un connecteur plutôt que dans un composant permet d'introduire dans le standard LwCCM une entité générique configurable présentant une interface respectant le standard IDL3 (pour « Interface Description Language », Version 3)
Dans l'annexe, est reproduit le code de spécification de l'interface du Connecteur logiciel de l'invention.
Ainsi, le code applicatif reste lisible et sa complexité n'augment pas. Il est facile à tester et à maintenir.
ANNEXE
Implémentation d'un connecteur de communication dénommé "Fast Events" :
Interface du connecteur « Fast Events » :
// FastEventsSource
local interface FastEventsSourceIntktypename T>
{
FastEvents$T$Writer reserve();
void push(in FastEvents$T$Writer writer);
void delete(in FastEvents$T$Writer writer);
};
port_type FastEventsSourcePorktypename T>
{
uses FastEventsSourcelntf<T> none;
};
// FastEventsSink
local interface FastEventsSinklntktypename T>
{
void push(in FastEvents$T$Reader reader);
};
port_type FastEventsSinkPorktypename T>
{
provides FastEventsSinklntkT> none;
};
Exemple d'utilisation :
//Définition du type échangé
eventtype Ev Track
{
public long id;
public long date;
};
Composant émetteur :
component subject
{
port FastEventsSourcePorkEv_Track> tracks_out;
};
Composant récepteur :
component sink
{
port FastEventsSinkPorkEv_Track> tracks_in;
};
Connecteur FastEvent :
connector FastEventCnx
{ mirrorport FastEventsSourcePort<Ev_Track> datajn;
mirrorport FastEventsSinkPort<Ev_Track> data_out;
};
Code généré pour le marshaller « Fast Events » :
module FastEvents
{
local interface Ev TrackWriter
{
void id (in long value);
void date (in long value);
};
};
Code généré pour le de-marshaller « Fast Events » :
module FastEvents
{
local interface Ev TrackReader
{
long id ();
long date ();
};
};
Code généré pour le composant émetteur :
local interface Ev Track FastEventsSourcelntf
{
:: FastEvents ::Ev_TrackWriter reserve ();
void push (in :: FastEvents :: Ev TrackWriter writer);
void delete (in :: FastEvents ::Ev_TrackWriter writer);
};
component subject
{
uses ::Ev_Track_FastEventsSourcelntf tracks_out_src;
};
Code généré pour le composant récepteur :
local interface Ev Track FastEventsSinklntf
{
void push (in :: FastEvents ::Ev_TrackReader reader);
};
component sink
{
provides ::Ev_Track_FastEventsSinklntf tracksj'n snk;
};
Code du composant émetteur :
//appel sur le contexte du composant pour avoir le réceptacle
CCM_subject_Context_ptr source = context->get_connection_tracks_out_src();
//récupération d'une instance de marshaller
FastEvents::ISP::Ev_TrackWriter_ptr track ref = source->reserve();
// Remplissage des valeurs track_ref->id(track_infos_.id);
track_ref->date(track_infos_.date);
//Envoi de l'événement
source->push(track_ref);
//Libération du marshaller
context->delete_Ev_TrackWriter(track_ref);
Code du composant récepteur :
//Implementation de la réception
void
CCM_sink_impl::push(FastEvents::Ev_TrackReader_ptr trackReader) {
long id = trackReader->id();
long date = trackReader->date();
}

Claims

REVENDICATIONS
1 . - Entité générique de communication à haute vitesse entre un Composant émetteur (12) et au moins un composant récepteur (14), lesdits composants respectant le standard CORBA Component Model, version 1 .0, caractérisée en ce qu'il comporte un connecteur au sens du standard DDS4LwCCM, version 1 .0 Betal , comprenant :
- un Fragment émetteur (22) comportant une partie d'enveloppe comportant un Port d'entrée (23) destiné à être connecté à un Port de sortie (13) du composant émetteur ;
- au moins un Fragment récepteur (24) comportant une partie d'enveloppe comportant un Port de sortie (25) destiné à être connecté à un Port d'entrée (15) dudit au moins un composant récepteur ;
- ledit Fragment émetteur comportant une partie de code métier comportant des moyens d'émission (52, 54, 56, 58, 59) d'une donnée publiée sur le Port d'entrée de la partie d'enveloppe dudit Fragment émetteur, à destination dudit au moins un Fragment récepteur ; et,
- ledit Fragment récepteur comportant une partie de code métier comportant des moyens de réception (74, 76, 78, 79) de la donnée émise par les moyens d'émission du Fragment émetteur, pour la publication de ladite donnée sur le Port de sortie de la partie d'enveloppe dudit Fragment récepteur.
2. - Entité selon la revendication 1 , caractérisée en ce que le Port d'entrée (23) dudit Fragment émetteur et le Port de sortie (25) dudit au moins un Fragment récepteur sont du type synchrone.
3. - Entité selon la revendication 1 ou la revendication 2, caractérisée en ce que les moyens d'émission du Fragment émetteur comportent un moyen de communication en mode local (58), et en ce que les moyens de réception du Fragment récepteur comportent un moyen conjugué de communication en mode local (78).
4. - Entité selon la revendication 1 ou la revendication 2, caractérisée en ce que les moyens d'émission du Fragment émetteur comportent au moins un moyen de communication en mode distant (54, 56), et en ce que les moyens de réception du Fragment récepteur comportent au moins un moyen conjugué de communication en mode distant (74, 76).
5. - Entité selon la revendication 3 et la revendication 4 en combinaison, caractérisée en ce que les moyens d'émission comportent un moyen d'acquisition (52) propre à acquérir une donnée publiée sur le Port d'entré (23) du Fragment émetteur et à la transmettre soit au moyen de communication en mode local (58) soit au moyen de communication en mode distant (54, 56).
6. - Entité selon la revendication 4 ou la revendication 5, caractérisée en ce que les moyens d'émission comportent un moyen de communication TCP (56) et un moyen de communication UDP (54), et en ce que les moyens de réception comportent un moyen conjugué de communication TCP (76) et un moyen conjugué de communication UDP (78), l'entité comportant, en outre, un fichier de configuration (80) comportant un paramètre de sélection du protocole de communication à utiliser en mode distant.
7. - Entité selon l'une quelconque des revendications 4 à 6, caractérisée en ce que le ou chaque moyen de communication en mode distant (54, 56) est propre à effectuer une transformation de sérialisation de la donnée à transmettre, et en ce que le ou chaque moyen conjugué de communication en mode distant (74, 76) est propre à effectuer une transformation inverse sur la donnée reçue.
8.- Entité selon l'une quelconque des revendications 3 à 7, caractérisée en ce que les moyens d'émission comportent un moyen d'écriture (59) dans un buffer d'émission, propre à réserver un espace mémoire du buffer d'écriture et à écrire une donnée appliquée en entrée du moyen d'écriture par le moyen de communication en mode local (58), et les moyens de réception comportent un moyen de lecture (79) dans un buffer de réception propre à lire une donnée dans le buffer de réception et à l'appliquer en entrée du moyen conjugué de communication en mode local (78).
9. - Entité selon la revendication 8, caractérisée en ce que les moyens d'écriture et de lecture (59, 79) sont propres à utiliser un buffer (60) commun situé en mémoire partagée.
10. - Support d'enregistrement d'informations, caractérisé en ce qu'il comporte les instructions pour l'instanciation sur une installation informatique d'une entité conforme à l'une quelconque des revendications 1 à 9, lorsque ces instructions sont exécutées par l'unité de calcul d'un ordinateur.
1 1 . - Installation informatique comportant au moins une plateforme, caractérisée en ce qu'elle comporte au moins une instanciation d'une entité conforme à l'une quelconque des revendications 1 à 9 pour la communication à haute vitesse entre une instanciation sur une première plateforme d'un Composant émetteur (12) et au moins une instanciation sur une seconde plateforme d'un Composant récepteur (14), lesdits composants respectant le standard CORBA Component Model, version 1 .0 et lesdites première et seconde plateformes pouvant être soit confondues, soit distantes et connectées l'une à l'autre par un réseau.
12. - Procédé de communication à haute vitesse entre un Composant émetteur (12) et au moins un Composant récepteur (14), lesdits composants respectant le standard CORBA Component Model, version 1 .0,
caractérisé en ce qu'il comporte les étapes consistant en :
- l'instanciation d'une entité selon l'une quelconque des revendications 1 à 9 ;
- l'acquisition par ladite entité d'une donné publiée par le Composant émetteur sur le port d'entrée du Fragment émetteur de ladite entité ;
- la communication de la donnée acquise entre les Fragments émetteur et récepteur de ladite entité ; et
- la publication de la donnée sur le Port d'entrée du Composant récepteur via le Port de sortie du Fragment récepteur.
EP11758513.3A 2010-08-17 2011-08-17 Entité générique de communication à haute vitesse entre composants ccm Withdrawn EP2606427A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR1003385A FR2963971B1 (fr) 2010-08-17 2010-08-17 Entite generique de communication a haute vitesse entre composants ccm
PCT/FR2011/051923 WO2012022916A1 (fr) 2010-08-17 2011-08-17 Entité générique de communication à haute vitesse entre composants ccm

Publications (1)

Publication Number Publication Date
EP2606427A1 true EP2606427A1 (fr) 2013-06-26

Family

ID=43881024

Family Applications (1)

Application Number Title Priority Date Filing Date
EP11758513.3A Withdrawn EP2606427A1 (fr) 2010-08-17 2011-08-17 Entité générique de communication à haute vitesse entre composants ccm

Country Status (5)

Country Link
US (1) US9264487B2 (fr)
EP (1) EP2606427A1 (fr)
CA (1) CA2808581C (fr)
FR (1) FR2963971B1 (fr)
WO (1) WO2012022916A1 (fr)

Family Cites Families (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
FR2938944B1 (fr) 2008-11-25 2011-09-30 Thales Sa Procede et systeme pour la transformation de composants logiciel ccm en composants deployables dans un environnement compatible du standard sca.

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
None *
See also references of WO2012022916A1 *

Also Published As

Publication number Publication date
WO2012022916A1 (fr) 2012-02-23
US9264487B2 (en) 2016-02-16
CA2808581A1 (fr) 2012-02-23
US20130219016A1 (en) 2013-08-22
FR2963971B1 (fr) 2012-08-31
CA2808581C (fr) 2019-09-03
FR2963971A1 (fr) 2012-02-24

Similar Documents

Publication Publication Date Title
CN111447170B (zh) 数据处理方法及其系统、计算机系统及计算机可读介质
EP2791798B1 (fr) Bus logiciel
FR2886494A1 (fr) Procede et dispositif d&#39;echange de donnees entre des stations mobiles dans un reseau pair a pair
EP2141591A1 (fr) Dispositif électronique portable comprenant une application portable et un module sécurisé pouvant comminique entre eux, et procédé de communication associé
WO2002001313A2 (fr) Procede de transmission d&#39;un agent mobile dans un reseau; emetteur, recepteur, et agent mobile associes
EP1422872B1 (fr) Procédé et dispositif modulaire de traçage d&#39;un message multimédia à travers un réseau de télécommunications
FR2828358A1 (fr) Procede et dispositif de mise en compatibilite de communication sur reseau de terminaux, par exemple pour permettre un dialogue avec une application sur une carte a puce
EP2124153B1 (fr) Procédés et dispositif de mise en oeuvre de périphériques multifonction avec un gestionnaire de périphérique standard unique
FR2860616A1 (fr) Unite de commande de dispositif de memorisation et procede de commande de celui-ci
CA2808581C (fr) Entite generique de communication a haute vitesse entre composants ccm
EP3135017A1 (fr) Procédés d&#39;échange de données avec un équipement comprenant des moyens de communication radio
WO2024083978A1 (fr) Procédé de traitement d&#39;une requête d&#39;exécution d&#39;un service dans un réseau de communication, procédé de validation de la requête, entité intermédiaire, entité de validation, système et programme d&#39;ordinateur correspondants
WO2016083734A1 (fr) Procede d&#39;envoi de courrier recommande electronique
EP1687719A1 (fr) Dispositif et procédé asynchrones et automatiques de transmission de résultats entre objets communicants
EP4213024A1 (fr) Procédé de partage d&#39;image, programme d&#39;ordinateur et système mettant en oeuvre un tel procédé
EP2525525B1 (fr) Procédé, programme d&#39;ordinateur et dispositif de cooptation permettant à un abonné d&#39;un service de partager ce service avec un autre utilisateur
KR100664757B1 (ko) Ｖｍｓ에서의 메시지 처리 장치 및 방법
FR3078850A1 (fr) Procede, dispositif et systeme permettant l&#39;acces a une application deployee dans un conteneur
FR2927711A1 (fr) Dispositif d&#39;echange de documents entre deux parties a travers un reseau
WO2006072692A1 (fr) Procede pour accomplir des fonctions cryptographiques dans une application informatique ecrite en langage a code mobile, et application informatique correspondante
FR2975554A1 (fr) Procede d&#39;adaptation d&#39;un contenu en fonction du recepteur du contenu
EP1018818A1 (fr) Architecture d&#39;agent pouvant coopérer avec des applications corba
EP2257019A1 (fr) Procédé de traitement de document par un ordinateur distant, système et dispositif amovible connectable à chaud pour la mise en oeuvre de ce procédé
FR2877114A1 (fr) Systeme et procede de gestion de messages dans un reseau de communication par messagerie electronique
FR3042362A1 (fr) Moyens de gestion d&#39;acces a des donnees

Legal Events

Date Code Title Description
PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

17P Request for examination filed

Effective date: 20130215

AK Designated contracting states

Kind code of ref document: A1

Designated state(s): AL AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HR HU IE IS IT LI LT LU LV MC MK MT NL NO PL PT RO RS SE SI SK SM TR

DAX Request for extension of the european patent (deleted)
RIN1 Information on inventor provided before grant (corrected)

Inventor name: HAIK, GREGORY

Inventor name: HACHET, OLIVIER

Inventor name: CHAUVIN, JEROME

17Q First examination report despatched

Effective date: 20190321

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE APPLICATION IS DEEMED TO BE WITHDRAWN

18D Application deemed to be withdrawn

Effective date: 20190801