KR19990020349A - How to prevent duplication of interprocessor messages due to board duplication - Google Patents

Abstract

A method for preventing duplex processing during inter-processor communication of a duplexing device using a dual active method includes a type of currently received message and identification information of a transmission processor, a type of a predetermined number of recently processed messages and identification information of a transmission processor. After analyzing the attributes of the message by comparing the two attributes, the currently received message at the same message attribute is judged as a duplicate message and is not processed.

Description

How to prevent duplication of interprocessor messages due to board duplication

The present invention relates to a message processing method used for inter-block communication, and more particularly, to a method for preventing double processing of inter-processor messages due to board duplication.

In general, a communication system that processes data in real time, such as an exchange system, implements control boards as redundant devices to improve the reliability of the data being communicated. Hereinafter, the communication system is assumed to be a switching system.

In a conventional exchange system (V4.2, a previous version of a commercial vehicle), a PBA (Printed Board Assembly) redundancy configuration is implemented as shown in FIG. 1. However, such a redundancy device is an active / standby redundancy system. That is, in the duplexing device having the configuration as shown in FIG. 1, only one of the two switches PBA A and PBS B operates in an operating state, and the other side is in a standby state. At this time, in the control PBA that actually processes the inter-processor communication message (hereinafter referred to as IPC message), only the IPC message is selected from the operation switch PBA in hardware. In this case, the selection method uses an ACT-A control signal and an ACT-B control signal. In this case, the software simply processes all received IPC messages one by one. In other words, the same two received IPC messages are filtered out in hardware, so that the software does not double process.

However, such an operation / standby redundancy device cannot be a true redundancy device. That is, the current exchange system (V4.3, user version) has been changed hardware system to dual active (dual active) redundancy. Thus, such a redundancy device requires an anti-duplication algorithm that filters out one of the same IPC messages each received by the two switch PBAs by a software routine.

At this time, if the dual anti-duplication algorithm is not applied in the dual active redundancy device or an algorithm that cannot reliably prevent the double-processing is adopted, the processor in the SLCA processes the same operation unnecessarily or simply sends a message to be processed. Discarded. In the former case, the load of the CPU is increased by a maximum of 2 times, which causes a problem that causes a delay in processing of another important message received later. This means a response delay to the control unit. In the worst case, the IPC message traffic in the system may increase due to retransmission of the IPC message due to a request timeout at the control system block side.

Accordingly, an object of the present invention is to provide a method capable of preventing double processing in inter-processor communication in a dual active redundancy device.

Another object of the present invention is to provide a method of determining whether or not messages are identical in communication between processors in a dual active duplication apparatus, and preventing double processing by processing only one message when receiving the same message.

It is still another object of the present invention to provide a method for processing a message-induced single-receipt message during inter-processor communication in a dual active duplication apparatus.

In order to achieve the above object, a method for preventing dual processing during communication between processors of a duplexing device using a dual active method according to an embodiment of the present invention is performed. After analyzing the attributes of the message by comparing a predetermined number of types of messages and identification information of the transmission processor, the message currently received at the same message attribute is determined as a duplicate message and is not processed.

1 is a diagram showing the configuration of a general redundancy processing apparatus;

2A to 2B are flowcharts illustrating a process for preventing duplication of messages between processors according to board duplication in a duplication processing apparatus according to an embodiment of the present invention.

2A to 2B are flowcharts illustrating a process of performing a double processing prevention function during communication between processors in a duplexing device adopting a dual active method according to an embodiment of the present invention. In FIG. 2, Que_msgID is an ID indicating a type of a message. Que_SMLASideID is an ID indicating the board on which the current message was received. DelDB is a database for determining whether to process a current message. msgID side is a duplicate message stored in the DelDB. DelDBcnt is a counter indicating the number of messages currently registered in DelDB. DelDBDepth represents the total number of messages that can be registered in DelDB.

Referring to the method for preventing dual processing of messages between processors of a duplexing device using a dual active method according to an embodiment of the present invention, once all IPC messages received through two SMLA PBAs are put into a queue in a SLCA that is a control PBA. Stored. The queue is operated in a FIFO (First In First Out) manner. Each message stored in the queue has two attributes appended by the software. One attribute is Que_msgID, which indicates the type of message, and the software decides what to do based on this value. For example, a message with ID 0X9001 requires status information on the switch port. In response, the software checks the current status of all switch ports (64 ports total, 32 * 32 switch redundancy), and loads this information. Send a response message. In addition, the other attribute Que_SMLASideID indicates whether the current message is received from SMLA-A or SMLA-B. That is, if Que_SMLASideID is 0, this is a message received from SMLA-A, and if 1, it is a message received from SMLA-B.

