WO2006061358A1 - Procede de duplication d'une base de donnees dans un reseau de machines et systeme de machines a base de donnees dupliquee - Google Patents

Procede de duplication d'une base de donnees dans un reseau de machines et systeme de machines a base de donnees dupliquee Download PDF

Info

Publication number
WO2006061358A1
WO2006061358A1 PCT/EP2005/056446 EP2005056446W WO2006061358A1 WO 2006061358 A1 WO2006061358 A1 WO 2006061358A1 EP 2005056446 W EP2005056446 W EP 2005056446W WO 2006061358 A1 WO2006061358 A1 WO 2006061358A1
Authority
WO
WIPO (PCT)
Prior art keywords
machine
data
machines
database
mac
Prior art date
Application number
PCT/EP2005/056446
Other languages
English (en)
Inventor
Laurent Deniel
Original Assignee
Thales
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 filed Critical Thales
Priority to US11/721,149 priority Critical patent/US20100131465A1/en
Priority to CA002591909A priority patent/CA2591909A1/fr
Priority to EP05846003A priority patent/EP1825408A1/fr
Publication of WO2006061358A1 publication Critical patent/WO2006061358A1/fr

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/27—Replication, distribution or synchronisation of data between databases or within a distributed database system; Distributed database system architectures therefor
    • G06F16/273—Asynchronous replication or reconciliation
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/27—Replication, distribution or synchronisation of data between databases or within a distributed database system; Distributed database system architectures therefor

