EP1959639A1 - Fail safe system for managing client-server communication - Google Patents
Fail safe system for managing client-server communication Download PDFInfo
- Publication number
- EP1959639A1 EP1959639A1 EP08009257A EP08009257A EP1959639A1 EP 1959639 A1 EP1959639 A1 EP 1959639A1 EP 08009257 A EP08009257 A EP 08009257A EP 08009257 A EP08009257 A EP 08009257A EP 1959639 A1 EP1959639 A1 EP 1959639A1
- Authority
- EP
- European Patent Office
- Prior art keywords
- broker
- backup
- primary
- journal
- client
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Granted
Links
- 238000004891 communication Methods 0.000 title claims description 29
- 230000015654 memory Effects 0.000 claims abstract description 70
- 238000000034 method Methods 0.000 claims abstract description 13
- 230000008569 process Effects 0.000 claims abstract description 10
- 238000012545 processing Methods 0.000 claims description 23
- 230000004044 response Effects 0.000 claims description 19
- 230000002085 persistent effect Effects 0.000 claims description 11
- 230000006870 function Effects 0.000 claims description 10
- 238000012360 testing method Methods 0.000 claims description 9
- 230000008859 change Effects 0.000 claims description 5
- 238000001914 filtration Methods 0.000 claims description 2
- 238000012546 transfer Methods 0.000 description 6
- 241001136792 Alle Species 0.000 description 5
- 230000009471 action Effects 0.000 description 5
- 238000003491 array Methods 0.000 description 5
- LAXBNTIAOJWAOP-UHFFFAOYSA-N 2-chlorobiphenyl Chemical compound ClC1=CC=CC=C1C1=CC=CC=C1 LAXBNTIAOJWAOP-UHFFFAOYSA-N 0.000 description 4
- 101710149812 Pyruvate carboxylase 1 Proteins 0.000 description 4
- 230000005540 biological transmission Effects 0.000 description 4
- NMWSKOLWZZWHPL-UHFFFAOYSA-N 3-chlorobiphenyl Chemical compound ClC1=CC=CC(C=2C=CC=CC=2)=C1 NMWSKOLWZZWHPL-UHFFFAOYSA-N 0.000 description 3
- 102000004137 Lysophosphatidic Acid Receptors Human genes 0.000 description 3
- 108090000642 Lysophosphatidic Acid Receptors Proteins 0.000 description 3
- 101001082832 Saccharomyces cerevisiae (strain ATCC 204508 / S288c) Pyruvate carboxylase 2 Proteins 0.000 description 3
- 230000007246 mechanism Effects 0.000 description 3
- 238000005192 partition Methods 0.000 description 3
- 230000000903 blocking effect Effects 0.000 description 2
- 230000000694 effects Effects 0.000 description 2
- 238000007726 management method Methods 0.000 description 2
- 230000001360 synchronised effect Effects 0.000 description 2
- XOMKZKJEJBZBJJ-UHFFFAOYSA-N 1,2-dichloro-3-phenylbenzene Chemical compound ClC1=CC=CC(C=2C=CC=CC=2)=C1Cl XOMKZKJEJBZBJJ-UHFFFAOYSA-N 0.000 description 1
- JAYCNKDKIKZTAF-UHFFFAOYSA-N 1-chloro-2-(2-chlorophenyl)benzene Chemical compound ClC1=CC=CC=C1C1=CC=CC=C1Cl JAYCNKDKIKZTAF-UHFFFAOYSA-N 0.000 description 1
- FPWNLURCHDRMHC-UHFFFAOYSA-N 4-chlorobiphenyl Chemical compound C1=CC(Cl)=CC=C1C1=CC=CC=C1 FPWNLURCHDRMHC-UHFFFAOYSA-N 0.000 description 1
- 101100084627 Neurospora crassa (strain ATCC 24698 / 74-OR23-1A / CBS 708.71 / DSM 1257 / FGSC 987) pcb-4 gene Proteins 0.000 description 1
- 230000008901 benefit Effects 0.000 description 1
- 238000006880 cross-coupling reaction Methods 0.000 description 1
- 238000013144 data compression Methods 0.000 description 1
- 238000013523 data management Methods 0.000 description 1
- 230000001934 delay Effects 0.000 description 1
- 230000001419 dependent effect Effects 0.000 description 1
- 238000002955 isolation Methods 0.000 description 1
- 238000012423 maintenance Methods 0.000 description 1
- 238000005457 optimization Methods 0.000 description 1
- 150000003071 polychlorinated biphenyls Chemical class 0.000 description 1
- 238000011084 recovery Methods 0.000 description 1
- 230000009467 reduction Effects 0.000 description 1
- 238000012384 transportation and delivery Methods 0.000 description 1
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
- G06F11/16—Error detection or correction of the data by redundancy in hardware
- G06F11/20—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements
- G06F11/202—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements where processing functionality is redundant
- G06F11/2038—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements where processing functionality is redundant with a single idle spare processing component
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
- G06F11/16—Error detection or correction of the data by redundancy in hardware
- G06F11/20—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements
- G06F11/2097—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements maintaining the standby controller/processing unit updated
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/2866—Architectures; Arrangements
- H04L67/288—Distributed intermediate devices, i.e. intermediate devices for interaction with other intermediate devices on the same level
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/50—Network services
- H04L67/56—Provisioning of proxy services
- H04L67/59—Providing operational support to end devices by off-loading in the network or by emulation, e.g. when they are unavailable
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
- G06F11/16—Error detection or correction of the data by redundancy in hardware
- G06F11/20—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements
- G06F11/202—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements where processing functionality is redundant
- G06F11/2046—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements where processing functionality is redundant where the redundant components share persistent storage
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
- G06F11/16—Error detection or correction of the data by redundancy in hardware
- G06F11/20—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements
- G06F11/202—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements where processing functionality is redundant
- G06F11/2048—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements where processing functionality is redundant where the redundant components share neither address space nor persistent storage
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/01—Protocols
- H04L67/10—Protocols in which an application is distributed across nodes in the network
- H04L67/1095—Replication or mirroring of data, e.g. scheduling or transport for data synchronisation between network nodes
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/50—Network services
- H04L67/56—Provisioning of proxy services
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
- H04L69/40—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass for recovering from a failure of a protocol instance or entity, e.g. service redundancy protocols, protocol state redundancy or protocol service redirection
Definitions
- the present invention relates to a fail-safe system for managing client-server communication.
- Client-server networks are ubiquitous in computing today. As a client, it considers any type of subscriber on the network who makes a request for a service that is provided on the network.
- a server is a participant in a network that provides a service to clients on the network.
- a client may be an application program that requests data from a server in the form of a database.
- the management of the communication between a plurality of clients and servers is particularly difficult if the participants of the network are heterogeneous, i. use different software and / or hardware. For example, there are a variety of different operating systems and network protocols that can be used by the clients and / or servers of a network. Also on the hardware side, variations are conceivable both in the clients, as well as in the servers and the network architecture.
- Fig. 1 schematically shows the from the EP 0 600 235 B1 known arrangement of the broker 20 in a heterogeneous network of clients 10a-d and servers 12a-d.
- Systems known from the prior art such as, for example, a RAID system, enable fail-safe storage of data stored permanently (on a hard disk or the like).
- Data residing in volatile memory i. the typical main memory of a computer system, but irretrievably lost in a crash of the system.
- the above-mentioned function of the broker entails that essential components of the communication between the clients and the servers of the network are handled in the volatile memory, the so-called memory pool of the broker.
- a backup of the permanently stored data of the broker can therefore at best partially solve the problem of reliability.
- the present invention is therefore based on the problem of providing a fail-safe system for managing client-server communication, so that the data stored in a volatile memory of a broker for communication between the clients and the servers in case of failure of the broker essentially not get lost.
- a system for managing communication between at least one client and at least one server having a primary broker that has a first volatile memory and that manages at least one request of the at least one client at the at least one server.
- the system further includes a backup broker having a second volatile memory that manages the at least one client request to the server when the primary broker has failed, the primary one Broker has a journal with entries about operations that can change the state of the first volatile memory, and sends these entries of the journal to the backup broker so that the state of the second volatile memory is substantially identical to the state of the first volatile memory ,
- the primary broker handles the communication between the clients and the servers and handles, for example, all requests from subscribers, creating the entries of the journal and sending them to the backup broker mirrors all relevant transactions there.
- the backup broker will be able to seamlessly handle all requests, regardless of whether the related data is persistent or volatile.
- the primary broker has a filter function that determines which entries are written to the journal. Accordingly, the journal does not log each modified byte, but preferably keeps in a most compact manner all relevant changes to the objects in the volatile memory of the primary broker.
- the backup broker also preferably includes a journal interpreter that handles the entries received from the primary broker so that the state of the second volatile memory is substantially identical to the state of the first volatile memory.
- a journal interpreter that handles the entries received from the primary broker so that the state of the second volatile memory is substantially identical to the state of the first volatile memory.
- the processing of the entries in the journal by the journal interpreter of the backup broker brings the second volatile memory, preferably by at least one other step, into the state substantially identical to the first volatile memory, than the step (s) performed in the primary broker for that purpose ( e).
- the effort for processing the entries is reduced in the backup broker because the second volatile memory is brought directly into the state of the first volatile memory without one or more intermediate steps possibly performed in the first volatile memory of the primary broker.
- the primary broker in response to receiving communication from a client or server, notifies the client or server of an identification of the backup broker. It is particularly preferred if each response to the request from a client has the identification of the backup broker. A failed request to the primary broker can therefore be immediately resent to the backup broker, for example, by appropriate instructions to the interface of the corresponding user program.
- the primary broker will respond to communication with the at least one client and or at least one server leading to an entry in the journal only after the backup broker has acknowledged receipt of the corresponding entry. This ensures that any relevant operation in the primary broker is first backed up for a failure before processing continues. The backup broker can therefore immediately resume processing where the primary broker has failed, if necessary.
- each request of a subscriber to the broker leading to an entry in the journal is preferably consecutively numbered, so that, for example, the duplicate sending of a message in the backup broker can be detected and prevented.
- the backup broker prefers to send a test signal to the primary broker if it has not received a new entry for a predetermined period of time.
- the Network is not additionally burdened by the constant transmission of a standby signal, but such a test is only used when the backup broker over a predetermined period of time receives no additional entry from the journal.
- the present invention relates to a computer-readable medium having instructions for providing the above-described system and a program with instructions for providing this system.
- the system according to the invention can thus be realized on the one hand by a dedicated hardware or by an appropriate software which can be loaded via a data carrier or from the Internet and installed on any hardware and software platform, which thus assumes the above-defined properties of the claimed system.
- a broker is used to manage communication among clients and servers of a network.
- Fig. 1 which are essentially the EP 0 600 235 B1 3 shows schematically the arrangement of a broker 20 in a network of a plurality of clients 10a-10d and servers 12a-12d.
- the details of the communication between the clients, the servers and the broker, in particular the commands and attributes mentioned below, which are used in the communication are in the EP 0 600 235 B1 discloses as well as the numerous administrative functions of the broker 20.
- the broker 20 in the arrangement shown is indispensable for the communication between the clients 10a-d and the servers 12a-12d. Even if the contents of a persistent store (in Fig. 1 not shown, cf. but the below explained Fig. 3 24) of the broker is secured against data loss, for example by the use of a RAID system or similar devices, in the event of a crash and the subsequent restart of the broker 20, all data that is only stored in the database is lost volatile memory, the so-called memory pool 23 (see. Fig. 3 ) of the broker 20 are stored. For many critical applications, such as the business processes of a bank, neither a temporary loss nor the loss of data is acceptable.
- Fig. 2 schematically shows an embodiment of the present invention.
- a backup broker 30 is arranged in parallel to the primary broker 20.
- further communication between the clients 10a-d and the servers 12a-12d is managed via the backup broker 30 (see dashed lines in FIG Fig. 2 ).
- Both the primary and backup broker clusters shown use two instances of identical release and patch versions of the broker, which are also essentially identically configured, that is, the dimensions for control blocks, messages, and other data contained in the EP 0 600 235 B1 individually defined, must be available in the backup broker as well as in the primary broker.
- Other resources, such as exits, used in the primary broker 20 must also exist in the backup broker 30; but they can have other names.
- Security for data management is preferably handled by a global security system (not shown).
- the persistent stores 24 and 34 used by the primary 20 and the backup broker 30, respectively may, however, be designed differently.
- All transport-specific attributes may differ as well.
- the dimensions of the two memory pools 23 and 33 and the two persistent stores 24 and 34 must be matched.
- the two brokers preferably communicate directly with each other, with data compression can be used for optimization.
- Fig. 3 shows an embodiment with two completely separate facilities for the primary and the backup broker.
- the two brokers 20 and 30 are running on separate hardware, in order to achieve maximum independence and thus reliability of the overall system.
- each broker 20, 30 has its own memory pool 23, or 33, as well as its own permanent memory 24, 34, for example in the form of a hard disk or at least a subarea thereof.
- each broker has kernel components 21 and 31 as well as transport components 22 and 32, respectively.
- Fig. 4 is shown schematically.
- a mainframe for example, an IBM z900 mainframe, two instances of the broker 50, 60.
- the two brokers are distributed to two LPAR's (logical partitions) of the mainframe.
- Reference numerals 41, 43 denote the respective z / OS operating systems.
- a heterogeneous environment is in the embodiment of Fig. 3 conceivable, for example, if the primary broker 20 and the backup broker 30 are installed on computer systems with different hardware and / or different operating systems ( Windows® , Unix, Linux, OS / 2, etc.).
- the primary broker 20 keeps a journal (not shown).
- the journal contains all the object-related activities of all threads used in the broker 20 to manage the communication with the clients 10a-d and the servers 12a-d (cf. Fig. 2 ) be used.
- the journal contains defined entries, which are necessary, for example, for processing a request of a subscriber, or for procedures such as deleting certain resources of the broker 20.
- this data is collected at broker 20 and forwarded to the backup broker via the direct communication link before responding to the subscriber. Only after receiving an acknowledgment from the backup broker 30 to the primary broker 20 is the response to the request sent to the subscriber.
- the responsible journal is a corresponding data buffer, which is filled with the necessary information, preferably in binary form. Since this information describes in detail all the actions performed in the primary broker 20 that are relevant to the memory pool 23, after a transfer of the entries to the backup broker 30 and the simplified processing explained below, the memory pool 33 is essentially in the same state as the memory pool 23.
- journal entry Not all operations in the primary broker 20 result in a journal entry. For example, updated timestamps of individual operations that are necessary for the generation of statistics are not necessarily forwarded to the backup broker 30, since the replay mechanism in the backup broker performs these actions autonomously when processing the journal entries. Various time stamps do not have to be transferred. Likewise, for example internal default values preferably set independently by the backup broker and not transmitted as journal entries, since these values are identical in every broker of the same version.
- Information requests for example, to the kernel version of the primary broker 20 or to the last "unit of work" of a participant are purely informative and do not require any mirroring in the backup broker 30.
- a RECEIVE with which a participant communicates to the primary broker 20 its readiness to receive data is preferably not mirrored until a response is generated.
- the fact that a subscriber is in a wait state remains unimportant to the backup broker 30. Only the delivery of a RECEIVE response should be forwarded to the backup broker 30, because the request counter in the primary broker 20 has changed, or the arrangement of messages in a conversation may have been modified if, for example, the oldest message read has been deleted is.
- Requests from subscribers to internal services of the broker 20 will not be logged unless they modify the data structure of the memory pool 23, e.g. a SHUTDOWN SERVER, or a SUBSCRIBE TOPIC.
- a SHUTDOWN SERVER e.g. a SHUTDOWN SERVER
- SUBSCRIBE TOPIC e.g. a SUBSCRIBE TOPIC
- all non-conversational, non-permanently stored requests are filtered out, since an application in the event of a failure of the broker 20 can repeat the request.
- Crucial to this classification is the fact that the expense of mirroring this information is disproportionate to the benefit of nonconversational applications. The entire system could be overburdened by a reflection of this information too much.
- journal data and the sent message itself are preferably transmitted from the primary broker 20 to the backup broker 30.
- the request of a subscriber is forwarded as a separate unit following the journal data.
- the procedure is analogous to the function SEND_PUBLICATION.
- This filter is active in the primary broker 20 to detect irrelevant operations, e.g. to ignore syntactically mis-formulated requests, as this does not cause any relevant change of objects in the primary broker 20, i. in the memory pool 23 or even in the permanent memory 24.
- the interpreter of the journal in the backup broker 30 generates, modifies, or deletes data objects according to the journal data.
- the interpreter is a special component of a broker that is only active in backup mode. It works single-threaded to completely trouble-free manipulate the data in the memory pool 33 of the backup broker 30 and optionally additionally adjust the permanent memory 34.
- the action sequences are optimized, as explained in more detail in the following example:
- the primary broker 20 creates all objects such as Participant Control Blocks (PCBs) for a new subscriber, Conversation Control Blocks for a new communication, Service Control Blocks, etc. at the time of their initialization.
- PCBs Participant Control Blocks
- the respective control block types are created in arrays. This ensures that, for example, all the PCBs in the memory pool 23 are physically one after the other. It is thus possible to reach each PCB control block via an index using the start address of the PCB array.
- This array is mapped to a queue, the queue of free PCBs.
- the anchor of this "free queue” points to PCB 0,
- PCB 0 points with its "next pointer” to PCB 1, which in turn points to PCB 2, etc.
- the last PCB contains as “next pointer” a 0.
- This "free PCB queue” corresponds to the physical arrangement in the memory pool 23 at the time of initialization.
- PCB 0 the free queue
- the "active PCB queue” is supplemented by the PCB 0. Since the queue was empty, PCB 0 is the only entry. The anchor points to PCB 0, the "next pointer" in PCB 0 is set to 0 to signal that there are no more PCBs. During processing, new PCBs are chained to the "active queue", and when a participant is deleted, they are also transferred back to the "free queue". After some time, the logical queues will no longer have any relation to the physical array. For example, the "free queue” might look like this:
- the anchor points to the PCB 253, whose "next pointer” points to PCB 1, whose "next pointer” in turn points to PCB 830, etc.
- the simplified processing of the journal entries in the backup broker 30 such search processes take place only in the primary broker 20.
- the primary broker 20 fails, all relevant administrative objects, but also the user data in the form of messages, Unis Of Work or Publications (which are in the EP 0 600 235 B1 more precisely defined) are available in the backup broker 30. For example, due to synchronization via journal data, a conversation in primary broker 20 also has the same CONV-ID in backup broker 30. As a result, all data relevant for the backup function is available as an exact copy in the backup broker 30.
- FIELD-KEY, FIELD-FORMAT and FIELD-VALUE can be repeated several times until FIELD-KEY EOD is set.
- the DEL-OBJ command is used without specifying FIELD * data.
- meta-objects are also valid if e.g. the context of a client is to be generated, or a conversation is assigned to a particular server.
- Abstractions such as the CREATE_CLIENT command reduce the amount of journal data, because the necessary actions are known in connection with meta-objects, and only supplementary indexes are necessary to perform the replay synchronously.
- the permanent memories 24 and 34 can also be synchronized. Such a synchronization can be achieved via the dynamic connection of the backup broker 30 to the primary broker 30 explained below, but requires effort to transfer all permanently stored data from the primary broker 20 to the backup broker 30. Since this dynamic matching can take place in isolation, is the copying or converting the permanent memory feasible also in the context of maintenance times.
- each request of a subscriber at the primary broker 20 in the response receives the ID of the backup broker 30. Therefore, in the event of failure of the primary broker 20, the request may be sent from the interface 71 directly to the backup broker 30.
- the backup broker 30 in the course of Enabled as the primary broker, detailed below, it accepts requests from participants and continues existing conversations or publications. The ID for the broker in the API will be modified accordingly.
- the primary broker 20 failure may have occurred before, during, or after the request has been processed - each request per subscriber is consecutively numbered so that duplicate sending of a message in the backup broker 30 can be discovered and prevented.
- journal entries runs in the backup broker 30, a sensor or a monitoring program (not shown), so that when exceeded a definable wait time (attribute PRIMARY-BROKER-NONACT) pings are sent to the primary broker 20 to test its availability. If the response persists within the PRIMARY BROKER NONACT, the backup broker 30 is activated, i. the rejection of the direct acceptance of normal requests from subscribers is turned off. Furthermore, the journal interpreter is stopped and normal operation as a broker begins. All subscriber requests with a consecutive number less than or equal to the number already processed will be rejected with a specific error message to avoid creating duplicate messages or duplicates.
- the interface handles the rejection of a duplicate SEND without having to notify the application. A RECEIVE is never rejected. If the message has already been delivered, the backup broker interprets the repeated request as RECEIVE LAST.
- the following section explains how to add a backup broker to a running primary broker. This process occurs, for example, when, after a primary broker failure in the manner described above, the backup broker has assumed the role of primary broker, and another backup broker is added to maintain resilience, such as the rebooted original primary broker or a third broker to serve as a new backup broker.
- the process of plugging blocks the hitherto solely acting primary broker 20 for a short period of time. Meanwhile, there is a data exchange between the primary broker 20 and the backup broker 30. For this purpose, the permanent memory is first transferred.
- the ability to transfer the persistent stored data from the memory 24 of the primary broker 20 to the persistent storage 34 of the backup broker 30 to be added allows convenient transfer of user data regardless of other operations, regardless of whether the type of persistent storage is the source or source of the target is identical or not. Even the operating systems can be different.
- the protocol for transferring the permanently stored information and the type of transmission make the transfer completely flexible.
- the messages stored in the UOW are transmitted as a binary array.
- the reconstruction of control information from the binary array is done on the destination host, e.g. Convert encoding descriptor or message lengths into local representation.
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Quality & Reliability (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
- Hardware Redundancy (AREA)
- Computer And Data Communications (AREA)
Abstract
Description
Die vorliegende Erfindung betrifft ein ausfallsicheres System zum Verwalten von Client-Server-Kommunikation.The present invention relates to a fail-safe system for managing client-server communication.
Client-Server-Netzwerke sind heutzutage allgegenwärtig in der Datenverarbeitung. Als ein Client wird dabei jede Art von Teilnehmer an dem Netzwerk betrachtet, der eine Anfrage nach einem Dienst stellt, der im Netzwerk bereitgestellt wird. Ein Server ist ein Teilnehmer eines Netzwerks, der einen Dienst für Clients im Netzwerk bereitstellt. Beispielsweise kann es sich bei einem Client um ein Anwendungsprogramm handeln, das Daten von einem Server in Form einer Datenbank anfordert.Client-server networks are ubiquitous in computing today. As a client, it considers any type of subscriber on the network who makes a request for a service that is provided on the network. A server is a participant in a network that provides a service to clients on the network. For example, a client may be an application program that requests data from a server in the form of a database.
Die Verwaltung der Kommunikation zwischen einer Vielzahl von Clients und Servern gestaltet sich insbesondere dann schwierig, wenn die Teilnehmer des Netzwerks heterogen sind, d.h. unterschiedliche Software und / oder Hardware verwenden. Beispielsweise gibt es eine Vielzahl von unterschiedlichen Betriebssystemen und Netzwerkprotokollen, die von den Clients und / oder den Servern eines Netzwerks verwendet werden können. Auch auf Seiten der Hardware sind Variationen sowohl bei den Clients, als auch bei den Servern und der Netzwerkarchitektur denkbar.The management of the communication between a plurality of clients and servers is particularly difficult if the participants of the network are heterogeneous, i. use different software and / or hardware. For example, there are a variety of different operating systems and network protocols that can be used by the clients and / or servers of a network. Also on the hardware side, variations are conceivable both in the clients, as well as in the servers and the network architecture.
Zur Überwindung dieser Schwierigkeiten ist es aus dem Stand der Technik bekannt, die Kommunikation zwischen dem / den Client(s) und dem / den Server(n) eines Netzwerks mit Hilfe eines Servicemaklers bzw. Brokers zu verwalten, so wie er in der
Da der Broker für die Kommunikation zwischen den verschiedenen Teilnehmern des Netzwerks von zentraler Bedeutung ist, kann sein Ausfall zu einem unerwünschten Datenverlust führen. Es ist daher erforderlich, einen Mechanismus bereitzustellen, mit dem ein Datenverlust verhindert oder zumindest minimiert werden kann.Since the broker is central to communication between the different participants in the network, its failure can lead to unwanted data loss. It is therefore necessary to provide a mechanism with which data loss can be prevented or at least minimized.
Aus dem Stand der Technik bekannte Systeme, wie beispielsweise ein RAID-System ermöglichen eine ausfallsichere Speicherung von dauerhaft (auf einer Festplatte o.ä.) gespeicherten Daten. Daten, die sich in einem flüchtigen Speicher befinden, d.h. dem typischen Hauptspeicher eines Computersystems, gehen jedoch bei einem Absturz des Systems unwiederbringlich verloren. Die oben erläuterte Funktion des Brokers bringt es mit sich, dass wesentliche Bestandteile der Kommunikation zwischen den Clients und den Servern des Netzwerks im flüchtigen Speicher, dem so genannten Memory Pool des Brokers, abgewickelt werden. Eine Sicherung der dauerhaft gespeicherten Daten des Brokers kann daher allenfalls teilweise das Problem der Ausfallsicherheit lösen.Systems known from the prior art, such as, for example, a RAID system, enable fail-safe storage of data stored permanently (on a hard disk or the like). Data residing in volatile memory, i. the typical main memory of a computer system, but irretrievably lost in a crash of the system. The above-mentioned function of the broker entails that essential components of the communication between the clients and the servers of the network are handled in the volatile memory, the so-called memory pool of the broker. A backup of the permanently stored data of the broker can therefore at best partially solve the problem of reliability.
Großrechner der Firma IBM bieten zu diesem Zweck den "Parallel SYSPLEX Support" an. Privilegierte Anwenderprogramme können hierbei XES (die "Cross System Extended Services") benutzen, um "Common Storage", der von verschiedenen MVS-Systemen gemeinsam verwendet werden kann, zu verwalten. Dieser gemeinsame Speicher wird über das "Cross-Coupling Facility (XCF)" zur Verfügung gestellt. Somit kann bei Ausfall einer Komponente auf einem LPAR ("Logical Partition") die Komponente auf einem anderen LPAR den Weiterbetrieb der Anwendung sicherstellen.Mainframes from IBM offer "Parallel SYSPLEX Support" for this purpose. Privileged application programs can use XES (the "Cross System Extended Services") to manage "common storage" that can be shared between different MVS systems. This shared memory is provided through the Cross-Coupling Facility (XCF). Thus, if a component fails on one LPAR ("logical partition"), the component on another LPAR can ensure the continued operation of the application.
Schließlich ist aus der
Aus der
Der vorliegenden Erfindung liegt daher das Problem zugrunde, ein ausfallsicheres System zum Verwalten von Client-Server-Kommunikation bereitzustellen, so dass auch die in einem flüchtigen Speicher eines Brokers gespeicherten Daten zur Kommunikation zwischen den Clients und den Servern bei einem Ausfall des Brokers im Wesentlichen nicht verloren gehen.The present invention is therefore based on the problem of providing a fail-safe system for managing client-server communication, so that the data stored in a volatile memory of a broker for communication between the clients and the servers in case of failure of the broker essentially not get lost.
Dieses Problem wird gelöst durch ein System zum Verwalten von Kommunikation zwischen zumindest einem Client und zumindest einem Server mit einem primären Broker, der einen ersten flüchtigen Speicher aufweist und der zumindest eine Anfrage des zumindest einen Clients bei dem zumindest einen Server verwaltet. Das System weist ferner einen Backup-Broker auf mit einem zweiten flüchtigen Speicher, der die zumindest eine Anfrage des Clients bei dem Server verwaltet, wenn der primäre Broker ausgefallen ist, wobei der primäre Broker ein Journal mit Einträgen über Vorgänge aufweist, die den Zustand des ersten flüchtigen Speicher verändern können, und diese Einträge des Journals an den Backup-Broker sendet, so dass der Zustand des zweiten flüchtigen Speichers im Wesentlichen identisch ist mit dem Zustand des ersten flüchtigen Speichers.This problem is solved by a system for managing communication between at least one client and at least one server having a primary broker that has a first volatile memory and that manages at least one request of the at least one client at the at least one server. The system further includes a backup broker having a second volatile memory that manages the at least one client request to the server when the primary broker has failed, the primary one Broker has a journal with entries about operations that can change the state of the first volatile memory, and sends these entries of the journal to the backup broker so that the state of the second volatile memory is substantially identical to the state of the first volatile memory ,
Während somit der primäre Broker die Kommunikation zwischen den Clients und den Servern abwickelt und dabei beispielsweise alle Anfragen von Teilnehmern bearbeitet, werden durch die Erzeugung der Einträge des Journals und die Versendung an den Backup-Broker alle relevanten Vorgänge dort gespiegelt. Bei einem Ausfall des primären Brokers ist der Backup-Broker aufgrund der wesentlichen Übereinstimmung der beiden flüchtigen Speicher in der Lage, unterbrechungsfrei die Bearbeitung aller Anfragen zu übernehmen, unabhängig davon, ob die damit zusammenhängenden Daten dauerhaft oder nur flüchtig gespeichert sind.Thus, while the primary broker handles the communication between the clients and the servers and handles, for example, all requests from subscribers, creating the entries of the journal and sending them to the backup broker mirrors all relevant transactions there. In the event of a primary broker failure, due to the substantial match between the two volatile stores, the backup broker will be able to seamlessly handle all requests, regardless of whether the related data is persistent or volatile.
Vorzugsweise weist der primäre Broker eine Filterfunktion auf, die festlegt, welche Einträge in das Journal geschrieben werden. Dementsprechend protokolliert das Journal nicht jedes modifizierte Byte, sondern hält vorzugsweise in einer möglichst kompakten Weise alle relevanten Änderungen der Objekte im flüchtigen Speicher des primären Brokers fest.Preferably, the primary broker has a filter function that determines which entries are written to the journal. Accordingly, the journal does not log each modified byte, but preferably keeps in a most compact manner all relevant changes to the objects in the volatile memory of the primary broker.
Der Backup-Broker weist ferner vorzugsweise einen Journal-Interpreter auf, der die vom primären Broker empfangenen Einträge abarbeitet, damit der Zustand des zweiten flüchtigen Speichers im Wesentlichen identisch ist mit dem Zustand des ersten flüchtigen Speichers. Dabei bringt die Abarbeitung der Einträge in dem Journal durch den Journal-Interpreter des Backup-Brokers den zweiten flüchtigen Speicher vorzugsweise durch zumindest einen anderen Schritt in den zum ersten flüchtigen Speicher im Wesentlichen identischen Zustand, als den / die dafür im primären Broker durchgeführten Schritt(e). Im Ergebnis wird dadurch im Backup-Broker der Aufwand zur Abarbeitung der Einträge verringert, da der zweite flüchtige Speicher direkt in den Zustand des ersten flüchtige Speichers gebracht wird, ohne einen oder mehrere Zwischenschritte, die dazu möglicherweise im ersten flüchtigen Speicher des primären Brokers durchgeführt worden sind.The backup broker also preferably includes a journal interpreter that handles the entries received from the primary broker so that the state of the second volatile memory is substantially identical to the state of the first volatile memory. In this case, the processing of the entries in the journal by the journal interpreter of the backup broker brings the second volatile memory, preferably by at least one other step, into the state substantially identical to the first volatile memory, than the step (s) performed in the primary broker for that purpose ( e). As a result, the effort for processing the entries is reduced in the backup broker because the second volatile memory is brought directly into the state of the first volatile memory without one or more intermediate steps possibly performed in the first volatile memory of the primary broker.
Vorzugsweise teilt der primäre Broker in einer Antwort auf den Empfang einer Kommunikation von einem Client oder einem Servers dem Client bzw. dem Server eine Identifizierung des Backup-Brokers mit. Besonders bevorzugt ist es, wenn jede Antwort auf die Anfrage eines Clients die Identifizierung des Backup-Brokers aufweist. Eine fehlgeschlagene Anfrage an den primären Broker kann daher unmittelbar erneut an den Backup-Broker versandt werden, beispielsweise durch entsprechende Anweisungen an die Schnittstelle des entsprechenden Anwenderprogramms.Preferably, in response to receiving communication from a client or server, the primary broker notifies the client or server of an identification of the backup broker. It is particularly preferred if each response to the request from a client has the identification of the backup broker. A failed request to the primary broker can therefore be immediately resent to the backup broker, for example, by appropriate instructions to the interface of the corresponding user program.
Vorzugsweise beantwortet der primäre Broker eine Kommunikation mit dem zumindest einen Client und oder dem zumindest einen Server, die zu einem Eintrag in dem Journal führt, erst nachdem der Backup-Broker den Empfang des entsprechenden Eintrags quittiert hat. Damit wird sichergestellt, dass jeder relevante Vorgang im primären Broker zunächst für einen Ausfall gesichert wird, bevor die Verarbeitung fortgesetzt wird. Der Backup-Broker kann daher, falls erforderlich, sofort die Bearbeitung dort fortsetzen, wo der primäre Broker ausgefallen ist.Preferably, the primary broker will respond to communication with the at least one client and or at least one server leading to an entry in the journal only after the backup broker has acknowledged receipt of the corresponding entry. This ensures that any relevant operation in the primary broker is first backed up for a failure before processing continues. The backup broker can therefore immediately resume processing where the primary broker has failed, if necessary.
Um Inkonsistenzen zu vermeiden wird vorzugsweise jede Kommunikation mit dem primären Broker, die zu einem Eintrag im Journal führt, eindeutig identifiziert. Bevorzugt wird dabei jede Anfrage eines Teilnehmers an den Broker, die zu einem Eintrag in das Journal führt, fortlaufend nummeriert, so dass beispielsweise das doppelte Senden einer Nachricht im Backup-Broker entdeckt und unterbunden werden kann.To avoid inconsistencies, it is preferable to uniquely identify any communication with the primary broker that results in an entry in the journal. In this case, each request of a subscriber to the broker leading to an entry in the journal is preferably consecutively numbered, so that, for example, the duplicate sending of a message in the backup broker can be detected and prevented.
Im Einsatz schickt der Backup-Broker bevorzugt ein Testsignal an den primären Broker, wenn er über einen vorbestimmten Zeitraum hinweg keinen neuen Eintrag empfangen hat. Anders als im oben erläuterten Stand der Technik wird das Netzwerk nicht durch das ständige Übertragen eines Bereitschaftssignals zusätzlich belastet, sondern ein solcher Test wird erst dann verwendet, wenn der Backup-Broker über einen vorbestimmten Zeitraum hinweg keinen zusätzlichen Eintrag aus dem Journal erhält.In use, the backup broker prefers to send a test signal to the primary broker if it has not received a new entry for a predetermined period of time. Unlike in the above-mentioned prior art, the Network is not additionally burdened by the constant transmission of a standby signal, but such a test is only used when the backup broker over a predetermined period of time receives no additional entry from the journal.
Weitere Ausgestaltungen des erfindungsgemäßen Systems sind in weiteren abhängigen Patentansprüchen definiert.Further embodiments of the system according to the invention are defined in further dependent claims.
Schließlich betrifft die vorliegende Erfindung ein computerlesbares Medium mit Anweisungen zur Bereitstellung des vorangehend erläuterten Systems sowie ein Programm mit Anweisungen zur Bereitstellung dieses Systems. Das erfindungsgemäße System kann somit einerseits durch eine dedizierte Hardware verwirklicht werden oder durch eine entsprechende Software, die über einen Datenträger oder aus dem Internet geladen und auf einer beliebigen Hardware- und Softwareplattform installiert werden kann, die damit die oben definierten Eigenschaften des beanspruchten Systems annimmt.Finally, the present invention relates to a computer-readable medium having instructions for providing the above-described system and a program with instructions for providing this system. The system according to the invention can thus be realized on the one hand by a dedicated hardware or by an appropriate software which can be loaded via a data carrier or from the Internet and installed on any hardware and software platform, which thus assumes the above-defined properties of the claimed system.
In der nachfolgenden detaillierten Beschreibung werden gegenwärtig bevorzugte Ausführungsbeispiele der Erfindung näher erläutert unter Bezugnahme auf die begleitenden Figuren. Diese Figuren zeigen:
- Fig. 1:
- Die Anordnung eines einzelnen Brokers nach dem Stand der Technik;
- Fig. 2:
- Eine schematische Darstellung eines Ausführungsbeispiels der vorliegenden Erfindung;
- Fig. 3:
- Eine schematische Darstellung der beiden Broker und ihrer flüchtigen und dauerhaften Speicher im Ausführungsbeispiel aus
Fig. 2 ; - Fig. 4:
- Ein Ausführungsbeispiel einer Anordnung eines ersten und eines zweiten Brokers auf einem Großrechner;
- Fig. 5:
- Eine schematische Darstellung der Schritte zur Sicherung des flüchtigen Speichers des primären Brokers; und
- Fig. 6:
- Eine schematische Darstellung der Schritte bei der Übernahme der Verwaltungsfunktion durch den Backup-Broker.
- Fig. 1:
- The arrangement of a single broker according to the prior art;
- Fig. 2:
- A schematic representation of an embodiment of the present invention;
- 3:
- A schematic representation of the two brokers and their volatile and permanent memory in the embodiment
Fig. 2 ; - 4:
- An embodiment of an arrangement of a first and a second broker on a mainframe computer;
- Fig. 5:
- A schematic representation of the steps for securing the volatile memory of the primary broker; and
- Fig. 6:
- A schematic representation of the steps taken by the backup broker to take over the management function.
Ein Broker dient der Verwaltung der Kommunikation unter Clients und Servern eines Netzwerks.
Es ist unmittelbar erkennbar, dass der Broker 20 in der gezeigten Anordnung für die Kommunikation zwischen den Clients 10a - d und den Servern 12a - 12d unverzichtbar ist. Selbst wenn der Inhalt eines dauerhaften Speichers (in
Zusätzlich zu der im Folgenden beschriebenen Anordnung mit einem primären Broker und einem Backup-Broker ist es auch denkbar einen oder mehrere weitere Backup-Broker vorzusehen, um ein noch größeres Maß an Ausfallsicherheit bereitzustellen.In addition to the primary broker and backup broker arrangement described below, it is also conceivable to provide one or more additional backup brokers to provide even greater levels of resiliency.
Vorzugsweise werden für den Betrieb des in
Die Attributdateien von primärem Broker 20 und Backup-Broker 30 sind mit Ausnahme folgender Attribute, die in der
- BROKER-ID
- NUM-WORKER
- PSTORE-TYPE
- TRACE-LEVEL
- TRANSPORT
- BROKER ID
- NUM WORKER
- Pstore TYPE
- TRACE LEVEL
- TRANSPORT
Auch alle transport-spezifischen Attribute können differieren. Für einen reibungslosen Betrieb von primärem und Backup-Broker sind die Dimensionen der beiden Memory Pools 23 und 33 und der beiden dauerhaften Speicher (persistent stores) 24 und 34 abzugleichen.All transport-specific attributes may differ as well. For a smooth operation of primary and backup brokers, the dimensions of the two
Wie in
Alternativ ist auch eine Ausführungsform dankbar, wie sie in
Eine heterogene Umgebung ist im Ausführungsbeispiel aus
Um im Ausführungsbeispiel aus
Im Falle einer Anfrage eines Teilnehmers werden diese Daten im Broker 20 gesammelt und vor einer Antwort an den Teilnehmer über die direkte Kommunikationsverbindung an den Backup-Broker weitergeleitet. Erst nach Erhalt einer Quittung vom Backup-Broker 30 an den primären Broker 20 wird die Antwort auf die Anfrage an den Teilnehmer gesendet.In the case of a request from a subscriber, this data is collected at
Dieser Vorgang ist im Detail in
- (1) Die Anfrage des Teilnehmers 70 (Client oder Server) wird über eine Schnittstelle 71, beispielsweise das in der
EP 0 600 235 B1 den primären Broker 20 gesendet. Die Transportschicht der Schnittstelle wartet in diesem Beispiel synchron auf eine Antwort vomBroker 20, d.h.der Teilnehmer 70 hält seine eigene Prozessverarbeitung solange an, bis dieAntwort vom Broker 20 eintrifft. - (2) Ebenso wie der Teilnehmer 70 weist der primäre
Broker 20Transportkomponenten 22 für die Kommunikation auf, die in den Figuren vereinfacht dargestellt sind und gemeinsammit dem Bezugszeichen 22 bezeichnet sind.Der Broker 20 stellt neben den bisher üblichen Transportkomponenten, die als Server im Sinne der jeweiligen Transportprotokolle agieren, so genannte Forwarder zur Verfügung. Sie agieren im Sinne der jeweiligen Transportprotokolle als Clients, und versetzenden primären Broker 20 in die Lage, Journal und Daten zur Anfrage eines Teilnehmers an den Backup-Broker 30 zu schicken. Der Backup-Broker 30 kann über seine Transportkomponenten 32 ein Test mit einem Bereitschaftssignal zum primärenBroker 20 senden, um zeitnah zu ermitteln, wann der primäreBroker 20 ausfällt (siehe dazu unten mehr).
Die Transportkomponenten 22 des primärenBrokers 20 übergeben die Anfrage nach vollständigem Empfang an die Kernel-Komponenten 21des Brokers 20 zur Abarbeitung. Während der Abarbeitung werden relevante Informationen im Journal (nicht dargestellt) protokolliert. - (3) Nach vollständiger Abarbeitung wird die Antwort auf die Anfrage des Teilnehmers 70 erzeugt.
- (4) Anstatt der Antwort, werden zunächst der oder die Einträge in das Journal und optional weitere Daten zur Anfrage des Teilnehmers 70 an den Backup-
Broker 30 gesendet. - (5)
Die Transportkomponenten 32 des Backup-Brokers 30 übergeben den / die Journaleintrag / - einträge und die optionalen Daten an die Kernel-Komponenten 31 zur Abarbeitung durch einen Journal-Interpreter, der weiter unten im Detail erläutert wird. Mit der Abarbeitung der Einträge wird derMemory Pool 33 des Backup-Brokers 30 im Wesentlichen in denselben Zustand gebracht wieder Memory Pool 23 des primärenBrokers 20 - (6) Nach vollständiger Abarbeitung wird ein Quittierungssignal für
den primären Broker 20 erzeugt. - (7) Das Quittierungssignal des Backup-
Brokers 30 wird anden primären Broker 20 gesendet. - (8) Die im Schritt (3) erzeugte Antwort wird an
die Schnittstelle 71 desTeilnehmers 70 gesendet und gegebenenfalls an eine Applikation übergeben.
- (1) The request of the subscriber 70 (client or server) is via an
interface 71, for example, in theEP 0 600 235 B1 primary broker 20. In this example, the transport layer of the interface waits synchronously for a response from thebroker 20, ie thesubscriber 70 stops his own process processing until the response from thebroker 20 arrives. - (2) Like the
subscriber 70, theprimary broker 20 hascommunication components 22 for communication, which are shown in simplified form in the figures and together designated by thereference numeral 22. Thebroker 20 provides so-called forwarders in addition to the usual transport components, which act as servers in the sense of the respective transport protocols. They act as clients in the sense of the respective transport protocols, and enable theprimary broker 20 to send journal and data for request of a subscriber to thebackup broker 30. Thebackup broker 30 may send a test with a ready signal to theprimary broker 20 via itstransport components 32 to promptly determine when theprimary broker 20 will fail (see below for more).
Thetransport components 22 of theprimary broker 20 submit the request for full receipt to thekernel components 21 of thebroker 20 for execution. During processing, relevant information is logged in the journal (not shown). - (3) Upon completion of the processing, the response to the request of the
subscriber 70 is generated. - (4) Instead of the reply, first the entry or entries in the journal and optionally further data for the request of the
subscriber 70 are sent to thebackup broker 30. - (5) The
transport components 32 of thebackup broker 30 provide the journal entry (s) and optional data to thekernel components 31 for processing by a journal interpreter, which will be discussed in more detail below. As the entries are processed, thememory pool 33 of thebackup broker 30 is brought into substantially the same state as thememory pool 23 of theprimary broker 20 - (6) After completion of processing, an acknowledge signal is generated for the
primary broker 20. - (7) The acknowledgment signal of the
backup broker 30 is sent to theprimary broker 20. - (8) The answer generated in step (3) is sent to the
interface 71 of thesubscriber 70 and optionally transferred to an application.
Sämtliche Anfragen der Teilnehmer, interne Timeouts, und administrative Kommandos verändern den Datenbestand im Memory Pool 23 und möglicherweise auch im nichtflüchtigen Speicher 24 des primären Brokers 20. Alle diese Aktivitäten müssen im primären Broker 20 bezüglich ihrer Relevanz für den Backup-Broker 30 untersucht werden. Sind Aktionen für den Backup-Broker 30 von Bedeutung, werden sie durch die Erstellung eines entsprechenden Eintrags protokolliert. Das dafür zuständige Journal ist ein entsprechender Datenpuffer, der mit den notwendigen Informationen, vorzugsweise in Binärform gefüllt wird. Da diese Informationen alle im primären Broker 20 durchgeführten, für den Memory Pool 23 relevanten Aktionen detailliert beschreiben, befindet sich nach einer Übertragung der Einträge zum Backup-Broker 30 und der weiter unten erläuterten, vereinfachten Abarbeitung der Memory Pool 33 im Wesentlichen im demselben Zustand wie der Memory Pool 23.All requests from the participants, internal timeouts, and administrative commands change the database in the
Nicht alle Vorgänge im primären Broker 20 führen zu einem Journaleintrag. Beispielsweise sind für die Erstellung einer Statistik notwendige aktualisierte Zeitstempel von einzelnen Vorgängen nicht notwendigerweise an der Backup-Broker 30 weiterzuleiten, da der Replay-Mechanismus im Backup-Broker diese Aktionen selbstständig beim Abarbeiten der Journaleinträge durchführt. Diverse Zeitstempel müssen also nicht übertragen werden. Ebenso werden beispielsweise interne Default-Werte vorzugsweise selbständig vom Backup-Broker gesetzt und nicht als Journaleinträge übermittelt, da diese Werte in jedem Broker gleicher Version identisch sind.Not all operations in the
Informationsanfragen beispielsweise nach der Kernelversion des primären Brokers 20 oder nach der letzten "Unit of Work" eines Participant sind rein informativ und erfordern keinerlei Spiegelung im Backup-Broker 30. Ein RECEIVE, mit dem ein Teilnehmer gegenüber dem primären Broker 20 seine Empfangsbereitschaft für Daten mitteilt, wird vorzugsweise bis zur Erzeugung einer Antwort darauf nicht gespiegelt. Ebenso bleibt bevorzugt die Tatsache, dass ein Teilnehmer im Wartezustand ist, für den Backup-Broker 30 unerheblich. Erst das Zustellen einer RECEIVE Antwort sollte an den Backup-Broker 30 weitergeleitet werden, denn der Request Counter im primären Broker 20 hat sich verändert, bzw. die Anordnung der Nachrichten in einer Conversation kann modifiziert worden sein, wenn beispielsweise die älteste gelesene Nachricht gelöscht worden ist.Information requests, for example, to the kernel version of the
Anfragen von Teilnehmern an interne Dienste des Brokers 20 werden nicht protokolliert, es sei denn, sie modifizieren die Datenstruktur des Memory Pools 23 wie z.B. ein SHUTDOWN SERVER, oder ein SUBSCRIBE TOPIC. Ebenso werden beispielsweise alle nicht-konversationalen, nicht-dauerhaft gespeicherten Anfragen herausgefiltert, da eine Applikation im Falle einer Störung des Brokers 20 die Anfrage wiederholen kann. Ausschlaggebend für diese Klassifizierung ist die Tatsache, dass der Aufwand zum Spiegeln dieser Informationen in keinem Verhältnis zum Nutzen für nicht-konversationale Anwendungen steht. Das Gesamtsystem könnte durch eine Spiegelung auch dieser Informationen zu stark belastet werden.Requests from subscribers to internal services of the
Alle benutzerbezogenen Daten werden im Journal festgehalten. LOGON, LOGOFF und alle Änderungen von Feldern im Participant Control Block (PCB, siehe dazu unten mehr) werden an den Backup-Broker 30 weitergeleitet. Fällt der primäre Broker 20 aus, ist daher der verloren gegangene Benutzerkontext im Backup-Broker 30 vollständig vorhanden.All user-related data is recorded in the journal. LOGON, LOGOFF, and any changes to fields in the Participant Control Block (PCB, see more below) are forwarded to
Komplexer werden die Anforderungen bei einem SEND. Sowohl Journaldaten als auch die gesendete Nachricht selbst werden vorzugsweise vom primären Broker 20 an den Backup-Broker 30 übertragen. In diesem Fall wird die Anfrage eines Teilnehmers im Anschluss an die Journaldaten als eigenständige Einheit weitergeleitet. Analog ist der Ablauf bei der Funktion SEND_PUBLICATION.The requirements for a SEND become more complex. Both journal data and the sent message itself are preferably transmitted from the
Die Intelligenz, zu erkennen, welche Daten im Journal geführt werden müssen, und welche nicht, ist als Filter zu betrachten. Dieser Filter ist im primären Broker 20 aktiv, um irrelevante Operationen z.B. syntaktisch falsch formulierte Anfragen nicht zu berücksichtigen, da dies keine relevante Änderung von Objekten im primären Broker 20, d.h. im Memory Pool 23 oder sogar im dauerhaften Speicher 24 nach sich zieht.The intelligence to recognize which data in the journal must be kept, and which not, should be considered as a filter. This filter is active in the
Der Interpreter des Journals im Backup-Broker 30 erzeugt, modifiziert, oder löscht Datenobjekte gemäß den Journaldaten. Der Interpreter ist eine spezielle Komponente eines Brokers, die nur im Backup-Modus aktiv ist. Sie arbeitet single-threaded, um völlig störungsfrei die Daten im Memory Pool 33 des Backup-Brokers 30 zu manipulieren und gegebenenfalls zusätzlich den dauerhaften Speicher 34 anzupassen. Die Aktionsabläufe sind dabei optimiert, wie im folgenden Beispiel näher erläutert wird:The interpreter of the journal in the
Der primäre Broker 20 erzeugt alle Objekte wie beispielsweise Participant Control Blocks (PCBs) für einen neuen Teilnehmer, Conversation Control Blocks für eine neue Kommunikation, Service Control Blocks etc. zum Zeitpunkt ihrer Initialisierung. Die jeweiligen Kontrollblocktypen werden in Arrays angelegt. Damit ist sichergestellt, dass z.B. alle PCBs im Memory Pool 23 physisch nacheinander liegen. Es ist somit möglich, über einen Index unter Zuhilfenahme der Anfangsadresse des PCB-Arrays jeden PCB-Kontrollblock zu erreichen.
Dieses Array wird auf eine Queue abgebildet, die Queue der freien PCBs. Der Anker dieser "free queue" zeigt auf PCB 0, PCB 0 zeigt mit seinem "next pointer" auf PCB 1, der wiederum auf PCB 2 usw. Der letzte PCB enthält als "next pointer" eine 0. Diese "free PCB queue" entspricht zum Zeitpunkt der Initialisierung der physikalischen Anordnung im Memory Pool 23.This array is mapped to a queue, the queue of free PCBs. The anchor of this "free queue" points to PCB 0, PCB 0 points with its "next pointer" to
Ferner gibt es eine "active PCB queue", die jedoch zum Zeitpunkt der Initialisierung des Brokers 20 noch leer ist. Soll nun für einen neuen Teilnehmer ein PCB erzeugt werden, wird der "free queue" der erste Eintrag entnommen (PCB 0), d.h. der Anker der "free queue" zeigt auf PCB 1, wobei der Rest dieser Queue unverändert bleibt.Furthermore, there is an "active PCB queue", which is still empty at the time of initialization of the
Die "active PCB queue" wird um den PCB 0 ergänzt. Da die Queue leer war, ist PCB 0 der einzige Eintrag. Der Anker zeigt auf PCB 0, der "next pointer" in PCB 0 ist auf 0 gesetzt, um zu signalisieren, dass keine weiteren PCBs vorhanden sind. Im Laufe der Verarbeitung werden neue PCBs in die "active queue" gekettet, und beim Löschen eines Teilnehmers auch wieder in die "free queue" überführt. Nach einiger Zeit haben dann die logischen Queues keinerlei Beziehung mehr zum physischen Array. Beispielsweise könnte die "free queue" so aussehen:The "active PCB queue" is supplemented by the PCB 0. Since the queue was empty, PCB 0 is the only entry. The anchor points to PCB 0, the "next pointer" in PCB 0 is set to 0 to signal that there are no more PCBs. During processing, new PCBs are chained to the "active queue", and when a participant is deleted, they are also transferred back to the "free queue". After some time, the logical queues will no longer have any relation to the physical array. For example, the "free queue" might look like this:
Der Anker zeigt auf den PCB 253, dessen "next pointer" zeigt auf PCB 1, dessen "next pointer" wiederum auf PCB 830, usw.. Dies führt dazu, dass der Broker 20, wenn er beispielsweise einen PCB mit der USER-ID "HUGO" suchen muss, er vom Anker der "active queue" ausgehend solange die logische Kette untersucht, bis die USER-ID gefunden wurde, oder das Ende der Kette erreicht wurde. Solche Suchabläufe finden jedoch aufgrund der vereinfachten Abarbeitung der Journaleinträger im Backup-Broker 30 nur im primären Broker 20 statt.The anchor points to the PCB 253, whose "next pointer" points to
Hat nämlich beispielsweise der PCB mit der USER-ID "HUGO" den Index 2000, dann bedeutet das für den Backup-Broker 30, dass er diesen PCB Index 2000 benutzen kann, ohne suchen zu müssen, denn das Journal teilt dem Backup-Broker mit, den PCB mit diesem Index zu verwenden. Im Ergebnis wird im Backup-Broker 30 jeglicher Aufwand zum Auffinden von Informationen vermieden, da das Journal Direktzugriffe formuliert.If, for example, the PCB with the USER-ID "HUGO" has the index 2000, then this means for the
Fällt der primäre Broker 20 aus, sind alle relevanten Verwaltungsobjekte, aber auch die Nutzdaten in Form von Nachrichten, Unis Of Work oder Publications (die in der
Die Journaldaten für den kontinuierlichen Datenabgleich haben vorzugsweise folgende Struktur:
- COMMAND:
- ADD_OBJ, UPD_OBJ, DEL_OBJ
- OBJECT:
- BCT, PCB, PCBEXT, SCB, SCBEXT, CCB, TOQ, ...
- OBJECT-INDEX:
- Index des Objekts
- FIELD-KEY:
- Objektspezifische Identifikationsnummern für Objektdatenfelder;
Feldformat und Feldlänge ergeben sich implizit aus dem angegebenen Feldschlüssel. - FIELD-FORMAT:
- i1|i2|i4 für Integer in Host-Order
s1|s2|sn für nicht-null-terminierte Character-Arrays in lokaler Repräsentation
x1|x2|xn für hexadezimale Werte - FIELD-VALUE:
- Wert, der im referenzierten Feld einzutragen ist.
Datenrepräsentation im Format des Quell-Hosts.
- COMMAND:
- ADD_OBJ, UPD_OBJ, DEL_OBJ
- OBJECT:
- BCT, PCB, PCBEXT, SCB, SCBEXT, CCB, TOQ, ...
- OBJECT INDEX:
- Index of the object
- FIELD-KEY:
- Object-specific identification numbers for object data fields;
Field format and field length implicitly result from the specified field key. - FIELD-FORMAT:
- i1 | i2 | i4 for integer in host order
s1 | s2 | sn for non-null-terminated character arrays in local representation
x1 | x2 | xn for hexadecimal values - FIELD-VALUE:
- Value to be entered in the referenced field.
Data representation in the format of the source host.
Die Felder FIELD-KEY, FIELD-FORMAT und FIELD-VALUE können mehrfach wiederholt werden, bis FIELD-KEY EOD gesetzt ist. Das Kommando DEL-OBJ wird ohne Angabe von FIELD-* Daten benutzt.The fields FIELD-KEY, FIELD-FORMAT and FIELD-VALUE can be repeated several times until FIELD-KEY EOD is set. The DEL-OBJ command is used without specifying FIELD * data.
Neben dieser deskriptiven Art der Protokollierung von Änderungen sind auch Meta-Objekte gültig, wenn z.B. der Kontext eines Clients erzeugt werden soll, oder eine Conversation einem bestimmten Server zugeordnet wird. Abstraktionen wie Kommando CREATE_CLIENT verkürzen die Menge der Journaldaten, da die notwendigen Aktionen im Zusammenhang mit Meta-Objekten bekannt sind, und nur ergänzende Indizes notwendig sind, um das Replay synchron durchführen zu können.In addition to this descriptive way of logging changes, meta-objects are also valid if e.g. the context of a client is to be generated, or a conversation is assigned to a particular server. Abstractions such as the CREATE_CLIENT command reduce the amount of journal data, because the necessary actions are known in connection with meta-objects, and only supplementary indexes are necessary to perform the replay synchronously.
Zusätzlich zum Datenabgleich über Journaleinträge können auch die dauerhaften Speicher 24 und 34 synchronisiert werden. Ein solcher Datenabgleich kann über die weiter unten erläuterte dynamische Zuschaltung des Backup-Brokers 30 zum primären Broker 30 erzielt werden, erfordert jedoch Aufwand zur Übertragung aller dauerhaft gespeicherten Daten vom primären Broker 20 zum Backup-Broker 30. Da dieser dynamische Abgleich isoliert ablaufen kann, ist das Kopieren bzw. Konvertieren der dauerhaften Speicher auch im Rahmen von Wartungszeiten durchführbar.In addition to the data synchronization via journal entries, the
Vorzugsweise erhält jede Anfrage eines Teilnehmers beim primären Broker 20 in der Antwort die ID des Backup-Brokers 30. Bei einem Ausfall des primären Brokers 20 kann daher die Anfrage von der Schnittstelle 71 unmittelbar zum Backup-Broker 30 gesendet werden. Sobald der Backup-Broker 30 im Zuge des weiter unten in Detail erläuterten Vorgangs als primärer Broker aktiviert ist, akzeptiert er Anfragen von Teilnehmern und setzt bestehende Konversationen oder Publikationen fort. Die ID für den Broker im API wird entsprechend modifiziert.Preferably, each request of a subscriber at the
Um das Duplizieren einer Anfrage eines Teilnehmers zu vermeiden - der Ausfall des primären Brokers 20 kann vor, während, oder nach der Bearbeitung der Anfrage eingetreten sein -, wird jede Anfrage pro Teilnehmer fortlaufend nummeriert, sodass das doppelte Senden einer Nachricht im Backup-Broker 30 entdeckt und unterbunden werden kann.In order to avoid duplicating a subscriber request - the
Die Übernahme der Funktion als Broker durch den Backup-Broker 30 verläuft wie folgt: Parallel zum oben erläuterten effizienten Abarbeiten der vom primären Broker 20 weitergeleiteten Journaleinträge läuft im Backup-Broker 30 ein Sensor bzw. ein Überwachungsprogramm (nicht dargestellt), so dass bei Überschreitung einer definierbaren Wartezeit (Attribut PRIMARY-BROKER-NONACT) Pings an den primären Broker 20 gesendet werden, um dessen Verfügbarkeit zu testen. Bleibt die Antwort innerhalb der PRIMARY-BROKER-NONACT aus, wird der Backup-Broker 30 aktiviert, d.h. die Zurückweisung der direkten Annahme von normalen Anfragen von Teilnehmern wird abgeschaltet. Ferner wird der Journal-Interpreter gestoppt, und der Normalbetrieb als Broker beginnt. Alle Teilnehmeranfragen mit einer fortlaufenden Nummer, die kleiner oder gleich der bereits verarbeiteten Nummer ist, werden mit einer speziellen Fehlermeldung abgewiesen, um das Erzeugen doppelter Nachrichten oder ähnliche Verdopplungen zu vermeiden.The assumption of the function as a broker by the
Die Schnittstelle behandelt das Zurückweisen eines doppelten SEND ohne die Applikation informieren zu müssen. Ein RECEIVE wird nie zurückgewiesen. War die Nachricht bereits zugestellt worden, interpretiert der Backup-Broker die wiederholte Anfrage als RECEIVE LAST.The interface handles the rejection of a duplicate SEND without having to notify the application. A RECEIVE is never rejected. If the message has already been delivered, the backup broker interprets the repeated request as RECEIVE LAST.
- (1)
Die Schnittstelle 71der Applikation 70 verwendet die ID des primärenBrokers 20 für die Adressierung einer Anfrage. - (2) Nach Abarbeitung der Anfrage wird von der Transport-
Komponente 22 des primärenBrokers 20 die Antwort andie Schnittstelle 71 gesendet. Die Antwort enthält auch die Adresse des verfügbaren Backup-Brokers 30. - (3) Die Verbindung
zum primären Broker 20 ist unterbrochen. Der Backup-Broker 30 empfängt keine Journaleinträge mehr. Nach dem Erreichen des Wertes PRIMARY-BROKER-NONACT wird ein Ping vom Backup-Broker 30 anden primären Broker 20 gesendet. Bleibt der Ping für die PRIMARY-BROKER-NONACT Zeit unbeantwortet, leitet der Backup-Broker 30 das Notfallprogramm ein. Dazu führt der Backup-Broker 30 eine Übernahmesequenz durch, die ihn als primären Broker aktiviert. Dies beinhaltet das Akzeptieren aller Verbindungsaufforderungen und das Abarbeiten von Anfragen der Teilnehmer. Wenn zu diesem Zeitpunkt kein weiterer Backup-Broker existiert, unterbleibt jegliche Kontaktaufnahme zur Sicherung der Datenim flüchtigen Speicher 33. - (4) Da der primäre
Broker 20 nicht mehr erreichbar ist, tauscht dieSchnittstelle 71 die ID für den Broker aus und versucht den Backup-Broker 30 zu kontaktieren. Nach erfolgreicher Übernahme ist der Backup-Broker 30 funktionsbereit, und akzeptiert die Teilnehmer-anfrage. - (5) Nach Abarbeitung der Teilnehmeranfrage wird von der Transport-
Komponente 32 des Backup-Broker 30 die Antwort andie Schnittstelle 71 gesendet. Diese Antwort enthält keine Adresse eines neuen Backup-Brokers, es sei denn, zwischenzeitlich erfolgte der weiter unten beschriebene Start eines weiteren Backup-Brokers.
- (1) The
interface 71 of theapplication 70 uses the ID of theprimary broker 20 for addressing a request. - (2) After the request has been processed, the response is sent to the
interface 71 by thetransport component 22 of theprimary broker 20. The response also includes the address of theavailable backup broker 30. - (3) The connection to the
primary broker 20 is broken. Thebackup broker 30 no longer receives journal entries. Upon reaching the PRIMARY-BROKER-NONACT value, a ping is sent from thebackup broker 30 to theprimary broker 20. If the ping for the PRIMARY-BROKER-NONACT time remains unanswered, thebackup broker 30 initiates the emergency program. To do this, thebackup broker 30 performs a takeover sequence that activates it as a primary broker. This includes accepting all connection requests and processing requests from the participants. If no other backup broker exists at this time, any contact to backup the data involatile memory 33 is lost. - (4) Since the
primary broker 20 is no longer reachable, theinterface 71 exchanges the ID for the broker and tries to contact thebackup broker 30. After successful acceptance, thebackup broker 30 is ready to work and accepts the subscriber request. - (5) After the subscriber request has been processed, the response is sent to the
interface 71 by thetransport component 32 of thebackup broker 30. This response does not include the address of a new backup broker, unless in the meantime the launch of another backup broker, described below, has occurred.
Im Folgenden wird das Hinzufügen eines Backup-Brokers zu einem laufenden primären Broker erläutert. Dieser Vorgang erfolgt beispielsweise, wenn nach einem Ausfall eines primären Brokers in der oben beschriebenen Weise der Backup-Broker die Rolle des primären Brokers übernommen hat und nun zur Aufrechterhaltung der Ausfallsicherheit ein weiterer Backup-Broker hinzugefügt wird, beispielsweise der erneut gestartete ursprünglich primäre Broker oder ein dritter Broker, der als neuer Backup-Broker dienen soll.The following section explains how to add a backup broker to a running primary broker. This process occurs, for example, when, after a primary broker failure in the manner described above, the backup broker has assumed the role of primary broker, and another backup broker is added to maintain resilience, such as the rebooted original primary broker or a third broker to serve as a new backup broker.
Der Vorgang des Dazuschaltens blockiert den bis dahin allein agierenden primären Broker 20 für einen kurzen Zeitraum. Währendessen erfolgt ein Datenaustausch zwischen dem primären Broker 20 und dem Backup-Broker 30. Dazu wird zunächst der dauerhafte Speicher übertragen.The process of plugging blocks the hitherto solely acting
Die Möglichkeit des Übertragens der dauerhaft gespeicherten Daten vom Speicher 24 des primären Brokers 20 zum dauerhaften Speicher 34 des hinzuzufügenden Backup-Brokers 30 erlaubt unabhängig von anderen Vorgängen, Benutzerdaten bequem zu transferieren, wobei es unerheblich ist, ob der Typ des dauerhaften Speichers der Quelle und des Ziels identisch ist oder nicht. Selbst die Betriebssysteme können unterschiedlich sein. Das Protokoll zur Übertragung der dauerhaft zu speichernden Informationen und die Art der Übertragung machen den Transfer völlig flexibel.The ability to transfer the persistent stored data from the
Danach erfolgt die Übertragung aller relevanten Daten aus dem Memory Pool 23. Ähnlich wie beim fortlaufenden Journal, werden zu diesem Zweck die Datenbestände im Memory Pool 23 über ein Komplett-Journal an den Backup-Broker 30 gesendet. Ein Komplett-Journal ist deshalb erforderlich, weil der gesamte Memory Pool 23 analysiert und ggf. abgeglichen werden muss. Da diese Vorgänge ein in sich konsistentes System erfordern, darf während der Synchronisierung des primären Brokers 20 mit dem Backup-Broker 30 keine Teilnehmeranfrage bearbeitet werden.Thereafter, the transmission of all relevant data from the
Das Transfer-Prokoll der für die dauerhaft gespeicherten Daten übertragt die Units Of Work unter Zuhilfenahme des Journal-Protokolls:
- COMMAND:
- ADD_OBJ
- OBJECT:
- UOW
- OBJECT-INDEX:
- Index des Objekts
- FIELD-KEY:
- Objektspezifische Identifikationsnummern für Obj ektdatenfelder;
Feldformat und Feldlänge ergeben sich implizit aus dem angegebenen Feldschlüssel. - FIELD-FORMAT:
- i1|i2|i4 für Integer in Host-Order
s1|s2|sn für nicht-null-terminierte Character-Arrays in lokaler Repräsentation
x1|x2|xn für hexadezimale Werte - FIELD-VALUE:
- Wert, der im referenzierten Feld einzutragen ist.
Datenrepräsentation im Format des Quell-Hosts.
- COMMAND:
- ADD_OBJ
- OBJECT:
- UOW
- OBJECT INDEX:
- Index of the object
- FIELD-KEY:
- Object-specific identification numbers for object data fields;
Field format and field length implicitly result from the specified field key. - FIELD-FORMAT:
- i1 | i2 | i4 for integer in host order
s1 | s2 | sn for non-null-terminated character arrays in local representation
x1 | x2 | xn for hexadecimal values - FIELD-VALUE:
- Value to be entered in the referenced field.
Data representation in the format of the source host.
Die in der UOW abgelegten Nachrichten werden als ein Binärarray übertragen. Die Rekonstruktion von Kontrollinformationen aus dem Binärarray erfolgt auf dem Ziel-Host, um z.B. Encoding-Descriptor oder Nachrichtenlängen in die lokale Repräsentation umzuwandeln.The messages stored in the UOW are transmitted as a binary array. The reconstruction of control information from the binary array is done on the destination host, e.g. Convert encoding descriptor or message lengths into local representation.
Abschließend wird noch die Vorgehensweise zum Start und zum Anhalten des Clusterbetriebs des primären Brokers 20 und des Backup-Brokers 30 erläutert. Sollen beide Instanzen des Brokers annähernd zeitgleich aktiviert werden, sind folgende Schritte notwendig:Finally, the procedure for starting and stopping the cluster operation of the
Der primäre Broker 20 wird mit "RUN-MODE = PRIMARY" gestartet. Zusätzlich wird über "PARTNER = broker_id" die Transportadresse des Backup-Brokers 30 in der Attributdatei definiert. Nach dem Startup des primären Brokers 20 wird versucht, den Partner zu kontaktieren. Solange der Backup-Broker 30 nicht antwortet, ist der primäre Broker 20 für Teilnehmeranfragen nicht verfügbar.The
Der Backup-Broker 30 wird mit "RUN-MODE = BACKUP" gestartet. Zusätzlich wird über "PARTNER = broker_id" die Transportadresse des primären Brokers 20 in der Attributdatei definiert. Nach dem Startup des Backup-Brokers 30 wird versucht, den Partner zu kontaktieren. Solange der primäre Broker 20 nicht antwortet, bleibt der Backup-Broker 30 in Wartestellung. Diese Verzögerungen führen jedoch nicht zu einer Übernahme der Rolle des primären Brokers 30.The
Nach dem Handshake beider Broker 20, 30 wird ermittelt, ob der Backup-Broker 30 zunächst synchronisiert werden muss, oder ob beide für den Cluster-Betrieb mit Journal basiertem Update bereit sind. Ist eine Synchronisierung erforderlich, sind die oben erläuterten Schritte zu absolvieren, die beim dynamischen Hinzufügen eines Backup-Brokers 30 notwendig sind.After the handshake of both
Zum Anhalten der beiden Broker werden bevorzugt die folgenden Sequenzen durchgeführt:
- Gemeinsames Stoppen von primärem 20 und Backup-Broker 30 (Kommando SHUTDOWN_CLUSTER):
- (1) Der PARTNER Broker wird vom bevorstehenden SHUTDOWN in Kenntnis gesetzt.
- (2)
Der primäre Broker 20 akzeptiert keine neuen Anfragen mehr. - (3) Der Backup-
Broker 30 arbeitet alle noch ausstehenden Journal-Sätze ab and quittiert. - (4)
Der primäre Broker 20 sendet Antworten für alle noch unbeantworteten Anfragen, bzw. unterbricht blockierende Calls. - (5)
Der primäre Broker 20 und der Backup-Broker 30 synchronisieren den gemeinsamen SHUTDOWN. - (6)
Der primäre Broker 20 und der Backup-Broker 30 stoppen.
- Stoppen des primären Brokers 20 (Kommando SHUTDOWN_BROKER):
- (1) Der Backup-
Broker 30 wird vom bevorstehenden SHUTDOWN in Kenntnis gesetzt. - (2)
Der primäre Broker 20 akzeptiert keine neuen Teilnehmeranfragen mehr. - (3) Der Backup-
Broker 30 arbeitet alle noch ausstehenden Journal-Sätze ab and quittiert. - (4)
Der primäre Broker 20 sendet Antworten für alle noch unbeantworteten Teilnehmeranfragen, bzw. unterbricht blockierende Calls. - (5)
Der primäre Broker 20 und der Backup-Broker 30 synchronisieren den SHUTDOWN des primärenBrokers 20. - (6)
Der primäre Broker 20 stoppt. - (7) Der Backup-
Broker 30 führt die TAKEOVER Sequenz durch, die ihn als primären Broker aktiviert. Dies beinhaltet das Akzeptieren aller Verbindungsaufforderungen und das Abarbeiten von Teilnehmer-anfragen. - (8) Da zu diesem Zeitpunkt kein Backup-Broker existiert, unterbleibt jegliche Kontaktaufnahme.
- (1) Der Backup-
- Stoppen des Backup-Broker (Kommando SHUTDOWN_BROKER mit Option STOP_CLUSTER_MODE).
- (1)
Der primäre Broker 20 wird vom bevorstehenden SHUTDOWN in Kenntnis gesetzt. - (2)
Der primäre Broker 20 stoppt die Übertragung von Journal-Sätzen an den Backup-Broker 30, arbeitet also im Normalbetrieb weiter. - (3) Der Backup-
Broker 30 leitet den SHUTDOWN ein und beendet die Verarbeitung.
- (1)
- Joint stopping of primary 20 and backup broker 30 (SHUTDOWN_CLUSTER command):
- (1) The PARTNER Broker will be notified by the upcoming SHUTDOWN.
- (2) The
primary broker 20 no longer accepts new requests. - (3) The
Backup Broker 30 processes and acknowledges all pending journal records. - (4) The
primary broker 20 sends responses for all unanswered requests, or interrupts blocking calls. - (5) The
primary broker 20 and thebackup broker 30 synchronize the common SHUTDOWN. - (6) The
primary broker 20 and thebackup broker 30 stop.
- Stop primary broker 20 (SHUTDOWN_BROKER command):
- (1) The
backup broker 30 is notified of the upcoming SHUTDOWN. - (2) The
primary broker 20 no longer accepts new subscriber requests. - (3) The
Backup Broker 30 processes and acknowledges all pending journal records. - (4) The
primary broker 20 sends replies for all unanswered subscriber requests, or interrupts blocking calls. - (5) The
primary broker 20 and thebackup broker 30 synchronize the SHUTDOWN of theprimary broker 20. - (6) The
primary broker 20 stops. - (7) The
backup broker 30 executes the TAKEOVER sequence which activates it as the primary broker. This includes accepting all connection requests and processing subscriber requests. - (8) Since no backup broker exists at this time, no contact is made.
- (1) The
- Stop the backup broker (command SHUTDOWN_BROKER with option STOP_CLUSTER_MODE).
- (1) The
primary broker 20 is notified of the upcoming SHUTDOWN. - (2) The
primary broker 20 stops the transmission of journal records to thebackup broker 30, thus continues to operate in normal operation. - (3) The
backup broker 30 initiates the SHUTDOWN and ends the processing.
- (1) The
Weitere Ausführungsformen der Erfindung sind im Folgenden genannt:
- 1. System zum Verwalten von Kommunikation zwischen zumindest einem Client (10a - d) und zumindest einem Server (12a - d) mit
- a. einem primären Broker (20) mit einem ersten flüchtigen Speicher (23), der zumindest eine Anfrage des zumindest einen Clients (10a - d) bei dem zumindest einen Server (12a -d) verwaltet;
- b. einem Backup-Broker (12a - d) mit einem zweiten flüchtigen Speicher (33), der die zumindest eine Anfrage des Clients (10a - d) bei dem Server (12a - d) verwaltet, wenn der primäre Broker (20) ausgefallen ist, dadurch gekennzeichnet, dass
- c. der primäre Broker (20) ein Journal mit Einträgen über Vorgänge auf weist, die den Zustand des ersten flüchtigen Speichers (23) verändern können, und diese Einträge des Journals an den Backup-Broker (30) sendet, so dass der Zustand des zweiten flüchtigen Speichers (33) im Wesentlichen identisch ist mit dem Zustand des ersten flüchtigen Speichers (23).
- 2.
System nach Anspruch 1, wobei der primäre Broker (20) eine Filterfunktion aufweist, die festlegt, welche Einträge in das Journal geschrieben werden. - 3.
System nach Anspruch 1oder 2, wobei der Backup-Broker (30) einen Journal-Interpreter aufweist, der die vom primären Broker (20) empfangenen Einträge empfangt und abarbeitet, damit der Zustand des zweiten flüchtigen Speichers (33) im Wesentlichen identisch ist mit dem Zustand des ersten flüchtigen Speichers (23). - 4.
System nach Anspruch 3, wobei die Abarbeitung der Einträge in dem Journal durch den Journal-Interpreter des Backup-Brokers (30) den zweiten flüchtigen Speicher (33) durch zumindest einen anderen Schritt in den zum ersten flüchtigen Speicher (23) im Wesentlichen identischen Zustand bringt, als den / die dafür im primären Broker (20) durchgeführten Schritt(e). - 5. System nach einem der Ansprüche 1 - 4, wobei der primäre Broker (20) in einer Antwort auf den Empfang einer Kommunikation von einem Client (10a - d) oder einem Server (12a - d) dem Client bzw. dem Server eine Identifizierung des Backup-Brokers (30) mitteilt.
- 6.
System nach Anspruch 5, wobei jede Antwort auf die Anfrage eines Clients (10a - d) die Identifizierung des Backup-Brokers (30) aufweist. - 7. System nach einem der Ansprüche 1-6, wobei der primäre Broker (20) eine Kommunikation mit dem zumindest einen Client (10a - d) und oder dem zumindest einen Server (12a - d), die zu einem Eintrag in dem Journal führt, erst beantwortet, nachdem der Backup-Broker (30) den Empfang des entsprechenden Eintrags quittiert hat.
- 8. System nach einem der Ansprüche 1 - 7, wobei jede Kommunikation mit dem primären Broker (20), die zu einem Eintrag im Journal führt, eindeutig identifiziert wird.
- 9.
System nach Anspruch 8, wobei jede Anfrage eines Teilnehmers an den primären Broker (20), die zu einem Eintrag in das Journal führt, fortlaufend nummeriert wird. - 10. System nach einem der Ansprüche 1 - 9, wobei der Backup-Broker (30) ein Testsignal an den primären Broker (20) schickt, wenn er über einen bestimmten Zeitraum hinweg keinen neuen Eintrag empfangen hat.
- 11. System nach Anspruch 10, wobei der Backup-Broker (30) für die Kommunikation mit dem zumindest einen Client (10a - d) und dem zumindest einen Server (12a - d) empfangsbereit wird, wenn der primäre Broker (20) auf das Testsignal nicht innerhalb einer vorbestimmten Zeit antwortet.
- 12. System nach einem der Ansprüche 1 - 11, wobei der Backup-Broker (30) zu dem primären Broker (20) zu einem beliebigen Zeitpunkt zuschaltbar ist, indem alle bis zu diesem Zeitpunkt im Journal gespeicherten Einträge an den Backup-Broker (30) übertragen und dort abgearbeitet werden.
- 13. System nach Anspruch 12, wobei zusätzlich Daten eines dauerhaften Speichers (24) des primären Brokers (20) an einen dauerhaften Speicher (34) des Backup-Prokers (30) übertragen werden.
- 14. Computerlesbares Medium mit Anweisungen zur Bereitstellung eines Systems nach einem der Ansprüche 1-13.
- 15. Programm mit Anweisungen zu Bereitstellung eines Systems nach einem der Ansprüche 1-13.
- A system for managing communication between at least one client (10a-d) and at least one server (12a-d)
- a. a primary broker (20) having a first volatile memory (23) that manages at least one request of the at least one client (10a-d) at the at least one server (12a-d);
- b. a backup broker (12a-d) having a second volatile memory (33) that manages the at least one request from the client (10a-d) to the server (12a-d) when the primary broker (20) has failed, characterized in that
- c. the primary broker (20) has a journal with entries about events that can change the state of the first volatile memory (23), and sends those entries of the journal to the backup broker (30) so that the state of the second volatile memory Memory (33) is substantially identical to the state of the first volatile memory (23).
- The system of
claim 1, wherein the primary broker (20) has a filtering function that determines which entries are written to the journal. - A system according to
1 or 2, wherein the backup broker (30) comprises a journal interpreter receiving and processing the entries received from the primary broker (20) so that the state of the second volatile memory (33) is substantially identical is the state of the first volatile memory (23).claim - The system of
claim 3, wherein the processing of the entries in the journal by the journal interpreter of the backup broker (30) substantially bypasses the second volatile memory (33) through at least one other step into the first volatile memory (23) identical state as the step (s) performed in the primary broker (20). - The system of any one of claims 1-4, wherein the primary broker (20), in response to receiving a communication from a client (10a-d) or a server (12a-d), identifies the client or the server of the backup broker (30).
- The system of
claim 5, wherein each response to the request of a client (10a-d) comprises the identification of the backup broker (30). - The system of any one of claims 1-6, wherein the primary broker (20) communicates with the at least one client (10a-d) and / or the at least one server (12a-d) resulting in an entry in the journal , only answered after the backup broker (30) has acknowledged receipt of the corresponding entry.
- The system of any one of claims 1-7, wherein each communication with the primary broker (20) leading to an entry in the journal is uniquely identified.
- The system of
claim 8, wherein each request of a subscriber to the primary broker (20) leading to an entry in the journal is consecutively numbered. - The system of any one of claims 1-9, wherein the backup broker (30) sends a test signal to the primary broker (20) if it has not received a new entry for a certain period of time.
- The system of claim 10, wherein the backup broker (30) becomes ready for communication with the at least one client (10a-d) and the at least one server (12a-d) when the primary broker (20) accesses the Test signal does not respond within a predetermined time.
- 12. System according to one of claims 1-11, wherein the backup broker (30) to the primary broker (20) is switchable at any time by all the entries stored in the journal up to this time to the backup broker (30 ) and processed there.
- The system of claim 12, wherein additional data of a persistent store (24) of the primary broker (20) is transferred to a persistent storage (34) of the backup procurer (30).
- A computer readable medium having instructions for providing a system according to any one of claims 1-13.
- A program containing instructions for providing a system according to any one of claims 1-13.
Claims (13)
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
EP06003030A EP1821498B1 (en) | 2006-02-15 | 2006-02-15 | Fail safe system for managing client-server communication |
Related Parent Applications (2)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
EP06003030A Division EP1821498B1 (en) | 2006-02-15 | 2006-02-15 | Fail safe system for managing client-server communication |
EP06003030.1 Division | 2006-02-15 |
Publications (2)
Publication Number | Publication Date |
---|---|
EP1959639A1 true EP1959639A1 (en) | 2008-08-20 |
EP1959639B1 EP1959639B1 (en) | 2011-11-02 |
Family
ID=36691380
Family Applications (2)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
EP06003030A Not-in-force EP1821498B1 (en) | 2006-02-15 | 2006-02-15 | Fail safe system for managing client-server communication |
EP08009257A Not-in-force EP1959639B1 (en) | 2006-02-15 | 2006-02-15 | Fail safe system for managing client-server communication |
Family Applications Before (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
EP06003030A Not-in-force EP1821498B1 (en) | 2006-02-15 | 2006-02-15 | Fail safe system for managing client-server communication |
Country Status (6)
Country | Link |
---|---|
US (1) | US8156177B2 (en) |
EP (2) | EP1821498B1 (en) |
CN (1) | CN101043378B (en) |
AT (2) | ATE396579T1 (en) |
DE (1) | DE502006000801D1 (en) |
ES (1) | ES2307242T3 (en) |
Families Citing this family (10)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US7725764B2 (en) * | 2006-08-04 | 2010-05-25 | Tsx Inc. | Failover system and method |
US20080307036A1 (en) * | 2007-06-07 | 2008-12-11 | Microsoft Corporation | Central service allocation system |
US10362131B1 (en) | 2008-06-18 | 2019-07-23 | Amazon Technologies, Inc. | Fault tolerant message delivery |
US8261286B1 (en) * | 2008-06-18 | 2012-09-04 | Amazon Technologies, Inc. | Fast sequential message store |
JP5609193B2 (en) * | 2010-03-19 | 2014-10-22 | 富士通株式会社 | Test program, test apparatus, and test method |
CN102891833B (en) * | 2011-07-21 | 2017-03-29 | 中兴通讯股份有限公司 | Network disaster tolerance method and system |
US9798639B2 (en) | 2013-06-13 | 2017-10-24 | Tsx Inc. | Failover system and method replicating client message to backup server from primary server |
US10127060B2 (en) | 2013-08-16 | 2018-11-13 | Intuitive Surgical Operations, Inc. | System and method for replay of data and events provided by heterogeneous devices |
US9729653B2 (en) * | 2014-01-23 | 2017-08-08 | Software Ag | Systems and/or methods for automatically tuning a delivery system for transmission of large, volatile data |
US10831571B2 (en) | 2018-09-27 | 2020-11-10 | International Business Machines Corporation | Communicating between systems using a coupling facility list structure |
Citations (6)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
EP0549325A2 (en) * | 1991-12-23 | 1993-06-30 | International Business Machines Corporation | Log archive filtering system for transaction-consistent forward recovery from catastrophic media failures |
US5815668A (en) * | 1995-03-17 | 1998-09-29 | Nec Corporation | Slave inter-lan connection device, an inter-lan connection system and a hot standby method of said inter-lan connection system |
US6065062A (en) | 1997-12-10 | 2000-05-16 | Cisco Systems, Inc. | Backup peer pool for a routed computer network |
US6578160B1 (en) * | 2000-05-26 | 2003-06-10 | Emc Corp Hopkinton | Fault tolerant, low latency system resource with high level logging of system resource transactions and cross-server mirrored high level logging of system resource transactions |
US20030237018A1 (en) * | 2002-06-25 | 2003-12-25 | Hitachi, Ltd. | Server takeover system and method |
US20050172161A1 (en) * | 2004-01-20 | 2005-08-04 | International Business Machines Corporation | Managing failover of J2EE compliant middleware in a high availability system |
Family Cites Families (6)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US6065325A (en) | 1999-05-26 | 2000-05-23 | Tsai; Sou-Jun | Automatic stamping machine |
US6665705B1 (en) * | 1999-10-19 | 2003-12-16 | International Business Machines Corporation | Method and apparatus for proxy replication |
US7043504B1 (en) * | 2000-04-10 | 2006-05-09 | International Business Machines Corporation | System and method for parallel primary and secondary backup reading in recovery of multiple shared database data sets |
US7647422B2 (en) * | 2001-11-06 | 2010-01-12 | Enterasys Networks, Inc. | VPN failure recovery |
US7130891B2 (en) * | 2002-02-04 | 2006-10-31 | Datasynapse, Inc. | Score-based scheduling of service requests in a grid services computing platform |
US7188273B2 (en) * | 2003-11-24 | 2007-03-06 | Tsx Inc. | System and method for failover |
-
2006
- 2006-02-15 EP EP06003030A patent/EP1821498B1/en not_active Not-in-force
- 2006-02-15 EP EP08009257A patent/EP1959639B1/en not_active Not-in-force
- 2006-02-15 AT AT06003030T patent/ATE396579T1/en not_active IP Right Cessation
- 2006-02-15 AT AT08009257T patent/ATE532313T1/en active
- 2006-02-15 ES ES06003030T patent/ES2307242T3/en active Active
- 2006-02-15 DE DE502006000801T patent/DE502006000801D1/en active Active
-
2007
- 2007-02-14 US US11/674,946 patent/US8156177B2/en active Active
- 2007-02-14 CN CN2007100879697A patent/CN101043378B/en not_active Expired - Fee Related
Patent Citations (6)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
EP0549325A2 (en) * | 1991-12-23 | 1993-06-30 | International Business Machines Corporation | Log archive filtering system for transaction-consistent forward recovery from catastrophic media failures |
US5815668A (en) * | 1995-03-17 | 1998-09-29 | Nec Corporation | Slave inter-lan connection device, an inter-lan connection system and a hot standby method of said inter-lan connection system |
US6065062A (en) | 1997-12-10 | 2000-05-16 | Cisco Systems, Inc. | Backup peer pool for a routed computer network |
US6578160B1 (en) * | 2000-05-26 | 2003-06-10 | Emc Corp Hopkinton | Fault tolerant, low latency system resource with high level logging of system resource transactions and cross-server mirrored high level logging of system resource transactions |
US20030237018A1 (en) * | 2002-06-25 | 2003-12-25 | Hitachi, Ltd. | Server takeover system and method |
US20050172161A1 (en) * | 2004-01-20 | 2005-08-04 | International Business Machines Corporation | Managing failover of J2EE compliant middleware in a high availability system |
Non-Patent Citations (1)
Title |
---|
"REPLICATION AND RECOVERY OF DATABASE STATE INFORMATION IN FAULT TOLERANT CLUSTERS", IBM TECHNICAL DISCLOSURE BULLETIN, IBM CORP. NEW YORK, US, vol. 36, no. 10, 1 October 1993 (1993-10-01), pages 541 - 544, XP000412479, ISSN: 0018-8689 * |
Also Published As
Publication number | Publication date |
---|---|
ES2307242T3 (en) | 2008-11-16 |
ATE396579T1 (en) | 2008-06-15 |
CN101043378A (en) | 2007-09-26 |
US20070203976A1 (en) | 2007-08-30 |
EP1959639B1 (en) | 2011-11-02 |
DE502006000801D1 (en) | 2008-07-03 |
CN101043378B (en) | 2011-12-14 |
ATE532313T1 (en) | 2011-11-15 |
EP1821498A1 (en) | 2007-08-22 |
EP1821498B1 (en) | 2008-05-21 |
US8156177B2 (en) | 2012-04-10 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
EP1959639B1 (en) | Fail safe system for managing client-server communication | |
DE69803476T2 (en) | HIGHLY AVAILABLE GROUP CONFIGURATION DATABASE | |
DE60312746T2 (en) | RECOVERY AFTER FAULTS IN DATA PROCESSING PLANTS | |
DE112011100623B4 (en) | Read-other protocol for maintaining parity coherency in a writeback distributed redundancy data storage system | |
DE69614383T2 (en) | CONTINUOUSLY AVAILABLE DATABASE SERVER WITH SEVERAL NODE GROUPS WITH MINIMUM OVERLAPPING SETS OF DATABASE PART COPIES | |
DE60220263T2 (en) | SERVER DUPLEX PROCESS AND SUPPLEMENTED SERVER SYSTEM | |
DE69905594T2 (en) | REPLICED SERVER PROTOCOL | |
DE69327679T2 (en) | Message transmission between processors and a coupling device | |
DE69715537T2 (en) | FAULT-TOLERANT PROCEDURE | |
DE602005002532T2 (en) | CLUSTER DATABASE WITH REMOTE DATA MIRROR | |
DE69330239T2 (en) | Device for fault-tolerant calculation | |
DE10134492B4 (en) | Failure transfer of the file management system in a computer cluster | |
DE60122691T2 (en) | METHOD AND DEVICE FOR DISTRIBUTING CAKES | |
DE10123067B4 (en) | Synchronous duplication of transactions in a distributed system | |
DE69623229T2 (en) | Binding procedure in a transaction in a distributed database | |
DE60111072T2 (en) | METHOD AND APPARATUS FOR PARALLEL MESSAGE TRANSMISSION IN REAL TIME OF FILE-SEPARATE | |
DE69715536T2 (en) | FAULT-TOLERANT PROCESSING SYSTEM | |
DE69714344T2 (en) | Device and method for the availability and retrieval of files using collections of copy memory | |
DE69624579T2 (en) | SYSTEM AND METHOD FOR A DISTRIBUTED OBJECT MANAGEMENT ENVIRONMENT IN SEVERAL PLACES | |
DE69702708T2 (en) | METHOD AND DEVICE FOR CLIENT-MANAGED FLOW CONTROL IN A COMPUTER SYSTEM WITH LIMITED STORAGE | |
DE602004005344T2 (en) | METHOD, SYSTEM AND PROGRAM FOR HANDLING A FAILOVER TO A REMOTE MEMORY | |
DE69807077T2 (en) | METHOD AND DEVICE FOR RECOVERY IN A DISTRIBUTED DATABASE SYSTEM WITH NOT GLOBALLY AVAILABLE DATA USING SHARED VIRTUAL DISKS | |
DE69907818T2 (en) | Method and device for error detection and recovery with predetermined type of replication for distributed applications in a network | |
DE202019005483U1 (en) | Data replication and data failure protection in database systems | |
DE19924900A1 (en) | Data processing and communication system that has a protection against loss of data due to a catastrophic failure |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
PUAI | Public reference made under article 153(3) epc to a published international application that has entered the european phase |
Free format text: ORIGINAL CODE: 0009012 |
|
17P | Request for examination filed |
Effective date: 20080520 |
|
AC | Divisional application: reference to earlier application |
Ref document number: 1821498 Country of ref document: EP Kind code of ref document: P |
|
AK | Designated contracting states |
Kind code of ref document: A1 Designated state(s): AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HU IE IS IT LI LT LU LV MC NL PL PT RO SE SI SK TR |
|
17Q | First examination report despatched |
Effective date: 20080812 |
|
AKX | Designation fees paid |
Designated state(s): AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HU IE IS IT LI LT LU LV MC NL PL PT RO SE SI SK TR |
|
GRAP | Despatch of communication of intention to grant a patent |
Free format text: ORIGINAL CODE: EPIDOSNIGR1 |
|
GRAS | Grant fee paid |
Free format text: ORIGINAL CODE: EPIDOSNIGR3 |
|
GRAA | (expected) grant |
Free format text: ORIGINAL CODE: 0009210 |
|
AC | Divisional application: reference to earlier application |
Ref document number: 1821498 Country of ref document: EP Kind code of ref document: P |
|
AK | Designated contracting states |
Kind code of ref document: B1 Designated state(s): AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HU IE IS IT LI LT LU LV MC NL PL PT RO SE SI SK TR |
|
REG | Reference to a national code |
Ref country code: GB Ref legal event code: FG4D Free format text: NOT ENGLISH |
|
REG | Reference to a national code |
Ref country code: CH Ref legal event code: EP |
|
REG | Reference to a national code |
Ref country code: IE Ref legal event code: FG4D |
|
REG | Reference to a national code |
Ref country code: DE Ref legal event code: R096 Ref document number: 502006010549 Country of ref document: DE Effective date: 20120105 |
|
REG | Reference to a national code |
Ref country code: NL Ref legal event code: VDEP Effective date: 20111102 |
|
LTIE | Lt: invalidation of european patent or patent extension |
Effective date: 20111102 |
|
PG25 | Lapsed in a contracting state [announced via postgrant information from national office to epo] |
Ref country code: LT Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT Effective date: 20111102 Ref country code: IS Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT Effective date: 20120302 |
|
PG25 | Lapsed in a contracting state [announced via postgrant information from national office to epo] |
Ref country code: PT Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT Effective date: 20120302 Ref country code: PL Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT Effective date: 20111102 Ref country code: LV Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT Effective date: 20111102 Ref country code: SE Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT Effective date: 20111102 Ref country code: GR Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT Effective date: 20120203 Ref country code: SI Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT Effective date: 20111102 Ref country code: NL Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT Effective date: 20111102 |
|
REG | Reference to a national code |
Ref country code: IE Ref legal event code: FD4D |
|
PG25 | Lapsed in a contracting state [announced via postgrant information from national office to epo] |
Ref country code: CY Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT Effective date: 20111102 |
|
PG25 | Lapsed in a contracting state [announced via postgrant information from national office to epo] |
Ref country code: SK Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT Effective date: 20111102 Ref country code: BG Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT Effective date: 20120202 Ref country code: DK Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT Effective date: 20111102 Ref country code: CZ Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT Effective date: 20111102 Ref country code: EE Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT Effective date: 20111102 Ref country code: IE Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT Effective date: 20111102 |
|
BERE | Be: lapsed |
Owner name: SOFTWARE A.G. Effective date: 20120228 |
|
PG25 | Lapsed in a contracting state [announced via postgrant information from national office to epo] |
Ref country code: RO Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT Effective date: 20111102 Ref country code: IT Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT Effective date: 20111102 |
|
PLBE | No opposition filed within time limit |
Free format text: ORIGINAL CODE: 0009261 |
|
STAA | Information on the status of an ep patent application or granted ep patent |
Free format text: STATUS: NO OPPOSITION FILED WITHIN TIME LIMIT |
|
PG25 | Lapsed in a contracting state [announced via postgrant information from national office to epo] |
Ref country code: MC Free format text: LAPSE BECAUSE OF NON-PAYMENT OF DUE FEES Effective date: 20120229 |
|
REG | Reference to a national code |
Ref country code: CH Ref legal event code: PL |
|
26N | No opposition filed |
Effective date: 20120803 |
|
PG25 | Lapsed in a contracting state [announced via postgrant information from national office to epo] |
Ref country code: LI Free format text: LAPSE BECAUSE OF NON-PAYMENT OF DUE FEES Effective date: 20120229 Ref country code: CH Free format text: LAPSE BECAUSE OF NON-PAYMENT OF DUE FEES Effective date: 20120229 |
|
REG | Reference to a national code |
Ref country code: FR Ref legal event code: ST Effective date: 20121031 |
|
REG | Reference to a national code |
Ref country code: DE Ref legal event code: R097 Ref document number: 502006010549 Country of ref document: DE Effective date: 20120803 |
|
PG25 | Lapsed in a contracting state [announced via postgrant information from national office to epo] |
Ref country code: BE Free format text: LAPSE BECAUSE OF NON-PAYMENT OF DUE FEES Effective date: 20120228 |
|
PG25 | Lapsed in a contracting state [announced via postgrant information from national office to epo] |
Ref country code: FR Free format text: LAPSE BECAUSE OF NON-PAYMENT OF DUE FEES Effective date: 20120229 |
|
REG | Reference to a national code |
Ref country code: AT Ref legal event code: MM01 Ref document number: 532313 Country of ref document: AT Kind code of ref document: T Effective date: 20120215 |
|
PG25 | Lapsed in a contracting state [announced via postgrant information from national office to epo] |
Ref country code: ES Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT Effective date: 20120213 |
|
PG25 | Lapsed in a contracting state [announced via postgrant information from national office to epo] |
Ref country code: AT Free format text: LAPSE BECAUSE OF NON-PAYMENT OF DUE FEES Effective date: 20120215 Ref country code: FI Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT Effective date: 20111102 |
|
PG25 | Lapsed in a contracting state [announced via postgrant information from national office to epo] |
Ref country code: TR Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT Effective date: 20111102 |
|
PG25 | Lapsed in a contracting state [announced via postgrant information from national office to epo] |
Ref country code: LU Free format text: LAPSE BECAUSE OF NON-PAYMENT OF DUE FEES Effective date: 20120215 |
|
PG25 | Lapsed in a contracting state [announced via postgrant information from national office to epo] |
Ref country code: HU Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT Effective date: 20060215 |
|
REG | Reference to a national code |
Ref country code: DE Ref legal event code: R079 Ref document number: 502006010549 Country of ref document: DE Free format text: PREVIOUS MAIN CLASS: H04L0029080000 Ipc: H04L0065000000 |
|
PGFP | Annual fee paid to national office [announced via postgrant information from national office to epo] |
Ref country code: GB Payment date: 20220223 Year of fee payment: 17 Ref country code: DE Payment date: 20220217 Year of fee payment: 17 |
|
REG | Reference to a national code |
Ref country code: DE Ref legal event code: R119 Ref document number: 502006010549 Country of ref document: DE |
|
GBPC | Gb: european patent ceased through non-payment of renewal fee |
Effective date: 20230215 |
|
PG25 | Lapsed in a contracting state [announced via postgrant information from national office to epo] |
Ref country code: GB Free format text: LAPSE BECAUSE OF NON-PAYMENT OF DUE FEES Effective date: 20230215 |
|
PG25 | Lapsed in a contracting state [announced via postgrant information from national office to epo] |
Ref country code: GB Free format text: LAPSE BECAUSE OF NON-PAYMENT OF DUE FEES Effective date: 20230215 Ref country code: DE Free format text: LAPSE BECAUSE OF NON-PAYMENT OF DUE FEES Effective date: 20230901 |