The software runs a database called DelDB to determine whether to process the current message. Information of duplicate messages (msg side information) is registered in DelDB, and messages having the same value (attribute) as information registered in DelDB among messages stored in the queue are not processed. That is, if the current message is determined to be a duplicate message with reference to information registered in DelDB, that is, if the same message received from the counterpart SMLA has already been processed in the previous step, the current message is not processed. However, if it is determined that the current message is not a duplicate message, it processes the current message after registering information in DelDB that specifies the same message received or expected to be received later. Here, DelDBcnt means the number of messages currently registered in DelDB, and DelDBDepth is the total number of messages that can be registered in DelDB. In other words, messages can be registered in DelDB from DelDB [0] to DelDB [DelDBDetph-1]. The initial values of the variables used in the algorithm shown in FIG. 2 are DelDBcnt = 0, DelDB [0] ~ DelDB [DelDDepth-1] = 0, and the value of DelDBDetph, which is a constant, is a parameter that can be set according to the essential characteristics of the system. to be.

If there is a message received and stored in the message queue, the software processes the stored message in the same manner as in FIG. 2. At this time, since the message queue is a packet type queue, the head message of the queue is a processing target. Referring to FIG. 2, in step 212, the message count value of the message queue is checked. If the message count value is positive, the head message value of the queue is read in step 214. At this time, the attribute of the message is replaced by Que_msg Que_SMLASideID. Where Que_msgID is an ID indicating a message type, and Que_SMLASideID is an ID indicating a board on which a current message is received. After that, check if the value of DeDBcnt is greater than zero. If DelDBcnt = 0, the flow proceeds to step 244.

If there is a message currently registered in DelDB in step 216 (DelDBcnt0), the message counter variable i is set to 0 while performing steps 218 and 220, and then Que-msgID = DelDB [i] .msgID and Que_SMLASideID = Check if it is DelDB [i] .side In this case, if it is not the same in step 220, the value of i is increased in step 222 (i = i + 1), and in step 224, jDelDBDetph is checked. In this case, if it is jDelDBDetph, the process returns to step 220, or otherwise proceeds to step 244. If it is not jDelDBDetph, it means there is no message in DelDB.

In addition, if the condition of Que-msgID = DelDB [i] .msgID Que_SMLASideID = DelDB [i] .side is satisfied, it is detected in step 220 and the process proceeds to step 226. At this time, if i is 0, DelDBcnt = DelDBcnt-1 is performed while performing steps 228 and 230, Del [0] = DelDB [1], Del [1] = DelDB [2] --- DelDB [DelDBDepth-2] == DelDB [DelDBDepth-1], DelDB [DelDBDepth-1] = DelDB [DelDBDepth-0] Rebuild DelDB. If i is 1, DelDBcnt = DelDBcnt-2 is performed while performing steps 232 and 234, Del [0] = DelDB [2], Del [1] = DelDB [3] --- DelDB [DelDBDepth-3] Rebuild DelDB with = DelDB [DelDBDepth-1], DelDB [DelDBDepth-2] = 0, and DelDB [DelDBDepth-1] = 0. Reconfigure DelDB from I = 2 to i = DelDBDepth-3 as above. If i = DelDBDepth-2, DelDBcnt = DelDBcnt- (DelDBDepth-1) in steps 236 to 238, and DelDB [0] = DelDB [DelDBDepth-1], DelDB [1] = 0, ---, Rebuild DelDB with DelDB [DelDBDepth-1] = 0. In the step i = DelDBDepth-1, step 240-242, DelDBcnt = DelDBcnt-DelDBDepth, DelDB [0] = 0, DelDB [1] = 0, ---, and DelDB [DelDBDepth-1] = 0. Rebuild DelDB

If the message is stored in the message queue as described above (DelDBcnt0), in step 220, DelDB is searched to determine whether there is information that matches the attribute of the message or is registered in the DB. At this time, if information of the condition (Que-msgID = DelDB [i] .msgID Que_SMLASideID = DelDB [i] .side) that matches the attribute of the message is stored, it is determined as a duplicate message and is not processed. In this case, the software performs steps 226 to 242 to reconstruct DelDB information. The content registered in DelDB [0] means a duplicate message of a message processed longest. Under most normal system operation, duplicate messages will most likely be equal to the DelDB [0] value. The software moves DelDB information below DelDB [1] forward by one index to reconstruct DelDB for use in subsequent message processing.

