Brevet FR2984554A1 — publié le 20130621

La présente invention concerne le domaine des procédés de communication entre modules logiciels et plus particulièrement des bus logiciels. Les dispositifs de traitement de l'information fonctionnent sous le contrôle d'un système d'exploitation. Ces systèmes d'exploitation sont multitâches et permettent d'ordonnancer une pluralité de modules logiciels. Ces modules logiciels peuvent être de plusieurs types en fonction de l'ordonnanceur (scheduler en anglais) qui organise le multitâche et des possibilités d'une hiérarchie de modules. Historiquement, les systèmes d'exploitation ont permis d'ordonnancer des processus. Un processus se définit comme un module logiciel disposant de son propre contrôle et de son propre espace mémoire. L'ordonnancement des processus est effectué typiquement aujourd'hui de manière préemptive. C'est-à-dire que l'ordonnanceur décide de manière arbitraire des moments de basculement de contexte entre les processus. Le contexte du processus courant, typiquement le contenu de caches mémoires, le contenu des registres du processeur et le pointeur d'instruction du contrôle, est alors sauvegardé. Un autre processus en attente est sélectionné, son contexte est restauré. Il peut alors continuer son exécution. Le basculement de contexte est un processus relativement lourd. Le besoin d'animer en parallèle des modules logiciels plus légers est apparu. On a donc créé la notion de processus légers (thread en anglais). Typiquement, un ensemble de processus légers est ordonnancé au sein d'un espace mémoire commun, il s'agit généralement d'un processus. Dans certains cas, on peut implémenter un niveau supplémentaire et ordonnancer un ensemble de tâches au sein même d'un processus léger. L'ordonnancement peut alors être préemptif ou non. L'autre famille d'ordonnancement, l'ordonnancement coopératif se faisant à l'occasion d'appels systèmes explicites où la tâche passe le contrôle explicitement à l'ordonnanceur. La différence principale tient au fait que, dans un tel ordonnancement, une tâche entrant dans une boucle infinie peut interdire au système de reprendre la main et bloquer le système complet. L'avantage étant que, une tâche ne pouvant se trouver interrompue à tout moment, il n'est pas nécessaire de protéger les ressources partagées par des mécanismes d'exclusion mutuelle (mutex en anglais). Nous considérons donc le logiciel exécuté sur un dispositif de traitement de l'information comme un ou plusieurs processus, chaque processus pouvant être lui-même constitué d'un ou plusieurs processus légers, chaque processus léger pouvant être constitué d'une ou plusieurs tâches. L'ordonnancement des processus et des processus légers sera considéré comme préemptif, celui des tâches pouvant être préemptif ou non. Nous utilisons le terme de module logiciel pour désigner l'ensemble de ces processus, processus légers et tâches de manière générique. Cette hiérarchie de modules logiciels est illustrée par la Fig. 1. On y voit un dispositif de traitement de l'information 1.1. Ce dispositif permet l'exécution en parallèle de trois processus 1.2, 1.3 et 1.4. Ces processus sont ordonnancés par le système d'exploitation 1.16. Le processus 1.2 contient plusieurs processus légers 1.5, 1.6, 1.7 et 1.8 exécutés en parallèle ordonnancés par le système d'exploitation 1.16. Le processus 1.3 ne contient pas de processus légers. Le processus 1.4 contient un premier processus léger 1.9 et un second processus léger 1.10. Ce second processus léger 1.10 contient lui-même plusieurs tâches 1.11, 1.12 et 1.13 exécutées en parallèle sous le contrôle d'un ordonnanceur 1.14 lui même exécuté au sein du processus léger 1.10. Le dispositif dispose au moins d'un port de communication 1.15 permettant la communication avec d'autres dispositifs via un réseau de communication, typiquement un réseau IP. Lorsque l'on cherche à faire communiquer des modules logiciels, on trouve dans l'art antérieur des solutions dédiées à un niveau de parallélisme donné. Les technologies principales étant dédiées à la communication entre processus. On peut citer les files d'attente de messages (message queue en anglais), les sockets UNIX pour une communication entre processus d'un même dispositif, les sockets INET pour la communication entre processus situés sur des dispositifs distants connectés à un réseau de type IP (Internet Protocol en anglais). Il existe aussi les tubes (pipe en anglais) nommés ou non. Il existe des bus logiciels, tels que le D-Bus qui est un système de communication entre processus. Il n'est pas adapté pour des modules logiciels tels que les simples tâches, ni pour les processus légers ni pour la communication entre machines. L'invention vise à proposer un système de communication ou bus logiciel qui permette la communication entre modules logiciels. Cette communication intervient au sein d'une machine et entre machines et fonctionne indifféremment pour le module logiciel qu'il s'agisse d'un processus, d'un processus léger ou d'une simple tâche. La communication repose sur des mécanismes adaptés au niveau de multitâche auquel fonctionnent les modules logiciels émetteurs et récepteurs. Il est basé sur une architecture hiérarchique, des phases de découvertes et d'enregistrement des différents modules logiciels devant communiquer auprès du bus. L'invention concerne un dispositif de traitement de l'information comportant un système d'exploitation ; au moins un processus ordonnancé par ledit système d'exploitation ; des processus légers pouvant être ordonnancés au sein desdits processus par ledit système d'exploitation ; des tâches pouvant être ordonnancées au sein desdits processus légers par un module d'ordonnancement, les processus, processus légers et tâches formant un ensemble de modules logiciels et qui comporte en outre un module de gestion d'un bus de communication logiciel au sein de chaque processus, l'un de ces modules étant élu maître pour la gestion dudit bus au sein dudit dispositif ; un module de gestion dudit bus intégré à chaque processus léger hébergeant une ou plusieurs tâches et en ce que lesdits modules de gestion dudit bus comportent des moyens pour enregistrer les modules logiciels clients du bus et leur associer une FIFO ; des moyens de communication entre les différents modules de gestion du bus ; des moyens de découverte d'autres dispositifs de traitement de l'information participant au bus ; des moyens de création d'un module logiciel relais du destinataire d'un message au sein du processus de l'émetteur et d'un module logiciel relais de l'émetteur au sein du processus du destinataire, lorsque le module logiciel émetteur d'un message et le module logiciel destinataire du message ne sont pas hébergés au sein d'un même processus et des moyens de transmettre un message reçu par un module logiciel relais d'un destinataire à un module logiciel relais de l'émetteur au sein d'un autre processus via un moyen de communication entre processus, ces processus pouvant être localisés sur des machines différentes. L'invention concerne également un procédé d'initialisation d'un bus de communication logiciel par un dispositif de traitement de l'information comportant un système d'exploitation, au moins un processus ordonnancé par ledit système d'exploitation, des processus légers pouvant être ordonnancés au sein desdits processus par ledit système d'exploitation et des tâches pouvant être ordonnancées au sein desdits processus légers par un module d'ordonnancement, les processus, processus léger et tâches formant un ensemble de modules logiciels, l'un des processus étant élu maître, les autres étant esclaves, chaque processus disposant d'un module de gestion du bus, qui comporte les étapes suivantes, une étape où les modules de gestion du bus des processus esclaves établissent un lien de connexion avec le module de gestion du bus du processus maître ; une étape où chaque module logiciel client du bus s'enregistre auprès du module de gestion du bus dont il dépend ; une étape de création d'une FIFO associée à chaque module logiciel client du bus et à chaque module de gestion du bus et une étape où le module de gestion du bus d'un processus esclave qui reçoit des enregistrements de modules logiciels clients du bus exporte ces enregistrements vers le module de gestion du bus du processus maître. Selon un mode particulier de réalisation de l'invention, le procédé comporte en outre une étape de création au sein du processus maître d'autant de modules logiciels relais qu'il y a de modules logiciels clients du bus au sein de processus esclaves dans le dispositif Selon un mode particulier de réalisation de l'invention, les modules logiciels clients du bus s'enregistrent avec un mode public ou privé, seuls les modules logiciels publics sont exportés vers le processus maître. Selon un mode particulier de réalisation de l'invention, le procédé comporte en outre une étape de découverte entre machines participant au bus. Selon un mode particulier de réalisation de l'invention, l'étape de découverte entre machines participant au bus comprend une étape d'annonce où chaque machine participant au bus émet une annonce sur le réseau de communication reliant lesdites machines ; une étape de réception d'un message d'annonce en provenance d'une machine distante ; une étape d'ajout de la machine à l'origine du message d'annonce reçu dans une table si elle n'est pas déjà connue et une étape d'établissement d'une connexion avec cette machine distante. L'invention concerne également un procédé d'échange de messages entre deux modules logiciels clients du bus au sein d'un dispositif tel que décrit précédemment, les deux modules logiciels clients du bus dépendant d'un même module de gestion du bus, qui comporte une étape où le module émetteur poste son message via l'API du bus en spécifiant le nom du destinataire ; une étape où le module de gestion du bus s'apercevant que le destinataire fait partie de son périmètre, poste le message dans la FIFO de celui-ci et une étape où le module destinataire récupère le message par une opération d'extraction au sein de ladite FIFO. L'invention concerne également un procédé d'échange de messages entre deux modules logiciels clients du bus au sein d'un dispositif tel que décrit précédemment, les deux modules logiciels clients du bus ne dépendant pas d'un même module de gestion du bus, mais étant hébergés au sein d'un même processus, qui comporte une étape où le module émetteur poste son message via l'API du bus en spécifiant le nom du destinataire ; une étape où le module du bus s'apercevant que le destinataire ne fait pas partie de son périmètre, poste le message dans la FIFO du module de gestion du bus du destinataire ; une étape où le module de gestion du bus du destinataire s'apercevant que le destinataire fait partie de son périmètre, poste le message dans la FIFO de celui-ci ; une étape où le module destinataire récupère le message par une opération d'extraction au sein de ladite FIFO. L'invention concerne également un procédé d'échange de messages entre deux modules logiciels clients du bus au sein d'un ou plusieurs dispositifs selon la revendication 1, les deux modules logiciels clients du bus n'étant pas hébergés au sein d'un même processus, qui comporte une étape où le module logiciel client du bus qui souhaite émettre un message effectue une étape de routage avec le nom du module destinataire auprès du bus ; une étape où le bus crée le module logiciel relais de ce module destinataire au sein du processus de l'émetteur ; une étape où le message est alors transmis à ce module logiciel relais ; une étape où le bus va créer, au besoin, le lien de connexion direct avec le processus hébergeant le destinataire ; une étape où le bus crée au sein du processus hébergeant le destinataire, un module logiciel relais de l'émetteur ; une étape où le message est alors transmis entre les deux relais via le lien de communication direct établi entre les deux processus ; une étape consistant alors à transmettre le message au destinataire final. Les caractéristiques de l'invention mentionnées ci-dessus, ainsi que d'autres, apparaîtront plus clairement à la lecture de la description suivante d'un exemple de réalisation, ladite description étant faite en relation avec les dessins joints, parmi lesquels : La Fig. 1 illustre les différents types de modules logiciels pouvant s'exécuter sur 25 une machine. La Fig. 2 illustre l'architecture logicielle du bus dans un mode de réalisation de l'invention. La Fig. 3 illustre la phase d'initialisation du bus au sein d'une machine. La Fig. 4 illustre la phase de découverte entre machines participant au bus. 30 La Fig. 5 illustre l'échange de messages entre deux modules logiciels clients du bus qui dépendent d'un même module de gestion du bus. La Fig. 6 illustre l'échange de messages entre deux modules logiciels clients du bus qui ne dépendent pas d'un même module de gestion du bus, mais sont hébergés au sein d'un même processus. La Fig. 7 illustre l'échange de messages entre deux modules logiciels clients du bus hébergés sur des processus différents, voire des machines différentes. La Fig. 2 illustre l'architecture logicielle du bus dans un mode de réalisation de l'invention. L'invention repose sur deux architectures de processus possibles au sein d'un dispositif de traitement de l'information 2.1. Le processus 2.2 illustre la première architecture possible. Dans cette architecture, un premier module logiciel de gestion du bus 2.4 permet à un ou plusieurs modules logiciels 2.6, 2.7 et 2.8 de communiquer avec le bus. Ces modules logiciels destinés à communiquer avec le bus sont appelés des modules client du bus. Ces modules logiciels sont typiquement des processus légers ordonnancés en parallèle au sein du processus. Le module de gestion du bus 2.4 est également typiquement un processus léger. Ces processus légers sont alors ordonnancés par le système d'exploitation au sein du processus. Cet ordonnancement est typiquement préemptif. Alternativement, un ordonnanceur ad hoc au sein du processus peut ordonnancer ces modules logiciels qui sont alors qualifiés de tâches exécutées en parallèle au sein du processus. Leur ordonnancement peut alors être préemptif ou non. L'ordonnanceur ad hoc peut être confondu avec le module de gestion du bus 2.4 ou un module indépendant non représenté selon les modes de réalisation. Dans le processus 2.3, on retrouve un processus léger 2.5 destiné à la gestion du bus pour le processus. Le processus léger 2.9 est un processus client du bus. Au contraire, le processus léger 2.10 n'est pas un client direct du bus. Il héberge un module de gestion de bus 2.11 interne au processus léger et une ou plusieurs tâches 2.12, 2.13 et 2.14. Ce sont alors ces tâches qui sont les clients du bus. Ces tâches sont ordonnancées au sein du processus léger 2.10 par un ordonnanceur ad hoc qui peut se confondre avec le module de gestion du but 2.11 ou pas. Le logiciel est donc divisé en processus 2.2, 2.3. Chaque processus contient un module de gestion du bus 2.4, 2.5. Il héberge également un ou plusieurs modules logiciels clients du bus 2.6, 2.7, 2.8 et 2.9. Ces clients du bus peuvent être des processus légers ou des tâches exécutées directement au sein du processus. Ces clients peuvent comprendre également des tâches 2.12, 2.13 et 2.14 exécutées au sein d'un processus léger. Le processus léger héberge alors également un module de gestion du bus 2.11. La phase d'initialisation du bus au sein d'une machine se passe de la façon suivante illustrée par la Fig. 3. Les modules logiciels clients devant communiquer avec le bus sont répartis au sein d'un ou plusieurs processus. L'un de ces processus est élu processus maître. Les autres processus, s'il y en a, sont donc des processus esclaves. Lors d'une étape 3.1, les modules de gestion du bus des processus esclaves établissent un lien de connexion avec le module de gestion du bus du processus maître. Typiquement, ce lien de connexion est une socket UNIX. Lors d'une étape 3.2, chaque module logiciel client du bus s'enregistre auprès de celui-ci. Cet enregistrement a lieu auprès du module de gestion du bus du processus, ou du processus léger, dont dépend le module logiciel client. Avantageusement cet enregistrement comprend le nom du module logiciel, une référence sur le module de gestion du bus dont dépend ledit module logiciel client ainsi qu'un mode de visibilité. Le mode de visibilité comprend un mode privé dans lequel le module logiciel client du bus peut émettre un message vers d'autres clients publics et recevoir une réponse liée à celui-ci sur le bus, mais pas recevoir de messages directs des autres clients publics. Il comprend également un mode public dans lequel le module logiciel client du bus rend public son nom et son emplacement et peut donc recevoir des messages en sus d'en émettre. Lors de l'étape 3.3, pour chaque module logiciel client du bus qui s'enregistre, le module de gestion du bus crée une FIFO (First In First Out en anglais) utilisée dans le cas d'un échange sur le même module de gestion du bus. Ces FIFO peuvent être des FIFO simples, c'est-à-dire non protégées par une exclusion mutuelle, si le séquencement du module de gestion du bus et des clients du bus sous sa responsabilité est coopératif. Dans le cas contraire, on utilise des FIFO protégées par un mécanisme d'exclusion mutuelle. Chaque module de gestion du bus possède une FIFO utilisée dans le cas d'échanges avec un module de gestion du bus différent pour gérer les réceptions de messages liés à ce module client. Lors d'une étape 3.4, le module de gestion du bus d'un processus esclave qui reçoit des enregistrements de modules logiciels clients du bus exporte ces enregistrements vers le module de gestion du bus du processus maître. Ce module de gestion du bus maintient une table, dite table de routage des utilisateurs, des modules logiciels clients du bus présents sur la machine. Les utilisateurs étant ici les modules clients du bus. Avantageusement, seuls les modules qui se sont déclarés publics sont présents dans cette table. Lors d'une étape 3.5, le module de gestion du bus du processus maître initie au sein du processus maître autant de modules logiciels qu'il y a de modules logiciels clients du bus au sein du processus esclave dans le dispositif. Ces modules logiciels sont gérés par le module de gestion du bus du processus maître et sont appelés modules logiciels relais (proxy en anglais). Cette étape est optionnelle. Les processus relais peuvent être alternativement créés au besoin lors des échanges de messages comme cela sera décrit plus loin. Cette phase d'initiation du bus au sein du dispositif constitue donc une phase de découverte interne où les différents processus au sein du dispositif établissent une communication avec le processus élu comme maître et où chaque module logiciel client du bus au sein du dispositif est découvert par le module de gestion du bus du processus maître qui maintient une table de tous les clients du bus au sein du dispositif. L'initialisation du bus comprend avantageusement en outre une étape de découverte entre machines participant au bus. Cette étape est illustrée par l'organigramme de la Fig. 4. Elle est mise en oeuvre pour chaque dispositif par les modules de gestion du bus des processus maîtres. Lors d'une étape d'annonce 4.1, chaque dispositif émet une annonce sur le réseau de communication reliant les dispositifs. Avantageusement, cette émission est effectuée sur les liens LAN en mode de diffusion générale (broadcast en anglais) sur le sous-réseau de celui-ci et sur les liens WAN en mode de diffusion multipoint (multicast en anglais) sur un groupe particulier. Avantageusement cette émission est répétée dans le temps pour permettre à de nouvelles machines se connectant au bus de découvrir les machines existantes. Le message d'annonce contient avantageusement le nom de la machine ainsi que son adresse IP et un port pour permettre une connexion IP. Lors d'une étape 4.2, le dispositif reçoit un message d'annonce en provenance d'un dispositif distant. Lors d'une étape 4.3, le dispositif vérifie alors si le dispositif distant dont il a reçu l'annonce est connu. Avantageusement, il maintient une table des machines connues, il lui suffit donc de vérifier dans cette table si une entrée existe pour ce dispositif distant. Si le dispositif est déjà connu, il n'y a rien à faire, on boucle en attente de la réception d'un autre message d'annonce. Si le dispositif n'est pas connu, on l'ajoute dans la table lors d'une étape 4.4. On crée une entrée dans la table des machines connues que l'on renseigne avec le nom du dispositif distant, son adresse IP et le port sur lequel il peut être joint. Lors d'une étape 4.5, on établit une connexion avec ce dispositif distant. Cette connexion peut prendre la forme d'une socket INET dédiée à la communication entre machines. Avantageusement, on crée deux sockets INET, l'une utilisant le protocole TCP (Transmission Control Protocol en anglais) dédié aux échanges de messages et une autre utilisant le protocole UDP (User Datagram Protocol en anglais) dédié à des messages de signalisation comme le message d'annonce. A l'issue de cette phase de découverte inter machine, les modules de gestion du bus de chaque processus maître de chaque machine connectée au bus sont tous interconnectés. Au niveau de chaque machine, toutes les machines distantes sont connues et référencées. Un lien de communication est établi vers chacune de ces machines distantes. L'échange de messages entre deux modules logiciels clients du bus utilise la même interface de programmation, API (Application Programmation Interface en anglais) d'accès au bus quel que soit le type de module logiciel. L'échange de messages entre deux modules logiciels clients du bus qui dépendent d'un même module de gestion du bus est illustré par la Fig. 5. Dans ce cas, les deux clients sont typiquement des tâches au sein d'un même processus léger. Lors d'une étape 5.1, l'émetteur poste son message via l'API du bus en spécifiant le nom du destinataire. Lors de l'étape 5.2, le module de gestion du bus s'aperçoit que le destinataire fait partie de son périmètre, par exemple en comparant la référence du module de gestion du bus du destinataire au sien, poste le message dans la FIFO simple de celui-ci. Lors d'une étape 5.3, le destinataire récupère le ou les messages qui lui sont destinés par une opération d'extraction de la FIFO simple. L'échange de messages entre deux modules logiciels clients du bus qui ne dépendent pas d'un même module de gestion du bus, mais sont hébergés au sein d'un même processus est illustré par la Fig. 6. Lors d'une étape 6.1, l'émetteur poste son message via l'API du bus en spécifiant le nom du destinataire. Lors de l'étape 6.2, le module de gestion du bus s'aperçoit que le destinataire ne fait pas partie de son périmètre, par exemple en comparant la référence du module de gestion du bus du destinataire et le sien, poste le message dans la FIFO du module de gestion du bus du destinataire. Lors d'une étape 6.3, le module de gestion du bus du destinataire extrait le ou les messages présents dans sa FIFO, les postent dans la FIFO du destinataire desdits messages. Lors d'une étape 6.4, le destinataire récupère le ou les messages qui lui sont destinés par une opération d'extraction de la FIFO. Concernant la transmission d'un message entre un émetteur et un récepteur constitués par des modules logiciels clients du bus qui se trouvent sur des processus différents, la transmission utilise des modules logiciels relais. Le bus dispose alors de moyens pour initialiser au sein de chaque processus un module logiciel client du bus géré par le bus et qui sert de relais du module logiciel distant. Ainsi, un module logiciel relais du destinataire est créé au sein du processus de l'émetteur, tandis qu'un module logiciel relais de l'émetteur est créé au sein du processus du destinataire. Ces modules logiciels relais sont gérés par le bus. Ainsi, vu de l'émetteur ou du destinataire, la communication apparaît comme étant toujours interne au processus. Les mêmes primitives peuvent être employées par les modules logiciels clients du bus. C'est le bus qui gère la communication inter processus via ces modules logiciels relais. Ces modules logiciels relais permettent également un fonctionnement asynchrone des communications. En effet, l'émetteur poste son message auprès du module logiciel relais du destinataire et peut continuer son traitement. Pendant ce temps-là, le bus achemine le message vers le destinataire réel au moyen d'une connexion inter processus, typiquement une socket UNIX. Concernant cette communication entre processus, on a vu qu'à l'initialisation du bus, un lien de communication est établi entre les processus esclaves et le processus maître. Par contre, il n'y a pas de lien créé entre les processus esclaves entre eux. Par conséquent, au besoin, c'est-à-dire lorsque l'émetteur et le destinataire sont hébergés par deux processus esclaves, un lien est créé, typiquement une socket UNIX, entre les deux processus esclaves. Le processus de transmission entre un émetteur et un destinataire hébergés sur des machines différentes s'effectue exactement sur le même schéma. Il implique également un module relais de l'émetteur au sein du processus du destinataire et un module relais du destinataire au sein du processus de l'émetteur. Une phase de routage gérée par les modules de gestion du bus des processus maîtres des deux machines permet la création d'une connexion directe entre les deux processus. La connexion est ici typiquement une socket INET. La communication est alors effectuée telle qu'illustrée par la Fig. 7. Lors d'une première étape 7.1, le module logiciel client du bus qui souhaite émettre un message que l'on appelle l'émetteur effectue une étape de routage avec le nom du destinataire auprès du bus, c'est-à-dire auprès du module de gestion du bus dont il dépend. Lors d'une étape 7.2, comme le bus s'aperçoit que le destinataire n'est pas hébergé par le même processus, il crée le module logiciel relais de ce destinataire au sein du processus de l'émetteur. Dans certains modes de réalisation, ce module relais peut être préexistant, par exemple au sein du processus maître si l'on a créé les relais lors de la phase d'initialisation, voir l'étape optionnelle 3.5. Lors de l'étape 7.3, le message est alors transmis à ce module logiciel relais selon le mécanisme décrit pour une transmission de messages au sein du processus. Si la communication est asynchrone, l'émetteur peut alors reprendre son traitement. Lors de l'étape 7.4, le bus va créer, au besoin, le lien de connexion direct avec le processus hébergeant le destinataire. Plusieurs cas se présentent ici. Si la communication a lieu au sein d'une même machine, entre un processus esclave et le processus maître, le lien de communication existe déjà. La création est inutile. Si la communication a lieu au sein d'une même machine, entre deux processus esclaves, le lien de communication doit être créé entre les deux processus esclaves, typiquement sous la forme d'une socket UNIX. Si la communication a lieu entre deux machines différentes, le lien direct doit être créé entre les deux processus, typiquement sous la forme d'une socket INET. Cette création est négociée par les processus maîtres des deux machines qui échangent les adresses et ports nécessaires. Lors de l'étape 7.5, le bus crée au sein du processus hébergeant le destinataire, un module logiciel relais de l'émetteur. Lors de l'étape 7.6, le message est alors transmis entre les deux relais via le lien de communication direct établi entre les deux processus. Une dernière étape 7.7 consiste alors à transmettre le message via les mécanismes inter processus déjà décrits au destinataire final. Avantageusement, le nommage des modules logiciels clients du bus intervient selon un schéma dérivé du schéma utilisé pour les URL (Uniform Ressources Locator en anglais). Selon ce schéma, le nom d'un module se décompose de la manière suivante : « ism://nom machine/nom module logiciel » où ism est le nom donné au protocole du bus selon l'invention. Au sein d'une même machine, un nommage relatif réduit au « nom module logiciel » peut être utilisé. Avantageusement, les différentes recopies des messages dans les FIFOs au sein d'un même processus sont évitées. Le message étant copié une fois dans un espace mémoire commun, seule une référence sur ce message est ensuite échangée. Cela permet de limiter les recopies effectives.10 REVENDICATIONS1/ Dispositif de traitement de l'information comportant : - un système d'exploitation (1.16) ; - au moins un processus (1.2, 1.3, 1.4) ordonnancé par ledit système d' exploitation ; - des processus légers (1.5, 1.6, 1.7, 1.8, 1.9, 1.10) pouvant être ordonnancés au sein desdits processus par ledit système d'exploitation (1.16) ; - des tâches (1.11, 1.12, 1.3) pouvant être ordonnancées au sein desdits processus légers par un module d'ordonnancement (1.14), les processus, processus légers et tâches formant un ensemble de modules logiciels ; caractérisé en ce qu'il comporte : - un module (2.4, 2.5) de gestion d'un bus de communication logiciel au sein de chaque processus, l'un de ces modules étant élu maître pour la gestion dudit bus au sein dudit dispositif ; - un module (2.11) de gestion dudit bus intégré à chaque processus léger hébergeant une ou plusieurs tâches ; et en ce que lesdits modules de gestion dudit bus comportent : - des moyens pour enregistrer les modules logiciels clients du bus et leur associer une FIFO ; - des moyens de communication entre les différents modules de gestion du bus ; - des moyens de découverte d'autres dispositifs de traitement de l'information participant au bus ; - des moyens de création d'un module logiciel relais du destinataire d'un message au sein du processus de l'émetteur et d'un module logiciel relais de l'émetteur au sein du processus du destinataire, lorsque le module logiciel émetteur d'un message et le module logiciel destinataire du message ne sont pas hébergés au sein d'un même processus ; - des moyens de transmettre un message reçu par un module logiciel relais d'un destinataire à un module logiciel relais de l'émetteur au sein d'un autre processus via un moyen de communication entre processus, ces processus pouvant être localisés sur des machines différentes.2/ Procédé d'initialisation d'un bus de communication logiciel par un dispositif de traitement de l'information comportant un système d'exploitation (1.16), au moins un processus (1.2, 1.3, 1.4) ordonnancé par ledit système d'exploitation, des processus légers (1.5, 1.6, 1.7, 1.8, 1.9, 1.10) pouvant être ordonnancés au sein desdits processus par ledit système d'exploitation (1.16) et des tâches (1.11, 1.12, 1.3) pouvant être ordonnancées au sein desdits processus légers par un module d'ordonnancement (1.14), les processus, processus légers et tâches formant un ensemble de modules logiciels, l'un des processus étant élu maître, les autres étant esclaves, chaque processus disposant d'un module de gestion du bus, caractérisé en ce qu'il comporte les étapes suivantes : - une étape (3.1) où les modules de gestion du bus des processus esclaves établissent un lien de connexion avec le module de gestion du bus du processus maître ; - une étape (3.2) où chaque module logiciel client du bus s'enregistre auprès du module de gestion du bus dont il dépend ; - une étape (3.3) de création d'une FIFO associée à chaque module logiciel client du bus et à chaque module de gestion du bus ; - une étape (3.4) où le module de gestion du bus d'un processus esclave qui reçoit des enregistrements de modules logiciels clients du bus exporte ces enregistrements vers le module de gestion du bus du processus maître. 3/ Procédé selon la revendication 2, caractérisé en ce qu'il comporte en outre une étape (3.5) de création au sein du processus maître d'autant de modules logiciels relais qu'il y a de modules logiciels clients du bus au sein de processus esclaves dans le dispositif 4/ Procédé selon l'une des revendications 2 ou 3, caractérisé en ce que les modules logiciels clients du bus s'enregistrant avec un mode public ou privé, seuls les modules logiciels publics sont exportés vers le processus maître. 5/ Procédé selon l'une des revendications 2 à 4, caractérisé en ce qu'il comporte en outre une étape de découverte entre machines participant au bus.356/ Procédé selon la revendication 5, caractérisé en ce que l'étape de découverte entre machines participant au bus comprend : - une étape (4.1) d'annonce où chaque machine participant au bus émet une annonce sur le réseau de communication reliant lesdites machines ; - une étape (4.2) de réception d'un message d'annonce en provenance d'une machine distante ; - une étape (4.4) d'ajout de la machine à l'origine du message d'annonce reçu dans une table si elle n'est pas déjà connue ; - une étape (4.5) d'établissement d'une connexion avec cette machine 10 distante. 7/ Procédé d'échange de messages entre deux modules logiciels clients du bus au sein d'un dispositif selon la revendication 1, les deux modules logiciels clients du bus dépendant d'un même module de gestion du bus, 15 caractérisé en ce qu'il comporte : - une étape (5.1) où le module émetteur poste son message via l'API du bus en spécifiant le nom du destinataire ; - une étape (5.2) où le module de gestion du bus s'apercevant que le destinataire fait partie de son périmètre, poste le message dans la FIFO de 20 celui-ci ; - une étape (5.3) où le module destinataire récupère le message par une opération d'extraction au sein de ladite FIFO. 8/ Procédé d'échange de messages entre deux modules logiciels clients 25 du bus au sein d'un dispositif selon la revendication 1, les deux modules logiciels clients du bus ne dépendant pas d'un même module de gestion du bus, mais étant hébergés au sein d'un même processus, caractérisé en ce qu'il comporte : - une étape (6.1) où le module émetteur poste son message via l'API du 30 bus en spécifiant le nom du destinataire ; - une étape (6.2) où le module du bus s'apercevant que le destinataire ne fait pas partie de son périmètre, poste le message dans la FIFO du module de gestion du bus du destinataire ;- une étape (6.3) où le module de gestion du bus du destinataire s'apercevant que le destinataire fait partie de son périmètre, poste le message dans la FIFO de celui-ci ; - une étape (6.4) où le module destinataire récupère le message par une opération d'extraction au sein de ladite FIFO. 9/ Procédé d'échange de messages entre deux modules logiciels clients du bus au sein d'un ou plusieurs dispositifs selon la revendication 1, les deux modules logiciels clients du bus n'étant pas hébergés au sein d'un même processus, caractérisé en ce qu'il comporte : - une étape (7.1) où le module logiciel client du bus qui souhaite émettre un message effectue une étape de routage avec le nom du module destinataire auprès du bus ; - une étape (7.2) où le bus crée le module logiciel relais de ce module destinataire au sein du processus de l'émetteur ; - une étape (7.3) où le message est alors transmis à ce module logiciel relais selon l'une des revendications 7 ou 8 ; - une étape (7.4) où le bus va créer, au besoin, le lien de connexion direct avec le processus hébergeant le destinataire ; - une étape (7.5) où le bus crée au sein du processus hébergeant le destinataire, un module logiciel relais de l'émetteur ; - une étape (7.6) où le message est alors transmis entre les deux relais via le lien de communication direct établi entre les deux processus ; - une étape (7.7) consistant alors à transmettre le message au destinataire final selon l'une des revendications 7 ou 8.