Definitions

  • the present invention relates to a method of duplicating a database in a network of machines. It also relates to a duplicated database machine system. It applies in particular for the duplication of databases among a large number of machines connected in a network, for example in the context of air traffic management systems.
  • Networked machine systems work with a growing number of connected machines. This is the case, for example, of air traffic management systems which may comprise several hundred machines, operating either as a server station or as a client station. In such a system, the machines access for example a common database.
  • a base includes, for example, flight plan data, meteorological data, runway data, etc. ... All this data must be accessible by all machines in the network.
  • the database is duplicated in each of these machines. Nevertheless, over time the data evolves. The database must therefore be duplicated regularly.
  • the update of a data is performed by a machine of the network, in particular by a server.
  • a first solution consists in transmitting point-to-point data from the station that is causing a data modification, for example a server, to the other stations of the network, for example client stations.
  • a point-to-point transmission means that the transmitting station successively transmits the updated data to each client station.
  • the overall update of the databases requires a very long time, not compatible with the current application.
  • Another solution uses a multicast transmission.
  • the multicast transmission makes it possible to carry out a single sending from the transmitting station, the updated data being simultaneously transmitted to all the other stations of the network, it must be ensured that the transmitted data are well received.
  • it is necessary to use acknowledgments In this case, the transmitting station must wait for acknowledgments of all the machines in the network. Again, if the network has a large number of machines, waiting for all acknowledgments may take too long, incompatible application. To reduce this time, it may be possible to use not acknowledgments as indicated above but negative acknowledgments.
  • negative acknowledgments means that a client machine, for example, re-acknowledges only if it does not receive data.
  • a client machine for example, re-acknowledges only if it does not receive data.
  • problems in detecting the non-receipt of data and the management of the software or hardware fault tolerance of the transmitter in particular In addition to these problems, there is still a wait time for negative acknowledgments to manage, this waiting time can also be too important.
  • the subject of the invention is a method of duplicating a database among the machines of a network, a machine of the network transmitting an A data item updated in its database to the other machines. According to this method:
  • the machine at the origin of the data A transmits towards all the machines in the same message with this data Has its version number and the address of the machine;
  • the machine also transmits the message to a master machine
  • a machine publishes the data item A in its database after a version number test; a master machine periodically transmits a central announcement message to all the machines, this central announcement message comprising only for each datum of the database its version number and the address of the machine at the origin of its update .
  • a machine On receipt of a central announcement message (MAC), a machine compares the versions of the data of its base with the versions of the central announcement message (MAC), the machine requesting the transmission of a data item A to the master machine when the version number of the data A is lower than the version number of the central announcement message (MAC).
  • MAC central announcement message
  • the machine at the origin of the data A re-transmits for example this data to the other machines and the master machine when the version number of the data A that it has sent is greater than the version number of the announcement message.
  • central (MAC) central
  • the machines when a machine sends two linked data A, C, on reception the machines store the received data in a buffer zone, the linked data A, C being published in the local database only when they have the issued version by the original machine.
  • the central announcement message (MAC) is issued periodically independent of the data transmission (A) by a machine (1).
  • the machinery network may be an air traffic management system.
  • the invention also relates to a system of networked machines sharing the same database, the base being duplicated in the machines, an original machine transmitting an A data update in its database to the other machines, the system comprising a master machine which converges the databases (10).
  • a master machine which converges the databases (10).
  • the machine (1) further transmitting the message to a master machine (31);
  • the master machine (31) transmitting a central announcement message (32, MAC) to the machines (1, 2, 3), this central announcement message comprising for each datum of the base (10) its version number and the address of the machine (1) causing it to be updated; a machine (31, 2, 3) publishing the data item (A) in its database (10) after a version number test.
  • a central announcement message 32, MAC
  • the main advantages of the invention are that it applies to many systems sharing the same database, that it applies to systems with a very large number of machines without performance degradation, that it is simple to implement and that it provides a complete tolerance to multiple software or hardware failures.
  • FIG. 1 an example of a network of machines sharing the same database, comprising, by way of example, a server and N client stations;
  • FIG. 2 an exemplary structure of a database
  • FIG. 3 an illustration of implementation of the method according to the invention applied to the network example of FIG. 1;
  • FIG. 4 an exemplary structure of a central announcement message intended to converge the databases
  • FIG. 5 an example of a central announcement message at the initialization of the databases
  • FIG. 7 a state of the data table and the central announcement message associated with a given instant
  • FIG. 8 an example of a structure of a message including the records transmitted by a machine of origin of the updates
  • Figure 1 shows a network of machines. To simplify only three machines are represented, a server station 1 and two client stations 2, 3 of a network to N customers.
  • the network could of course include other servers. Still for simplicity, only the server initiates the update of the data.
  • the data could also be updated by other servers. They could also be updated by client computers.
  • the machines 1, 2, 3 share the same database 10. This database updated by the server 1 is distributed on the clients 2, 3.
  • FIG. 2 shows an example of a structure of such a database.
  • the database 10 includes a data suite 21.
  • each data corresponds to a record.
  • This may be, for example, a flight plan record, weather data, runway data, or other information related to air traffic management.
  • the database 10 therefore comprises a series of records 21 regularly updated by the server 1, these records being duplicated in each of the machines of the network. Subsequently, it will be considered by way of example that a datum 21 of the base 10 is a record. The latter could nevertheless include other types of data than records.
  • FIG. 2 thus presents a base comprising P recordings 21. To describe an operation of the method according to the invention, the updates of two data, an A record and a C record, will be followed.
  • the server writes a new record A and then by a multicast transmission 4, it transmits this record A to the client stations 2, 3.
  • the multicast link allows the server to execute a single send, the record A being simultaneously distributed to all clients.
  • the clients 2, 3 re-transmit to the server an accused positive reception or negative acknowledgment.
  • a positive acknowledgment is sent to indicate that the record is received and a negative acknowledgment is sent to indicate that a record is not received. Disadvantages of these two modes of distribution have been mentioned previously.
  • FIG. 3 illustrates an implementation of the method according to the invention.
  • the networked system comprises the same machines 1, 2, 3 as the system of FIG. 1. It furthermore comprises a master machine 31.
  • This machine can be for example a server or a client station. Preferably, this machine is dedicated to its master function as described below.
  • the master hosts the database 10 As an example, we resume the update of the record A.
  • the server therefore writes a new record A in its own database 10.
  • the clients 2, 3 and the master 31 write the record A in the corresponding location 21 of the database 10.
  • the clients 2, 3 and the master 31 do not send acknowledgments to the machine of origin of the record A, in this case the server 1 in the example of Figure 3.
  • the method according to the invention periodically converts the data tables between them, independently of the updates.
  • the period of convergence depends in particular on the application. It is the master 31 which contributes to ensuring the convergence of the data tables 10. For the proper functioning of the system it is especially necessary that at given times all the duplicate databases 10 comprise the same data. For example, all machines must have the same record of a flight plan at a given moment or the same meteorological information record to ensure the overall reliability of the system.
  • the master station 31 periodically sends a central announcement message 32 (MAC) to all the other machines 1, 2, 3 of the network, including to the machine 1 at the origin of the updates. This MAC message is especially intended to converge the databases 10 of the machines 1, 2, 3 of the network.
  • MAC central announcement message
  • FIG. 4 shows the structure of a central announcement message 32 next to the database 10.
  • This message actually comprises a series of data coupled to the records of the database 10.
  • the base 10 includes a record, A for example.
  • the base also comprises a counter 41 and an IP address 42.
  • the counter indicates the version number of the record, more particularly the counter indicates the counting result. the number of changes made to the A record since a given initial record.
  • This structure of a record A completed by its counter and the IP address of its original machine is repeated for all records in the database.
  • a machine 1 which writes a new record A in a database increments the counter of this record and writes its own IP address to the reserved locations of the database. Then the machine 1 transmits the recording A, accompanied by its counter and its IP address to the other machines 2, 3 and in particular to the master station 31.
  • the set of counters of all the records and the IP addresses of the original machines of the recordings forms the central announcement message 32 sent periodically by the master station 31 to all other machines.
  • This message 32 is for example sent by the multicast link.
  • the data of this message will be called later MAC data.
  • the slaves On receipt of this MAC message sent by the master 31, the slaves perform a test with their own MAC data which are updated at the same time as the reception of the new recordings. These slaves being of course all the other machines 1, 2, 3 of the system that share the same database. If we take the case of the record A, when the server 1 writes and then transmits the new record A, it also transmits the updated counter and its IP address.
  • Each client 2, 3 thus comprises the MAC data of a central announcement message 32. These data are updated as and when new records are received, line by line. Then periodically it receives from the master station the central announcement message 32 comprising all the MAC data. The client then compares its MAC data with the MAC data of the central announcement message 32 sent by the master 31.
  • FIG. 5 presents a MAC message to the creation of a first record A.
  • This first record is for example written by the server 1 in its database 10.
  • the server also records the version number, that is to say say increments the counter of the record A to 1 and it registers its IP address in the corresponding field 42. Then the server transmits via the multicast link 4 the record A, the value of the counter, therefore the version number of the recording A, and its IP address to the other machines of the network, that is to say the client stations 2, 3 and the master 31.
  • FIG. 6 presents the system of FIG. 3 after transmission of this first recording A.
  • a client 3 did not receive the message.
  • the counter remains at 0 at the location 41 reserved for the word A opposite the database 10, within this client 3.
  • the other client 2 and the master having received the transmitted data by the server 1, have the correct version number of the record A, in this case version 1 here at initialization.
  • the location 41 reserved for the counter of the record A is at 1 for this client 2 and for the master 31.
  • the master sends the central announcement message 32, the MAC message.
  • the MAC message has a known structure of all the machines, so that each of them can identify the counter associated with each of the records as well as the IP addresses of the transmitting machines.
  • the MAC message has for example a serial structure which successively presents the counter and the IP address associated with each of the records.
  • the MAC message is for example transmitted by the multicast link.
  • the receiving machines 1, 2, 3 compare this MAC message transmitted by the master 31 with their own MAC message. In particular, they compare each of the version numbers of the words of the base 10 with the corresponding version numbers transmitted by the master. In the example of FIG.
  • the machines compare the value of the counter of the slot 41 reserved for the word A with the value of the counter entered in the MAC message transmitted by the master. For the result of the comparison to be conclusive, the counter values must be identical, in this case equal to 1 in the example of FIG. 6. In this example, a client 3 has not received the registration. A and therefore its counter remained at 0 on the reserved slot 41. More generally, an A record was not received by a machine if:
  • Cpt A m achine is the counter of the record A in the machine and Cpt Amaître is the counter of the record A in the MAC message sent by the master.
  • the relation (1) does not apply, however, when the master 31 is faulty.
  • the client station 3 realizes that the record A has not been transmitted following the test (1), it asks for example the issuance of this record A to the master station 31. More generally when a client station asks issuing records that do not have the same version number as the MAC message, that is, whose associated counters verify the relationship (1).
  • the master 31 then retransmits the recordings requested by the client, for example in multicast mode. In multicast transmission, the record or records issued by the master 31 are sent to all other machines 1, 2, 3 including those that have received the registration. These other machines do the test according to relation (1) and do not react because this test then indicates that the records they contain have the correct version.
  • the invention also advantageously makes it possible to treat the case of a machine that fits into the network.
  • a machine requests from the master all the records of the database following the tests (1). Following the tests, the machine then acts as another machine with the wrong version numbers.
  • the request for re-transmission of all the records by the master may result in the saturation of the network.
  • the machine requests for example at first only part of the recordings. More generally, to avoid occasional overloads on the network, the master for example sends a subset of the records in a given period of time, or sends the same record once in a given period.
  • the master 31 which does not receive the record A. Its counter then remains at zero, especially in the example of FIG. 6.
  • the client 3 which is in the same state that the master, that is to say who has not received the record A does not react and therefore does not request the emission by the master of the recording A. Indeed, in this case the test according to relation (1) is inoperative. The client 3 does not check the relation (1) and yet it has not received the record A. This client station 3 does not notice that it did not receive this record A.
  • a machine which verifies the relation (2) therefore knows that it has received the record A. It can therefore transmit to all the machines including the master the record A as well as all the other records for which it checks the relation (2). Nevertheless, to avoid saturation on the network, it is preferable that only one machine transmits the recording A. It can be then the machine which is to the origin of the modification of the record A, that is to say the writer. In the example of Figure 6 it is for example the server 1 to transmit the record A which it is the origin. The machine which is at the origin of a recording is well identified in the MAC message thanks in particular to its IP address placed at the location 42 opposite the counter.
  • a client machine (among 1, 2, 3) is responsible for the retransmission of the recording A. This situation is detected by the machines that received record A if the MAC message issued by the master checks relation (2) for n consecutive periods.
  • FIG. 6 shows a state of the table 10 and MAC message associated with a given time. This table 10 is duplicated in all the machines. In each machine the table 10 occupies a reserved memory space, a memory slot 21 is reserved for each record. It is the same for the MAC message that has a memory space.
  • a series of memory cells 41 thus indicates the version numbers of the recordings, via counters.
  • Another series of memory boxes 42 indicate the IP addresses of the original machines of the recordings. Records can be independent of each other, but they can also be linked. This is particularly the case when transactions are at stake. In practice there is a relationship between two tables and the updating of records must be done simultaneously. It is assumed by way of example that the data A and C are linked.
  • the clients 2, 3 receive A and C at the same time. More specifically, it is necessary that in case of non-receipt of A by a customer, C is not visible by this customer. The client should avoid using a good version of C with a bad version of A.
  • FIG. 8 shows an example structure of a message 81 comprising the records sent by the server 1.
  • This message structure notably makes it possible to process the linked records.
  • Message 81 has a serial data structure and has a header 82 followed by records.
  • the header 82 indicates the number N of records contained in the message.
  • the N records include the linked records A and C.
  • a client will then have to place the received records in his database 10 only if he has received all the N records.
  • a client knows that he has received a recording, in particular using the tests (1), (2) described above.
  • Each client therefore has an internal buffer, also called buffer in the English literature, in which it stores the records received.
  • FIG. 9 illustrates in particular the function of this buffer.
  • a client 3 therefore comprises a buffer 91 in which it receives the linked records A, C and more generally all the other linked or independent records.
  • the buffer occupies a dedicated memory area in the client.
  • the client treats the stamp 91 as a record A, as described with reference to Figure 6 in particular.
  • the method according to the invention applies to the buffer the protocol described above for an A record.
  • the version of a buffer is considered correct when all the versions of its records A, C are correct.
  • the client 3 asks the master 31 to re-transmit the records A, C.
  • the client switches the data of the buffer into its buffer.
  • a transmission fault affects the header 82, that is to say that the content thereof is not received by a client.
  • the client then realizes that he has not received the contents of the header and sends a request to the master for a re-transmission of the complete message 81, including header.
  • the master for example keeps in memory that the data A, C are grouped and then reissues the whole of the message 81 with the header 82.
  • the convergence time in the event of breakdowns for an air traffic management application can be for example between one and five seconds.
  • This convergence period corresponds to the period of sending the MAC messages, that is to say a MAC message is then sent every ⁇ t, ⁇ t being for example between 1 and 5 seconds.
  • the sending of the records A, C updated by the multicast link 4 is done at any time, in particular regardless of the periods of convergence of the records.
  • the master sends the MAC message and then starts the convergence transactions between the master and the clients: tests on the versions of the received recordings, request for re-transmission of the not received recordings, with or without iteration.
  • all the databases 10 converge. They are identical, they have the same version.
  • a method according to the invention does not manage records history, it only manages the latest version. In particular, if there are 10, 100 or even 1000 machines in a network, or even more, the performances are the same. The response times are not related to the numbers of the machines, in particular since the version tests (1), (2) are decentralized in each machine and the retransmissions after the re-transmission requests made in parallel are made by convergence period to all multicast machines.
  • the version tests (1), (2) are decentralized in each machine and the retransmissions after the re-transmission requests made in parallel are made by convergence period to all multicast machines.
  • FIGS. 3 and 6 only one server has been represented. An application can obviously use multiple servers. This is particularly the case for an air traffic management system where the system may include a server dedicated to flight plans, a server dedicated to meteorological data, a server dedicated to runway data, etc. ...
  • each of these servers writes the corresponding records to the database 10.
  • the server 1 and the master 31 are two separate machines. Nevertheless, it is possible to provide applications where the master 31 is also at the origin of the updating of the data. In other words, the same machine can be both master and writer, a writer being at the origin of the writing or the modification of a data or a recording.
  • the invention has been described for an air traffic management system, but it can still apply for many other systems comprising networked machines that use the same database.