In operation 244, the number of messages stored in the message queue is equal to the number of messages that can be registered in DelDB (DelDBcnt = DelDBDepth). If DelDBcnt = DelDBDepth, in step 246, DelDB reconstructs DelDB with DelDB [0] = DelDB [1], DelDB [1] = DelDB [2] --- DelDB [DelDBDepth-2] = DelDB [DelDBDepth-1], In step 248, DelDB [DelDBDepth-1] .msgID = Que_msgID is set. In step 250, the Que_SMLASideID is checked to determine in which SMLA the received message originated. At this time, if Que_SMLASideID is 0, it is detected that the message has been received by the SMLA-A, and in step 252, DelDB [DelDBDepth-1] .side = 1. In addition, if Que_SMLASideID is 1, it detects that the message is received by the SMLA-B, and in step 254, DelDB [DelDBDepth-1] .side = 0. After performing step 252 or step 254, the operation is terminated after performing the corresponding operation according to the Que-msgID value of the message in step 256.

However, if DelDBcnt ≠ DelDBDepth, it is detected in step 244, and in step 258, DelDB [DelDBcnt] .msgID = Que_msgID is set. In step 260, Que_SMLASideID is checked to determine in which SMLA the received message originated. At this time, if Que_SMLASideID is 0, it is detected that the message has been received by the SMLA-A. In step 262, DelDB [DelDBDepth-1] .side = 1. In addition, if Que_SMLASideID is 1, it is detected that the message has been received by the SMLA-B, and in step 264, DelDB [DelDBDepth-1] .side = 0. Thereafter, step 262 or 264 is performed, and in step 266, DelDBcnt = DelDBcnt + 1 is set. In step 256, the corresponding operation is performed according to the Que-msgID value of the message and then terminated.

When the message to be processed is the same as the content of DelDB [i] (i ≠ 0), all the duplicate messages before i are lost and are not received. In this case, the software reconfigures DelDB as described above. If the message to be processed is not registered in DelDB or DelDBcnt is 0 as a result of DelDB search, this message is processed because it is a preceding message instead of a duplicate message. Before processing the message, the software registers the attribute (msgID side) of the duplicate message to be processed later in DelDB.

The DelDBDepth value is the total number of messages that can be registered in DelDB, and the received message is interpreted differently according to the setting of this value. The DelDBDepth of n implies that reception of duplicate messages is possible up to n message delays due to system characteristics. For example, suppose DelDBDepth is 3 and the order of received messages is 100A, 200A, 300B, 100B. Then, in 100A, 100 means msgID and A means receiving SMLA side. In this case, the contents of DelDB after the processing up to 300B are DelDB [0] = 100B, DelDB {1] = 200B, and DelDB [2] = 300A. The next message 100B to be processed is a message registered in DelDB, which is determined as a duplicate message and is not processed. That is, a message of the same attribute received after 1 to 3 message delays after the preceding message 100A is regarded as a duplicate message. On the other hand, if DelDBDepth is 2 in the above example, the content of DelDB after processing up to 300B becomes DelDB [0] = 200B, DelDB [1] = 300A, and subsequent message 100B is processed because it is not stored in DelDB. In other words, 100A and 100B are treated as messages other than duplicate messages.

As described above, the present invention accurately determines whether a message is redundant when processing an IPC message in a duplexing device using a dual active method, thereby preventing duplicate processing of the message. By preventing unnecessary duplication of the message as described above, it is possible to efficiently operate the processor, and also has the advantage of minimizing the waiting delay of other IPC messages received later to ensure the rapid processing.

Claims (2)

What is claimed is: 1. A method of preventing dual processing in interprocessor communication of a duplexing device using a dual active method. The message property is analyzed by comparing the type of the currently received message and the identification information of the transmission processor with the type of the recently processed predetermined number of messages and the identification information of the transmission processor. Method for preventing double processing in inter-processor communication, characterized in that it is not determined as a duplicate message and processed What is claimed is: 1. A method of preventing dual processing in interprocessor communication of a duplexing device using a dual active method. Analyzing the message queue and reading the message type of the first message and the identification code of the transmitting processor; Comparing the type of the message and the identification information of the transmission processor with a predetermined number of recently processed messages and the identification information of the transmission processor, analyzing the property of the message, and then checking whether the message is a duplicate message; When reconfiguring the database without processing the corresponding message when the same message attribute is in the checking process and ending; The method of preventing double processing during inter-processor communication, characterized in that the process of processing the corresponding message when the different message attributes in the checking process, registered in the database, reconfigured and terminated.