FR 2879056 A1 20060609 FR 0413020 A 20041207 PROCEDE DE DUPLICATION D'UNE BASE DE DONNEES DANS UN RESEAU DE MACHINES ET SYSTEME DE MACHINES A BASE DE DONNEES DUPLIQUEE La présente invention concerne un procédé de duplication d'une base de données dans un réseau de machines. Elle concerne également un système de machines à base de données dupliquée. Elle s'applique notamment pour la duplication de bases de données parmi un grand nombre de machines connectées en réseau, par exemple dans le cadre de systèmes de gestion du trafic aérien. Les systèmes de machines en réseau fonctionnent avec un nombre de machines connectées de plus en plus important. C'est le cas par exemple des systèmes de gestion de trafic aérien qui peuvent comporter plusieurs centaines de machines, fonctionnant soit en poste serveur soit en poste client. Dans un tel système, les machines accèdent par exemple à une base de données commune. Dans un cas d'application à la gestion du trafic aérien, une telle base comporte par exemple des données de plan de vol, des données météorologique, des données de piste etc. ... Toutes ces données doivent être accessibles par toutes les machines du réseau. A cet effet, la base de données est dupliquée dans chacune de ces machines. Néanmoins, au cours du temps les données évoluent. La base de données doit donc être dupliquée régulièrement. En général, la mise à jour d'une donnée est effectuée par une machine du réseau, notamment par un serveur. Une fois la machine ayant effectué la mise à jour, elle transmet cette mise à jour aux autres machines du réseau. Plusieurs solutions sont connues pour dupliquer des données à l'intérieur d'un réseau local. Une première solution consiste à transmettre en point à point les données depuis le poste qui est à l'origine d'une modification de données, par exemple un serveur, vers les autres postes du réseau, par exemple des postes clients. Une transmission point à point signifie que le poste émetteur transmet successivement les données mises à jour vers chaque poste client. Dans un système comportant un grand nombre de postes, par exemple plusieurs centaines, la mise à jour globale des bases données demande un temps très long, non compatible de l'application en cours. Une autre solution utilise une transmission multicast. La transmission multicast permet d'effectuer un seul envoi à partir du poste émetteur, la donnée mise à jour étant simultanément transmise vers tous les autres postes du réseau, encore faut-il s'assurer que les données transmises sont bien reçues. Ainsi, dans un système où la fiabilité des données est primordiale tel qu'un système de gestion de trafic aérien notamment, il est nécessaire de s'assurer que les données sont bien transmises. A cet effet, il est nécessaire d'utiliser des accusés de réception. Dans ce cas, le poste émetteur doit attendre les accusés de réception de toutes les machines du réseau. Ici encore, si le réseau comporte un grand nombre de machines, l'attente de tous les accusés de réception peut exiger un temps trop long, incompatible de l'application. Pour réduire ce temps, il pourrait être possible d'utiliser non pas des accusés de réception comme indiqué précédemment mais des accusés de réception négatifs. L'utilisation d'accusés de réception négatifs signifie qu'un poste client par exemple ne ré-émet un accusé de réception que dans le cas où il ne reçoit pas de données. II demeure néanmoins les problèmes de détection de la non-réception des données et de la gestion de la tolérance aux pannes logicielle ou matérielle de l'émetteur en particulier. En plus de ces problèmes, il reste un temps d'attente des accusés de réception négatifs à gérer, ce temps d'attente pouvant lui aussi être trop important. Toutes ces solutions ont donc en particulier pour inconvénients d'être trop lentes et/ou pas assez fiables. Un but de l'invention est notamment de pallier les inconvénients précités. A cet effet, l'invention a pour objet un procédé de duplication d'une base de données parmi les machines d'un réseau, une machine du réseau émettant une donnée A mise à jour dans sa base de données vers les autres machines. Selon ce procédé : la machine à l'origine de la donnée A émet vers l'ensemble des 30 machines dans un même message avec cette donnée A son numéro de version et l'adresse de la machine; la machine émet en outre le message à une machine maître; une machine publie la donnée A dans sa base de données après un test de numéro de version; une machine maître émet périodiquement un message d'annonce central vers l'ensemble des machines, ce message d'annonce central comportant uniquement pour chaque donnée de la base son numéro de version et l'adresse de la machine à l'origine de sa mise à jour. A la réception d'un message d'annonce central (MAC), une machine compares les versions des données de sa base avec les versions du message d'annonce central (MAC), la machine demandant l'émission d'une donnée A à la machine maître lorsque le numéro de version de la donnée A 1 o est inférieur au numéro de version du message d'annonce central (MAC). La machine à l'origine de la donnée A ré-émet par exemple cette donnée vers les autres machines et la machine maître lorsque le numéro de version de la donnée A qu'elle a émis est supérieur au numéro de version du message d'annonce central (MAC). Avantageusement, lorsqu'une machine émet deux données liées A, C, à la réception les machines stockent les données reçues dans une zone tampon, les données liées A, C étant publiées dans la base de données locale que lorsqu'elles ont la version émise par la machine d'origine. Avantageusement, le message d'annonce central (MAC) est émis périodiquement indépendant des émissions de données (A) par une machine (1). Le réseau de machines peut être un système de gestion de trafic aérien. L'invention a également pour objet un système de machines en réseau partageant une même base de données, la base étant dupliquée dans les machines, une machine d'origine transmettant une donnée A mise à jour dans sa base de données vers les autres machines, le système comportant une machine maître qui fait converger entre elles les bases de données (10). A cet effet: la machine (1) à l'origine de la donnée (A) émettant dans un même message avec cette donnée (A) son numéro de version (41) et l'adresse (42) de la machine; la machine (1) émettant en outre le message à une machine maître (31) ; la machine maître (31) émettant un message d'annonce central (32, MAC) vers les machines (1, 2, 3), ce message d'annonce central comportant pour chaque donnée de la base (10) son numéro de version et l'adresse de la machine (1) à l'origine de sa mise à jour; une machine (31, 2, 3) publiant la donnée (A) dans sa base de données (10) après un test de numéro de version. L'invention a pour principaux avantages qu'elle s'applique à de nombreux systèmes partageant une même base de données, qu'elle s'applique à des systèmes comportant un très grand nombre de machines sans altération des performances, qu'elle est simple à mettre en oeuvre et qu'elle assure une tolérance complète à des pannes logicielle ou matérielle multiples. D'autres caractéristiques et avantages de l'invention apparaîtront à l'aide de la description qui suit faite en regard de dessins annexés qui représentent: - la figure 1, un exemple de réseau de machines partageant une même base de données, comportant à titre d'exemple un serveur et des N postes clients; la figure 2, un exemple de structure d'une base de données; - la figure 3, une illustration de mise en oeuvre du procédé selon l'invention appliqué à l'exemple de réseau de la figure 1; la figure 4, un exemple de structure d'un message d'annonce central destiné à faire converger les bases de données; la figure 5, un exemple de message d'annonce central à l'initialisation des bases de données; la figure 6, le système de la figure 3 après transmission d'un premier enregistrement A; la figure 7, un état de la table de donnée et du message d'annonce central associé à un instant donné ; la figure 8, un exemple de structure d'un message comportant les enregistrements émis par une machine d'origine des mises à jour; la figure 9, une illustration de la fonction d'une zone tampon utilisée avant mise à jour d'une base de données. La figure 1 présente un réseau de machines. Pour simplifier seules trois machines sont représentées, un poste serveur 1 et deux postes clients 2, 3 d'un réseau à N clients. Le réseau pourrait bien évidemment comporter d'autres serveurs. Toujours pour simplifier, seul le serveur initie la mise à jour des données. Les données pourraient aussi être mises à jour par d'autres serveurs. Elles pourraient aussi être mises à jour par des postes clients. Les machines 1, 2, 3 partagent une même base de données 10. Cette base mise à jour par le serveur 1 est distribuée sur les clients 2, 3. La figure 2 présente un exemple de structure d'une telle base de données. La base de données 10 comporte une suite de données 21. Dans une application de gestion du trafic aérien par exemple, chaque donnée correspond à un enregistrement. Il peut s'agir par exemple d'un enregistrement de plan de vol, d'une donnée météorologique, d'une donnée de piste ou de toute autre information relative à la gestion du trafic aérien. La base de données 10 comporte donc toute une série d'enregistrements 21 mis à jour régulièrement par le serveur 1, ces enregistrements étant dupliqués dans chacune des machines du réseau. Par la suite on considèrera à titre d'exemple qu'une donnée 21 de la base 10 est un enregistrement. Cette dernière pourrait néanmoins comporter d'autres types de données que des enregistrements. La figure 2 présente donc une base comportant P enregistrements 21. Pour décrire un fonctionnement du procédé selon l'invention, on suivra les mises à jour de deux données, un enregistrement A et un enregistrement C. On revient à la figure 1. Le serveur écrit un nouvel enregistrement A puis par une transmission multicast 4, il transmet cet enregistrement A aux postes clients 2, 3. La liaison multicast permet au serveur d'exécuter un seul envoi, l'enregistrement A étant simultanément distribué vers tous les clients. Dans une telle configuration, les clients 2, 3 ré-émettent vers le serveur un accusé de réception positif ou un accusé de réception négatif. Un accusé de réception positif est envoyé pour indiquer que l'enregistrement est bien reçu et un accusé de réception négatif est envoyé pour indiquer qu'un enregistrement n'est pas reçu. Des inconvénients de ces deux modes de distribution ont notamment été mentionnés précédemment. La figure 3 illustre une mise en oeuvre du procédé selon l'invention. Le système en réseau comporte les mêmes machines 1, 2, 3 que le système de la figure 1. Il comporte en plus une machine maître 31. Cette machine peut être par exemple un serveur ou un poste client. De préférence, cette machine est dédiée à sa fonction de maître telles que décrite par la suite. Comme les autres machines 1, 2, 3 du réseau, le maître héberge la base de donnée 10 A titre d'exemple, on reprend la mise à jour de l'enregistrement A. Le serveur écrit donc un nouvel enregistrement A dans sa propre base de données 10. Puis comme dans le cas de la figure 1, il transmet par liaison multicast 4 cet enregistrement A aux postes clients 1, 2 et aussi au maître 31. A réception de l'enregistrement A, les clients 2, 3 et le maître 31 écrivent l'enregistrement A dans l'emplacement correspondant 21 de la base de données 10. Les clients 2, 3 et le maître 31 n'envoient pas d'accusés de réception vers la machine d'origine de l'enregistrement A, en l'occurrence le serveur 1 dans l'exemple de la figure 3. Le procédé selon l'invention fait converger périodiquement les tables de données entre elles, indépendamment des mises à jour. La période de convergence dépend notamment de l'application. C'est le maître 31 qui contribue à assurer la convergence des tables de données 10. Pour le bon fonctionnement du système il faut notamment qu'à des instants donnés toutes les bases dupliquées 10 comportent les mêmes données. Il faut par exemple que toutes les machines comportent un même enregistrement d'un plan de vol à un instant donné ou un même enregistrement d'information météorologique pour assurer la fiabilité d'ensemble du système. Le poste maître 31 envoie périodiquement un message d'annonce central 32 (MAC) vers toutes les autres machines 1, 2, 3 du réseau, y compris vers la machine 1 à l'origine des mises à jour. Ce message MAC est notamment destiné à faire converger entre elles les bases de données 10 des machines 1, 2, 3 du réseau. La figure 4 présente la structure d'un message d'annonce central 32 en regard de la base de données 10. Ce message comporte en fait une série de données couplées aux enregistrements de la base 10. La figure 2 montrait qu'un emplacement de la base 10 comporte un enregistrement, A par exemple. Sur ce même emplacement ou en regard ou en correspondance de ce même emplacement, la base comporte par ailleurs un compteur 41 et une adresse IP 42. Le compteur indique le numéro de version de l'enregistrement, plus particulièrement le compteur indique le résultat du comptage du nombre de modifications effectuées sur l'enregistrement A depuis un enregistrement initial donné. Cette structure d'un enregistrement A complété par son compteur et 15 l'adresse IP de sa machine d'origine est répété pour tous les enregistrements de la base de données. Ainsi selon l'invention, une machine 1 qui écrit un nouvel enregistrement A dans une base incrémente le compteur de cet enregistrement et écrit sa propre adresse IP aux emplacements réservés de la base de données. Puis la machine 1 transmet l'enregistrement A, accompagné de son compteur et de son adresse IP aux autres machines 2, 3 et notamment au poste maître 31. L'ensemble des compteurs de tous les enregistrements et des adresses IP des machines d'origine des enregistrements, en fait les données complémentaires placées par exemples aux endroits 41, 42 comme décrit précédemment, cet ensemble forme le message d'annonce central 32 envoyé périodiquement par le poste maître 31 vers toutes les autres machines. Ce message 32 est par exemple envoyé par la liaison multicast. Les données de ce message seront appelées par la suite données MAC. A réception de ce message MAC envoyé par le maître 31, les esclaves effectuent un test avec leur propres données MAC qui sont mises à jour en même temps que la réception des nouveaux enregistrements. Ces esclaves étant bien sûr toutes les autres machines 1, 2, 3 du système qui partagent la même base de données. Si on reprend le cas de l'enregistrement A, lorsque le serveur 1 écrit puis transmet le nouvel enregistrement A, il transmet aussi le compteur mis à jour et son adresse IP. Les clients 2, 3 et le maître stockent alors dans leur base de données 10 ce nouvel enregistrement A ainsi que le compteur mis à jour et l'adresse IP aux endroits 41, 42 correspondant. Chaque client 2, 3 comporte donc les données MAC d'un message d'annonce central 32. Ces données sont mises à jour au fur et à mesure de la réception des nouveaux enregistrements, ligne par ligne. Puis périodiquement il reçoit du poste maître le message d'annonce central 32 comportant l'ensemble des données MAC. Le client compare alors ses données MAC avec les données MAC du message d'annonce central 32 envoyé par le maître 31. La figure 5 présente un message MAC à la création d'un premier enregistrement A. Ce premier enregistrement est par exemple écrit par le serveur 1 dans sa base de donnée 10. Le serveur inscrit aussi le numéro de version, c'est-à-dire incrémente le compteur de l'enregistrement A à 1 et il inscrit son adresse IP dans le champ correspondant 42. Puis le serveur transmet par la liaison multicast 4 l'enregistrement A, la valeur du compteur, donc le numéro de version de l'enregistrement A, et son adresse IP aux autres machines du réseau, c'est-à-dire aux postes clients 2, 3 et au maître 31. La figure 6 présente le système de la figure 3 après transmission de ce premier enregistrement A. Dans l'exemple présenté, un client 3 n'a pas reçu le message. Dans ce cas, le compteur reste à 0 à l'emplacement 41 réservé au mot A en regard de la base de donnée 10, à l'intérieur de ce client 3. L'autre client 2 et le maître ayant bien reçu les données transmises par le serveur 1, ont le bon numéro de version de l'enregistrement A, en l'occurrence la version 1 ici à l'initialisation. L'emplacement 41 réservé au compteur de l'enregistrement A est bien à 1 pour ce client 2 et pour le maître 31 Puis le maître envoie le message d'annonce central 32, le message MAC. Le message MAC a une structure connue de toutes les machines, de façon à permettre à chacune d'entre elle d'identifier le compteur associé à chacun des enregistrements ainsi que les adresses IP des machines émettrices. A cet effet, le message MAC a par exemple une structure série qui présente successivement le compteur et l'adresse IP associés à chacun des enregistrements. Le message MAC est par exemple transmis par la liaison multicast. A la réception du message MAC, les machines réceptrices 1, 2, 3 comparent ce message MAC transmis par le maître 31 avec leur propre message MAC. En particuliers elles comparent chacun des numéros de version des mots de la base 10 avec les numéros de version correspondant transmis par le maître. Dans l'exemple de la figure 6 les machines comparent la valeur du compteur de l'emplacement 41 réservé au mot A avec la valeur du compteur inscrite dans le message MAC transmis par le maître. Pour que le résultat de la comparaison soit concluant, il faut que les valeurs de compteur soient identiques, en l'occurrence égales à 1 dans l'exemple de la figure 6. Dans cet exemple un client 3 n'a pas reçu l'enregistrement A et donc son compteur est resté à 0 sur l'emplacement réservé 41. Plus généralement, un enregistrement A n'a pas été reçu par une machine si: Cpt Amachine La relation (1) ne s'applique toutefois pas lorsque le maître 31 est défaillant. Lorsque le poste client 3 s'aperçoit que l'enregistrement A n'a pas été transmis suite au test (1), il demande par exemple l'émission de cet enregistrement A au poste maître 31. Plus généralement lorsqu'un poste client demande l'émission des enregistrements qui n'ont pas le même numéro de version que le message MAC c'est-à-dire dont les compteurs associés vérifient la relation (1). Le maître 31 retransmet alors les enregistrements demandés pas le client, par exemple en mode multicast. En transmission multicast, le ou les enregistrements émis par le maître 31 sont envoyés à toutes les autres machines 1, 2, 3 y compris à celles qui ont bien reçu l'enregistrement. Ces autres machines font le test selon la relation (1) et ne réagissent pas car ce test indique alors que les enregistrements qu'ils contiennent ont la bonne version. L'invention permet aussi avantageusement de traiter le cas d'une machine qui s'insère dans le réseau. Une telle machine demande alors au maître l'ensemble des enregistrements de la base de données à la suite des tests (1). Suite aux tests, la machine agit alors comme une autre machine ayant des mauvais numéros de versions. Dans ce cas d'insertion de machine, la demande de ré-émission de l'ensemble des enregistrements par le maître peut entraîner la saturation du réseau. Pour éviter cette saturation, la machine demande par exemple dans un premier temps seulement une partie des enregistrements. Plus généralement pour éviter des surcharges ponctuelles sur le réseau le maître envoie par exemple un sous-ensemble des enregistrements dans une période donnée, ou encore, il envoie une seule fois un même enregistrement dans une période donnée. Dans un autre cas de défaillance de transmission, ce peut être le maître 31 qui ne reçoit pas l'enregistrement A. Son compteur reste alors à zéro, notamment dans l'exemple de la figure 6. Dans ce cas, le client 3 qui est dans le même état que le maître, c'est-à-dire qui n'a pas reçu l'enregistrement A ne réagit pas et ne demande donc pas l'émission par le maître de l'enregistrement A. En effet, dans ce cas le test selon la relation (1) est inopérant. Le client 3 ne vérifie pas la relation (1) et pourtant il n'a pas reçu l'enregistrement A. Ce poste client 3 ne s'aperçoit donc pas qu'il n'a pas reçu cet enregistrement A. Les autres clients 2 qui ont bien reçu l'enregistrement A ne vérifient pas la relation (1) car ils ont en fait un numéro de version supérieur à celui du maître. Pour une machine qui a reçu l'enregistrement A, le compteur vérifie alors la relation suivante: Cpt Amachine > Cpt Amaître (2) Une machine qui vérifie la relation (2) sait donc qu'elle a reçu l'enregistrement A. Elle peut donc transmettre à destination de toutes les machines y compris le maître l'enregistrement A ainsi que tous les autres enregistrements pour lesquels elle vérifie la relation (2). Néanmoins pour éviter une saturation sur le réseau, il est préférable qu'une seule machine transmette l'enregistrement A. Ce peut être alors la machine qui est à l'origine de la modification de l'enregistrement A, c'est-à-dire l'écrivain. Dans l'exemple de la figure 6 c'est donc par exemple au serveur 1 de transmettre l'enregistrement A dont il est l'origine. La machine qui est à l'origine d'un enregistrement est bien identifiée dans le message MAC grâce notamment à son adresse IP placée à l'endroit 42 en regard du compteur. En cas de défaillance de l'écrivain simultanée avec la non-réception du maître 31, une machine cliente (parmis 1,2,3) a la responsabilité de la retransmission de l'enregistrement A. Cette situation est détectée par les machines ayant reçu l'enregistrement A si le message MAC émit par le maître vérifie la relation (2) 1 o pendant n périodes consécutives. En cas de défaillance complète de la machine maître 31, un nouveau maître est automatiquement élu. Cette défaillance est détectée par la nonréception de message MAC pendant n périodes consécutives. II reste alors notamment un cas à prendre en compte qui est celui où c'est le serveur 1 qui est défaillant et plus généralement où c'est la machine qui est à l'origine de l'enregistrement qui est défaillant. En se référant à la figure 6, dans ce cas, ni le maître 31 ni les autres machines 2, 3 ne reçoivent l'enregistrement A. Pour pallier ce type de défaillance, il est possible de prévoir un système redondant néanmoins il n'est guère critique car l'ensemble des bases de données du système sont toujours cohérentes (aucune ne contient l'enregistrement A) La figure 7 présente un état de la table 10 et du message MAC associé à un instant donné. Cette table 10 est dupliquée dans toutes les machines. Dans chaque machine la table 10 occupe un espace mémoire réservé, une case mémoire 21 est réservée à chaque enregistrement. II en est de même pour le message MAC qui dispose d'un espace mémoire. Une série de cases mémoires 41 indique ainsi les numéros de version des enregistrements, par l'intermédiaire de compteurs. Une autre série de cases mémoires 42 indiquent les adresses IP des machines d'origine des enregistrements. Les enregistrements peuvent être indépendants les uns des autres, mais ils peuvent aussi être liés. C'est notamment le cas lorsque des transactions sont en jeu. En pratique il y a une relation entre deux tables et la mise à jour des enregistrements doit se faire simultanément. On suppose à titre d'exemple que les données A et C sont liées. Il faut donc que les clients 2, 3 reçoivent A et C en même temps. Plus précisément, il faut qu'en cas de non-réception de A par un client, C ne soit pas visible par ce client. Il faut éviter au client d'utiliser une bonne version de C avec une mauvaise version de A. La figure 8 présente un exemple de structure d'un message 81 comportant les enregistrements émis par le serveur 1. Cette structure de message permet notamment de traiter les enregistrements liés. Le message 81 a une structure de données en séries et comporte un en-tête 82 suivie des enregistrements. L'en-tête 82 indique le nombre N d'enregistrements que contient le message. Les N enregistrements incluent les enregistrements liés A et C. Un client ne devra alors placer les enregistrements reçus dans sa base de données 10 que s'il a reçu tous les N enregistrements. Un client sait qu'il a reçu un enregistrement à l'aide notamment des tests (1), (2) décrits précédemment. Chaque client comporte donc un tampon interne, encore appelé buffer dans la littérature anglo-saxonne, dans lequel il stocke les enregistrements reçus. La figure 9 illustre notamment la fonction de ce tampon. Un client 3 comporte donc un tampon 91 dans lequel il reçoit les enregistrements liés A, C et plus généralement toutes les autres enregistrements liés ou indépendants. Le tampon occupe une zone mémoire dédiée dans le client. En particulier pour tenir compte des enregistrements liés, le client traite le tampon 91 comme un enregistrement A, de la façon décrite en regard de la figure 6 notamment. Le procédé selon l'invention applique au tampon le protocole décrit plus haut pour un enregistrement A. Ainsi la version d'un tampon est considérée correcte lorsque toutes les versions de ses enregistrements A, C sont 3o correctes. Tant que la version de son tampon 91 n'est pas correcte, le client 3 demande au maître 31 de lui ré-émettre les enregistrements A, C. Lorsque la version du tampon est correcte, le client bascule 92 les données du tampon dans sa base de données 10. Il peut arriver qu'un défaut de transmission touche l'en-tête 82, c'est-à-dire que le contenu de celle-ci n'est pas reçu par un client. Le client s'aperçoit alors qu'il n'a pas reçu le contenu de l'en-tête et lance une requête au maître pour une ré-émission du message complet 81, en-tête compris. Le maître garde par exemple en mémoire que les données A, C sont groupées et ré-émet alors l'ensemble du message 81 avec l'en-tête 82. Le temps de convergence en cas de pannes pour une application de gestion du trafic aérien peut être compris par exemple entre une et cinq secondes. 1 o Cette période de convergence correspond à la période d'envoi des messages MAC, c'est-à-dire qu'un message MAC est alors envoyé tous les \t, At étant par exemple comprise entre 1 et 5 secondes. L'envoi des enregistrements A, C mis à jour par la liaison multicast 4 se fait à n'importe quel instant, en particulier indépendamment des périodes de convergence des enregistrements. A chaque période de convergence, le maître envoie le message MAC puis commence les transactions de convergence entre le maître et les clients: tests sur les versions des enregistrements reçus, demande de ré-émission des enregistrements non reçus, avec ou sans itération. A un instant donné, toutes les bases de données 10 convergent. Elles sont identiques, elles ont la même version. Avantageusement, un procédé selon l'invention ne gère pas des historiques d'enregistrements, il ne gère que la dernière version. En particulier qu'il y ait 10, 100 ou même 1000 machines en réseau, voire plus, les performances sont les mêmes. Les temps de réponse ne sont pas liés aux nombres des machines, notamment du fait que les tests de version (1), (2) sont décentralisés dans chaque machine et que les retransmissions après les requêtes de ré-émissioneffectuées en parallèle sont faites par période de convergence vers l'ensemble des machines en multicast. Dans l'exemple d'application des figures 3 et 6, un seul serveur a été représenté. Une application peut évidemment utiliser plusieurs serveurs. C'est notamment le cas pour un système de gestion du trafic aérien où le système peut comporter un serveur dédié aux plans de vols, un serveur dédié aux données météorologique, un serveur dédié aux données de piste etc. ... Dans ce cas, chacun de ces serveurs écrit les enregistrements correspondant dans la base de données 10. Dans l'exemple de réalisation des figures 3 et 6, le serveur 1 et le maître 31 sont deux machines distinctes. Néanmoins, il est possible prévoir des applications où le maître 31 est aussi à l'origine de la mise à jour des données. En d'autres termes, une même machine peut à la fois être maître et écrivain, un écrivain étant à l'origine de l'écriture ou de la modification d'une donnée ou d'un enregistrement. L'invention a été décrite pour un système de gestion de trafic aérien, elle peut néanmoins s'appliquer pour de nombreux autres systèmes comportant des machines en réseau qui utilisent une même base de données. REVENDICATIONS 1. Procédé de duplication d'une base de données (10) parmi les machines (1, 2, 3) d'un réseau, une machine (1) du réseau émettant une donnée (A) mise à jour dans sa base de données vers les autres machines (2, 3), caractérisé en ce que: - la machine (1) à l'origine de la donnée (A) émet dans un même message avec cette donnée (A) son numéro de version (41) et l'adresse (42) de la machine; la machine (1) émet en outre le message à une machine maître (31) ; une machine (31, 2, 3) publie la donnée (A) dans sa base de données (10) après un test de numéro de version; la machine maître (31) émet périodiquement un message d'annonce central (32, MAC) vers les machines (1, 2, 3), ce message d'annonce central comportant pour chaque donnée de la base (10) son numéro de version et l'adresse de la machine (1) à l'origine de sa mise à jour. 2. Procédé selon la revendication 1, caractérisé en ce qu'à la réception d'un message d'annonce central (MAC), une machine compare les versions des données de sa base (10) avec les versions du message d'annonce central (MAC), la machine (3) demandant l'émission d'une donnée (A) à la machine maître (31) lorsque le numéro de version de la donnée (A) est inférieur au numéro de version du message d'annonce central (MAC). 3. Procédé selon l'une quelconque des revendications précédentes, caractérisé en ce que la machine (1) à l'origine de la donnée (A) ré-émet cette donnée vers les autres machines (2, 3) et la machine maître (31) lorsque le numéro de version de la donnée (A) qu'elle a émis est supérieur au numéro de version du message d'annonce central (MAC). 4. Procédé selon l'une quelconque des revendications précédentes, caractérisé en ce que lorsqu'une machine (1) émet deux données liées (A, C), à la réception les machines (2, 3) stockent les données reçues dans une zone tampon (91), les données liées (A, C) étant publiées dans la base de données (10) de la machine que lorsqu'elles ont la version émise par la machine (1) d'origine. 5. Procédé selon l'une quelconque des revendications précédentes, caractérisé en ce que le message d'annonce central (MAC) est émis périodiquement indépendant des émissions de données (A) par une machine (1). 6. Procédé selon l'une quelconque des revendications précédentes, caractérisé en ce que les données (A) sont émises par liaison multicast. 7. Procédé selon l'une quelconque des revendications précédentes, caractérisé en ce que le message d'annonce central (MAC) est émis par liaison multicast. 8. Procédé selon l'une quelconque des revendications précédentes, 15 caractérisé en ce que le réseau de machines (1, 2, 3) est un système de gestion de trafic aérien. 9. Système de machines (1, 2, 3) en réseau partageant une même base de données (10), la base (10) étant dupliquée dans les machines, une machine (1) d'origine transmettant une donnée (A) mise à jour dans sa base de données vers les autres machines (2, 3), caractérisé en ce qu'il comporte une machine maître (31) qui fait converger entre elles les bases de données (10) : la machine (1) à l'origine de la donnée (A) émettant dans un même 25 message avec cette donnée (A) son numéro de version (41) et l'adresse (42) de la machine; la machine (1) émettant en outre le message à une machine maître (31) ; une machine (31, 2, 3) publiant la donnée (A) dans sa base de 30 données (10) après un test de numéro de version; - la machine maître (31) émettant un message d'annonce central (32, MAC) vers les machines (1, 2, 3), ce message d'annonce central comportant pour chaque donnée de la base (10) son numéro de version et l'adresse de la machine (1) à l'origine de sa mise à jour. 10. Système selon la revendication 9, caractérisé en ce qu'à la réception d'un message d'annonce central (MAC), une machine compare les versions des données de sa base (10) avec les versions du message d'annonce central (MAC), la machine (3) demandant l'émission d'une donnée (A) à la machine maître (31) lorsque le numéro de version de la donnée (A) est inférieur au numéro de version du message d'annonce central (MAC). 11. Système selon l'une quelconque des revendications 9 ou 10, caractérisé en ce que la machine (1) à l'origine de la donnée (A) ré-émet cette donnée vers les autres machines (2, 3) et la machine maître (31) lorsque le numéro de version de la donnée (A) qu'elle a émis est supérieur au numéro de version du message d'annonce central (MAC). 12. Système selon l'une quelconque des revendications 9 à 11, caractérisé en ce que lorsqu'une machine (1) émet deux données liées (A, C), à la réception les machines (2, 3) stockent les données reçues dans une zone tampon (91), les données liées (A, C) étant publiées dans la base de données (10) de la machine que lorsqu'elles ont la version émise par la machine (1) d'origine. 13. Système selon l'une quelconque des revendications 9 à 12, caractérisé en ce que le message d'annonce central (MAC) est émis périodiquement indépendant des émissions de données (A) par une machine (1). 14. Système selon l'une quelconque des revendications 9 à 13, caractérisé en ce que les données (A) sont émises par liaison multicast. 15. Système selon l'une quelconque des revendications 9 à 14, caractérisé en ce que le message d'annonce central (MAC) est émis par liaison 30 multicast. 16. Système selon l'une quelconque des revendications précédentes, caractérisé en ce qu'il effectue une gestion du contrôle aérien.