Landscapes

  • Engineering & Computer Science (AREA)
  • Databases & Information Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Computing Systems (AREA)
  • Data Mining & Analysis (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Computer And Data Communications (AREA)

Abstract

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. Les machines (1, 2, 3) partagent une même base de données (10), la base (10) étant dupliquée dans les machines. Une machine (1) d'origine transmet une donnée (A) mise à jour dans sa base de données vers les autres machines (2, 3 ). Une machine maître (31) fait converger entre elles les bases de données (10), à 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 et l'adresse 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 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. L'invention 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.

Description

PROCEDE DE DUPLICATION D'UNE BASE DE DONNEES
DANS UN RESEAU DE MACHINES ETSYSTEME DE MACHINESABASE 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. Il 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 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 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 œuvre 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 œuvre 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 œuvre 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 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 < Cpt Amaître ( 1 )
où Cpt Amachine est le compteur de l'enregistrement A dans la machine et Cpt Amaître est le compteur de l'enregistrement A dans le message MAC envoyé par le maître.
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) 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 non-ré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. Il 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 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. II 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. 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, Δt é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é-émission effectué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.

Claims

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, 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 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 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 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.
PCT/EP2005/056446 2004-12-07 2005-12-02 Procede de duplication d'une base de donnees dans un reseau de machines et systeme de machines a base de donnees dupliquee WO2006061358A1 (fr)

Priority Applications (3)

Application Number Priority Date Filing Date Title
US11/721,149 US20100131465A1 (en) 2004-12-07 2005-12-02 Method for duplicating a database in a network of machines, and system of machines comprising a duplicated database
CA002591909A CA2591909A1 (fr) 2004-12-07 2005-12-02 Procede de duplication d'une base de donnees dans un reseau de machines et systeme de machines a base de donnees dupliquee
EP05846003A EP1825408A1 (fr) 2004-12-07 2005-12-02 Procede de duplication d'une base de donnees dans un reseau de machines et systeme de machines a base de donnees dupliquee

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR04/13020 2004-12-07
FR0413020A FR2879056B1 (fr) 2004-12-07 2004-12-07 Procede de duplication d'une base de donnees dans un reseau de machines et systeme de machines a base de donnees dupliquee

Publications (1)

Publication Number Publication Date
WO2006061358A1 true WO2006061358A1 (fr) 2006-06-15

Family

ID=34952878

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/EP2005/056446 WO2006061358A1 (fr) 2004-12-07 2005-12-02 Procede de duplication d'une base de donnees dans un reseau de machines et systeme de machines a base de donnees dupliquee

Country Status (5)

Country Link
US (1) US20100131465A1 (fr)
EP (1) EP1825408A1 (fr)
CA (1) CA2591909A1 (fr)
FR (1) FR2879056B1 (fr)
WO (1) WO2006061358A1 (fr)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2008141588A1 (fr) * 2007-05-23 2008-11-27 Tencent Technology (Shenzhen) Company Limited Procédé et dispositif servant à mettre à jour des contenus de réseau
WO2014173240A1 (fr) * 2013-04-25 2014-10-30 中兴通讯股份有限公司 Procédé, dispositif et système de traitement d'informations de configuration concernant un signal de référence

Families Citing this family (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101765831B (zh) * 2007-06-06 2012-10-17 雅典娜电信实验有限公司 数据库不一致的处理方法
AT507204B1 (de) * 2008-10-09 2010-03-15 Frequentis Ag Verfahren sowie anlage zur verteilung von einlangenden daten
CN103324716B (zh) * 2013-06-25 2016-08-10 四川九洲电器集团有限责任公司 一种基于安卓系统的应用程序数据库更新方法
US10614045B2 (en) 2018-01-02 2020-04-07 International Business Machines Corporation In-flight processing of operations in a role mutable file system
US10884985B2 (en) 2018-01-02 2021-01-05 International Business Machines Corporation Role mutable file system

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5924096A (en) * 1997-10-15 1999-07-13 Novell, Inc. Distributed database using indexed into tags to tracks events according to type, update cache, create virtual update log on demand
US5999931A (en) * 1997-10-17 1999-12-07 Lucent Technologies Inc. Concurrency control protocols for management of replicated data items in a distributed database system
US6516327B1 (en) * 1998-12-24 2003-02-04 International Business Machines Corporation System and method for synchronizing data in multiple databases
US20030101185A1 (en) * 2001-11-16 2003-05-29 Inventec Corporation Method for synchronously updating screen data of database application program at clients over network

Family Cites Families (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5870765A (en) * 1996-10-09 1999-02-09 Oracle Corporation Database synchronizer
US6820088B1 (en) * 2000-04-10 2004-11-16 Research In Motion Limited System and method for synchronizing data records between multiple databases
US6898642B2 (en) * 2000-04-17 2005-05-24 International Business Machines Corporation Synchronous collaboration based on peer-to-peer communication
WO2001084377A2 (fr) * 2000-05-04 2001-11-08 Kickfire, Inc. Systeme et procede de depot d'informations pour un systeme de portail internet
US20040153473A1 (en) * 2002-11-21 2004-08-05 Norman Hutchinson Method and system for synchronizing data in peer to peer networking environments
US20050050142A1 (en) * 2003-08-28 2005-03-03 Aligo Inc. Method and framework for transaction synchronization
US7154862B2 (en) * 2003-12-31 2006-12-26 Openpeak Inc. Device control system, method, and apparatus for server-based or peer-to-peer network environments
US20060031323A1 (en) * 2004-06-29 2006-02-09 International Business Machines Corporation Systems, methods, and media for database synchronization on a network

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5924096A (en) * 1997-10-15 1999-07-13 Novell, Inc. Distributed database using indexed into tags to tracks events according to type, update cache, create virtual update log on demand
US5999931A (en) * 1997-10-17 1999-12-07 Lucent Technologies Inc. Concurrency control protocols for management of replicated data items in a distributed database system
US6516327B1 (en) * 1998-12-24 2003-02-04 International Business Machines Corporation System and method for synchronizing data in multiple databases
US20030101185A1 (en) * 2001-11-16 2003-05-29 Inventec Corporation Method for synchronously updating screen data of database application program at clients over network

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2008141588A1 (fr) * 2007-05-23 2008-11-27 Tencent Technology (Shenzhen) Company Limited Procédé et dispositif servant à mettre à jour des contenus de réseau
WO2014173240A1 (fr) * 2013-04-25 2014-10-30 中兴通讯股份有限公司 Procédé, dispositif et système de traitement d'informations de configuration concernant un signal de référence

Also Published As

Publication number Publication date
US20100131465A1 (en) 2010-05-27
EP1825408A1 (fr) 2007-08-29
FR2879056A1 (fr) 2006-06-09
FR2879056B1 (fr) 2007-04-20
CA2591909A1 (fr) 2006-06-15

Similar Documents

Publication Publication Date Title
US7624155B1 (en) Data replication facility for distributed computing environments
US7571215B2 (en) Data replication protocol
WO2006061358A1 (fr) Procede de duplication d&#39;une base de donnees dans un reseau de machines et systeme de machines a base de donnees dupliquee
US6012085A (en) Apparatus and method for increased data access in a network file object oriented caching system
US7111057B1 (en) Method and system for purging content from a content delivery network
US7603454B2 (en) System and method for clustered tunneling of requests in application servers and transaction-based systems
US20030023898A1 (en) Layered architecture for data replication
US8850056B2 (en) Method and system for managing client-server affinity
US20110238814A1 (en) Method for creating global distributed namespace
US20030126133A1 (en) Database replication using application program event playback
US7555558B1 (en) Method and system for fault-tolerant transfer of files across a network
US20070288915A1 (en) Side by side for web services
EP1797696A1 (fr) Procede et systeme de resolution dns distribuee
US20060168145A1 (en) Method for creating a secure and reliable content distribution framework
EP1782597A1 (fr) Procede de fourniture de fonction de serveur fiable comme support de service ou de serie de services
US20040003007A1 (en) Windows management instrument synchronized repository provider
JP2005182251A (ja) バックアップシステム及び方法並びにプログラム
EP1085725B1 (fr) Procédé pour faire communiquer un utilisateur avec au moins une base de données.
WO2015145382A1 (fr) Composant electronique a reponse deterministe
AU2002355086A2 (en) Data replication protocol
AU2002355086A1 (en) Data replication protocol
JP3304365B2 (ja) メッセージ通信制御方法および通信システム
CN114697201A (zh) 一种基于应用客户端代理请求的数据处理方法及装置
EP2273759B1 (fr) Réplication optimisée dans un réseau pair-à-pair
US7475160B1 (en) Method and apparatus for a rumor based protocol for distributed state synchronization between request routing servers

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A1

Designated state(s): AE AG AL AM AT AU AZ BA BB BG BR BW BY BZ CA CH CN CO CR CU CZ DE DK DM DZ EC EE EG ES FI GB GD GE GH GM HR HU ID IL IN IS JP KE KG KM KN KP KR KZ LC LK LR LS LT LU LV LY MA MD MG MK MN MW MX MZ NA NG NI NO NZ OM PG PH PL PT RO RU SC SD SE SG SK SL SM SY TJ TM TN TR TT TZ UA UG US UZ VC VN YU ZA ZM ZW

AL Designated countries for regional patents

Kind code of ref document: A1

Designated state(s): BW GH GM KE LS MW MZ NA SD SL SZ TZ UG ZM ZW AM AZ BY KG KZ MD RU TJ TM AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HU IE IS IT LT LU LV MC NL PL PT RO SE SI SK TR BF BJ CF CG CI CM GA GN GQ GW ML MR NE SN TD TG

121 Ep: the epo has been informed by wipo that ep was designated in this application
WWE Wipo information: entry into national phase

Ref document number: 11721149

Country of ref document: US

Ref document number: 2591909

Country of ref document: CA

NENP Non-entry into the national phase

Ref country code: DE

WWE Wipo information: entry into national phase

Ref document number: 2005846003

Country of ref document: EP

WWP Wipo information: published in national office

Ref document number: 2005846003

Country of ref document: EP