A method for multi-protocol traffic operation verification

Abstract

This application discloses a multi-protocol service operation verification method, belonging to the field of industrial router testing technology. The method includes: responding to a trigger command, controlling a first device to output a trigger signal, so that at least one second device receives the trigger signal and triggers the execution of a service operation; creating an independent waiter queue for each protocol verification task corresponding to each second device, and registering each waiter queue and its corresponding matching conditions to the waiter list of a protocol monitor; when the protocol monitor receives a protocol message, distributing the protocol message to the matching waiter queue according to the matching conditions; each protocol verification task obtaining the protocol message from its corresponding independent waiter queue, and confirming the execution result of the service operation based on the protocol message. This invention, by allocating an independent waiter queue for each protocol verification task, achieves isolation of verification messages from each device during concurrent verification by multiple devices, avoiding message crosstalk caused by shared message channels.

Description

Technical Field

[0001] This invention relates to the field of industrial router testing technology, and in particular to a method for verifying multi-protocol service operation. Background Technology

[0002] In industrial router applications, digital input (DI) and digital output (DO) are the fundamental mechanisms for devices to interact with the external physical world. When an external device inputs a voltage signal to the router's DI port, the router can trigger pre-configured service actions, such as sending SMS alarms, sending email notifications, cascading control of other devices by outputting DO signals, initiating cellular network dialing, publishing MQTT messages, and sending SNMP traps.

[0003] In multi-device collaborative testing scenarios, a typical approach involves one router outputting a DO signal to simultaneously trigger the DI ports of multiple monitored routers. This verifies whether each router successfully executes its respective service action upon receiving the DI trigger. To ensure testing efficiency and reliability, multiple monitored routers often need to concurrently execute the verification task of the same protocol.

[0004] In existing technologies, verification of the above scenarios typically employs a single-protocol script verification method: an automated script is written for a specific protocol, and after DI / DO is triggered, the business action is verified through the protocol channel. However, when multiple routers concurrently verify the same protocol, all verification threads share the same message channel. For example, in the MQTT protocol, messages published by multiple routers all enter the same MQTT message queue, and each verification thread consumes messages from this shared queue, leading to the problem of messages being consumed by incorrect threads.

[0005] Specifically, the verification thread of the first router retrieves a protocol message belonging to the second router from the shared message queue. Based on this, the first router mistakenly judges its service action to have been successfully executed, while the verification thread of the second router fails to retrieve the corresponding protocol message and times out. This problem is known as message crosstalk in the field of industrial router testing. Its root cause lies in the fact that the ownership relationship between the verification thread and the message cannot be established in the existing verification scheme. The verification thread cannot distinguish the source of the message, resulting in unreliable verification results. Summary of the Invention

[0006] The embodiments of the present invention provide a multi-protocol service operation verification method, which aims to allocate an independent waiter queue for each protocol verification task and accurately distribute protocol messages to the corresponding waiter queues through matching conditions, so as to achieve isolation of verification messages of each device and avoid message crosstalk caused by shared message channels.

[0007] To achieve the above objectives, the present invention provides a multi-protocol service operation verification method, characterized by the following steps: Responding to a trigger command, controlling a first device to output a trigger signal, so that at least one second device receives the trigger signal and triggers the execution of a pre-configured service operation; Creating an independent waiter queue for each protocol verification task corresponding to each second device; Registering each waiter queue and its corresponding matching conditions to the waiter list of a protocol monitor; When the protocol monitor receives a protocol message, iterating through the waiter list and distributing the protocol message to the matching waiter queue according to the matching conditions; Each protocol verification task obtaining the protocol message from its corresponding independent waiter queue and confirming the execution result of the service operation based on the protocol message.

[0008] Furthermore, the matching conditions include topic filtering conditions for the MQTT protocol and / or source IP address matching conditions for the SNMP protocol; when the protocol message is an MQTT message, it is checked whether the topic of the MQTT message contains the topic filtering conditions of the waiter queue, and if so, the MQTT message is distributed to the waiter queue; when the protocol message is an SNMP Trap message, it is checked whether the source IP address of the SNMP Trap message matches the source IP address matching conditions of the waiter queue, and if so, the SNMP Trap message is distributed to the waiter queue.

[0009] Further, the protocol verification task obtains the protocol message from its respective independent waiter queue, specifically including: the protocol verification task blocking and obtaining the protocol message from its corresponding independent waiter queue within a preset timeout period; if the protocol message is successfully obtained within the preset timeout period, the protocol verification task is determined to have passed verification; if the protocol message is not obtained within the preset timeout period, the protocol verification task is determined to have failed verification; after the protocol verification task completes verification, it removes the corresponding waiter queue from the waiter list.

[0010] Furthermore, the business operation includes an email sending operation, the protocol verification task includes an email protocol verification task, and the method further includes: upon responding to the trigger instruction, retrieving the entire email identifier list of the monitored mailbox via the IMAP protocol, and recording the last email identifier in the entire email identifier list as the email baseline identifier; when executing the email protocol verification task, retrieving the entire email identifier list of the monitored mailbox, locating the position of the email baseline identifier in the entire email identifier list, and only traversing the newly added emails corresponding to the email identifiers to be verified after the email baseline identifier; in the newly added emails, performing dual matching according to preset subject keywords and body keywords, and if the matching is successful, determining that the execution result of the email sending operation has been verified.

[0011] Furthermore, it also includes obtaining a log line count baseline, comprising the following steps: After the second device performs the business operation, a log line count statistics command is sent to the second device via a serial port, and the total number of lines in the current log file is extracted from the returned result as the log line count baseline; The log line count baseline is used to read newly added log lines after the log line count baseline for log verification when the protocol verification channel is unavailable.

[0012] Furthermore, it also includes dual-mode degradation verification, comprising the following steps: For any of the aforementioned protocol verification tasks, end-to-end verification is first performed through the target protocol channel corresponding to the protocol verification task to confirm whether the service operation has been successfully delivered to the target end; Detect whether the target protocol channel is available, and if it is unavailable, automatically switch to log verification mode; The log verification mode includes: Based on the log line count baseline, sending a log read instruction to the second device to read from the next line after the log line count baseline, obtaining the newly added log lines after the log line count baseline, and performing keyword matching verification in the newly added log lines; Wherein, the verification accuracy of the end-to-end verification is higher than that of the log verification mode, the end-to-end verification is used to confirm that the execution result of the service operation has been delivered to the target server, and the log verification mode is used to confirm that the second device has locally executed the sending action of the service operation.

[0013] Furthermore, the multiple protocol verification tasks are started and executed in parallel. The method further includes: for a first type of protocol verification task based on serial communication, multiple first-type protocol verification tasks share a serial port mutex lock to ensure the atomic execution of serial port commands; for a second type of protocol verification task based on network communication, multiple second-type protocol verification tasks are executed in true parallel mode, without being blocked by the serial port mutex lock; the communication protocol corresponding to the first type of protocol verification task includes at least one of the following: SMS protocol, digital output protocol, cellular network dialing protocol; the communication protocol corresponding to the second type of protocol verification task includes at least one of the following: MQTT protocol, email protocol, SNMP protocol.

[0014] Furthermore, the trigger command is generated manually by the user or automatically by a timer; the first device and each of the second devices are connected via signal cables, and the trigger signal is transmitted from the first device to the digital input port of each of the second devices via the signal cables; the step of controlling the first device to output the trigger signal in response to the trigger command specifically includes: sending a digital output trigger command to the first device via the Telnet protocol to control the digital output port of the first device to output the trigger signal; when sending the digital output trigger command via the Telnet protocol fails, the current Telnet connection is automatically disconnected and a new Telnet connection is established, and the digital output trigger command is sent again.

[0015] Furthermore, the business operations also include SMS sending operations, digital output operations, cellular network dialing operations, MQTT message publishing operations, and / or SNMP Trap sending operations; the protocol verification tasks include at least two of the following: SMS verification tasks, email verification tasks, digital output verification tasks, cellular network verification tasks, MQTT verification tasks, and SNMP verification tasks; the method also includes: initializing the corresponding global protocol monitor instance according to the protocol monitor enable switch in the configuration file, wherein the global protocol monitor instance includes at least one of the following: IMAP monitor, MQTT client, and SNMP Trap receiving thread.

[0016] Furthermore, the method also includes verification result aggregation and alarm steps, specifically including: aggregating the verification results of each protocol verification task, the verification results including the number of successful items, the number of failed items, and the response time of each protocol verification task; calculating the cumulative success rate based on the current verification results and historical verification records, the cumulative success rate being the ratio of the total number of historical successful attempts to the total number of historical triggers; if there are protocol verification tasks that have failed, constructing a structured alarm message, the structured alarm message including a second device identifier, a list of failed protocol verification tasks, the response time of each failed task, and the cumulative success rate; and pushing the structured alarm message to a third-party communication interface to output an alarm notification.

[0017] The above technical solution has the following technical effects: By assigning an independent waiter queue to each protocol verification task and registering each waiter queue and its matching conditions to the waiter list of the protocol monitor, each verification task has its own dedicated message receiving channel. After receiving the protocol message, the protocol monitor distributes the message to the corresponding waiter queue according to the matching conditions. Each verification task retrieves the message from its own independent queue, fundamentally avoiding the problem of messages being consumed by incorrect threads when multiple devices perform concurrent verification by sharing a message channel, thus ensuring that the verification results of each device are accurate and reliable.

[0018] In a further embodiment, each verification task has an independent waiter queue, and each verification task waits for a timeout independently in its own queue without affecting others. The timeout, exception, or crash of any verification task will not affect other verification tasks from obtaining messages from their respective queues and completing verification normally, which greatly improves the system stability and fault tolerance in multi-device concurrent verification scenarios.

[0019] In a further embodiment, each verification task is executed in parallel, and message matching, distribution and acquisition can be completed automatically without manual intervention, which significantly improves the verification efficiency in multi-device collaborative testing scenarios. At the same time, since the message ownership relationship is clear and the verification conclusions are independent and reliable, misjudgments and repeated tests caused by message crosstalk are avoided, and testing costs are reduced. Attached Figure Description

[0020] Figure 1 This is a flowchart illustrating a multi-protocol service operation verification method according to an embodiment of the present invention. Detailed Implementation

[0021] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only a part of the embodiments of this application, and not all of them. All other embodiments obtained by those skilled in the art based on the embodiments of this application without creative effort are within the scope of protection of this application.

[0022] It should be understood that the terms "first device" and "second device" in the embodiments of this application are merely for ease of description and do not constitute any limitation on the number, type, or function of the devices. In the embodiments of this application, the first device is a trigger router, and the second device is a monitored router. The following uses an industrial router DI / DO function testing scenario as an example to provide a detailed description of the technical solution provided in the embodiments of this application.

[0023] Figure 1 This is a flowchart illustrating a multi-protocol service operation verification method according to an embodiment of the present invention. Figure 1 As shown, the method provided in this application embodiment includes the following steps: Step S1: In response to the trigger command, control the first device to output a trigger signal so that at least one second device receives the trigger signal and triggers the execution of a pre-configured service operation.

[0024] In this embodiment, the trigger command is generated by the user manually clicking the trigger button, or automatically generated when the automatic trigger timer expires. Before the trigger is executed, the system performs a pre-check: checking whether the Telnet connection status is normal and whether the previous trigger has been completed to prevent re-entry. If the previous trigger has not been completed, the current trigger request is ignored to avoid multiple trigger signals overlapping and causing confusion in the verification results. After the pre-check passes, the system records the current trigger timestamp as a unique identifier for this trigger.

[0025] The system executes a background thread that sends digital output trigger control commands to the first device, i.e., the trigger router, via the Telnet protocol to control the digital output port of the first device to output a level signal (such as a high-level pulse). If the command execution fails (e.g., the Telnet connection is abnormally disconnected), the system automatically closes the current Telnet connection, establishes a new Telnet connection, and re-executes the trigger command. The retry count is one to avoid infinite retries that could cause the system to freeze.

[0026] After the digital output port of the first device outputs a trigger signal, this trigger signal is transmitted from the first device to the digital input ports of each of the second devices, i.e., each monitored router, via signal cables. Upon receiving this signal, the digital input ports of each second device trigger the execution of their respective pre-configured service actions. In one specific implementation, the service actions include at least one of the following: SMS sending operation, email sending operation, digital output operation, cellular network dialing operation, MQTT message publishing operation, and SNMP Trap sending operation.

[0027] In practical implementation, the system first loads a structured configuration file upon startup. This configuration file contains the Telnet connection parameters for the trigger router and the authentication parameters for each monitored router. Specifically, the configuration file includes at least: the IP address, port number, username, and password of the trigger router, as well as the aforementioned digital output trigger control commands; the serial port parameters for each monitored router, such as the serial port device path and baud rate, and a list of service monitoring items, namely, optional combinations of six monitoring items: SMS authentication, email authentication, digital output authentication, cellular network authentication, MQTT authentication, and SNMP authentication; and the distinguishing identifiers required for each protocol authentication, such as MQTT topic filtering keywords like di / 6218C1049198, email body sequence numbers like DI_6218C1049198, and SNMP source IP addresses.

[0028] The system initializes the corresponding global protocol monitor instance based on the enable / disable switches of each protocol monitor in the configuration file. If email monitoring is enabled, an IMAP monitor is created, an encrypted connection is established with the mail server, and a keep-alive thread is started to periodically send NOOP commands to prevent the connection from being disconnected due to prolonged inactivity. If MQTT monitoring is enabled, an MQTT client is created, connects to the MQTT Broker, and registers an automatic resubscription callback to ensure automatic resubscription after the connection is lost. If SNMP monitoring is enabled, a UDP port 162 listener is created, and an SNMP Trap receiving thread is started.

[0029] The system also establishes a serial port connection for each monitored router. Serial port login employs a multi-step state machine automatic login process: sending an Enter key to activate the terminal, checking the current login status, clearing the buffer, sending the username character by character at preset intervals, sending the password character by character, and waiting for the system's preset login success indicator to confirm successful login. Sending characters at preset intervals is designed to accommodate the slow response time of industrial router serial ports and avoid character loss due to excessively fast transmission speeds.

[0030] Step S2: Create an independent waiter queue for each protocol verification task corresponding to each second device.

[0031] In scenarios where multiple monitored routers simultaneously verify the same protocol, existing technologies often use a shared message channel for each verification thread. For example, in the MQTT protocol, messages published by multiple routers enter the same MQTT message queue, and each verification thread consumes messages from this shared queue. This can lead to the verification thread of the first router potentially taking messages belonging to the second router, causing the first router to falsely declare success and the second router to falsely declare timeout failure.

[0032] To address the aforementioned issues, in this embodiment, each protocol verification task first creates its own independent message buffer queue (with a preset capacity limit of 10 messages) upon startup, and constructs a waiter registration entry. This waiter registration entry contains at least two elements: a reference to the message buffer queue, and a topic filtering keyword such as di / 6218C1049198, which includes the serial number of the first router.

[0033] Step S3: Register each waiter queue and its corresponding matching conditions to the waiter list of the protocol monitor.

[0034] After the waiter queue is created, the verification thread registers the waiter registration item (containing the independent queue and matching conditions) with a mutex lock to the waiter registration list of the protocol monitor.

[0035] In one specific implementation, the matching criteria differ depending on the protocol type: for the MQTT protocol, the matching criteria are topic filtering keywords; for the SNMP protocol, the matching criteria are exact matching of the source IP address.

[0036] Step S4: When the protocol monitor receives a protocol message, it iterates through the list of waiters and distributes the protocol message to the matching waiter queue according to the matching conditions.

[0037] The protocol monitor continuously listens for protocol messages from the network. When the protocol monitor receives a protocol message, it triggers the message distribution process.

[0038] Taking the MQTT monitor as an example, when an MQTT client receives a message from the Broker, the message arrival processing function is triggered. This function first acquires a mutex lock and iterates through the waiter registration list, checking whether the topic filter keyword of each waiter registration entry in the list matches the topic of the current message. If a match is found, the message is written non-blockingly to the independent message buffer queue corresponding to that waiter registration entry.

[0039] The matching method differs for SNMP Trap messages. In the waiter registry maintained by the SNMP monitor, the matching condition for each waiter registry entry is the source IP address. When the SNMP monitor receives a Trap message on UDP port 162, it parses the source IP address of the message, iterates through the waiter registry, and distributes the message to the independent queue corresponding to the waiter registry entry that matches the source IP address.

[0040] Step S5: Each protocol verification task retrieves the protocol message from its corresponding independent waiter queue and confirms the execution result of the business operation based on the protocol message.

[0041] Each protocol verification task blocks and waits for a message to arrive in its own independent waiter queue, with a preset timeout threshold, such as 30 seconds. Specifically, the verification thread blocks and retrieves the protocol message from its corresponding independent waiter queue within the preset timeout period. If the protocol message is successfully retrieved within the preset timeout period, the protocol verification task is considered to have passed verification. If the protocol message is not retrieved within the preset timeout period, the protocol verification task is considered to have failed verification.

[0042] After the verification task is completed, regardless of whether it passes or fails, a mutex lock is acquired during the resource release phase to remove the corresponding waiter registration item from the waiter registration list. If the waiter registration item is not removed after verification, a large number of invalid queue references will accumulate in the waiter registration list, causing the protocol monitor to continuously distribute messages to queues that are no longer being consumed, resulting in memory leaks. At the same time, as the waiter registration list continues to grow, the traversal overhead for each message arrival also increases, affecting system performance.

[0043] In one embodiment of this application, multiple protocol verification tasks are started and executed in parallel. The system creates an independent verification thread for each selected monitoring item of each monitored router, and all monitoring item threads start and execute in parallel simultaneously. For the first type of protocol verification tasks based on serial communication, including SMS verification, digital output verification, and cellular network verification, multiple first-type protocol verification tasks share a serial port mutex to ensure the atomic execution of the complete process of clearing the buffer, sending the command, and waiting for the output. For the second type of protocol verification tasks based on network communication, including MQTT verification, email verification, and SNMP verification, multiple second-type protocol verification tasks are executed in true parallel mode, without being blocked by the serial port mutex. The system waits for all verification threads to complete, with a total timeout of 120 seconds. Verification threads that fail to complete within the timeout period are marked as timeout failures.

[0044] In one embodiment of this application, a step of obtaining a log line count baseline is also included. After the second device performs a business operation, the system sends a log line count statistics command to the second device via a serial port, extracting the current log file line count as the log line count baseline N from the command output. This baseline is obtained only once at the start of each verification, and all subsequent log checks are based on this baseline. The log line count baseline is used to read newly added log lines after the log line count baseline for log verification when the protocol verification channel is unavailable. Specifically, the system starts reading from the line after the log line count baseline, only obtaining newly added log lines, rather than the traditional fixed-line-count end-reading method. When the log line count baseline acquisition fails, the system degrades to reading the last fixed number of lines of the log file.

[0045] In one embodiment of this application, the method further includes a dual-mode degradation verification step. For any protocol verification task, the system prioritizes end-to-end verification through the target protocol channel corresponding to the protocol verification task to confirm whether the business operation has been successfully delivered to the target end. Taking email verification as an example, the system first checks whether the global email monitor exists and whether the connection status is normal. If available, it waits in the IMAP mailbox for a new email with a subject containing preset keywords (such as "IO EVENT") and a body containing the router's serial number, with a timeout threshold of 60 seconds—this is end-to-end verification, confirming that the message has been successfully delivered to the target mailbox. If the email monitor is unavailable, the system automatically degrades to the serial port log verification method: based on the log line number baseline N, it reads new logs starting from the next line after the baseline line number and searches for matches by email sending keywords, checking whether the incremental log after triggering contains email sending records. MQTT verification and SNMP verification use the same dual-mode degradation logic. The three monitoring items of SMS verification, digital output verification, and cellular network verification only support serial port log or command verification. The two verification methods differ in precision: end-to-end verification confirms that the business operation execution result has been successfully delivered to the target end, with high verification precision; log verification confirms that the second device has executed the sending action of the business operation locally, with lower verification precision. However, both verification methods can provide clear verification conclusions.

[0046] In one embodiment of this application, the service operation includes email sending. When multiple monitored routers share the same monitoring mailbox to verify email sending services, the system, in response to a trigger command, retrieves the entire list of email identifiers in the monitored mailbox via the IMAP protocol and records the last email identifier as the email baseline identifier. When performing the email protocol verification task, the system re-acquires the entire list of email identifiers, locates the position of the email baseline identifier in the current list of all email identifiers, and only traverses the newly added emails corresponding to the email identifiers to be verified after the email baseline identifier. In the newly added emails, the system performs a double match according to preset subject keywords (such as "IO EVENT") and body keywords (such as the router serial number "DI_6218C1049198"). If the match is successful, the verification is considered successful. All IMAP operations are protected by fine-grained mutex locks, and the NOOP command sending and verification query of the keep-alive thread share the same lock to ensure the atomicity of the operation.

[0047] In one embodiment of this application, the system further includes a verification result aggregation and alarm step. After all verification tasks are completed, the system aggregates the verification results for each monitored router, including the number of successful items, the number of failed items, and the response time for each item. The system also calculates the cumulative success rate based on historical verification records, which is the ratio of the total number of historical successful instances to the total number of historical triggers. If there are any failed verification monitoring items, the system constructs a structured alarm message, which includes at least the router name or identifier, serial port number, a list of failed monitoring items, and the cumulative success rate. Subsequently, the system pushes this structured alarm message to a third-party communication interface, and the alarm is triggered only when there is a verification failure.

[0048] In other embodiments of this application, the independent waiter queue is not limited to an in-process list implementation; it can also be replaced by a centralized message queue middleware such as Redis Streams or RabbitMQ. All verification threads subscribe to matching conditions through the message queue middleware, which is responsible for message routing and persistence. This implementation is suitable for scenarios where the number of monitored routers exceeds six or where cross-process / cross-machine collaborative verification is required.

[0049] In other embodiments of this application, the protocol monitor can be deployed as a cloud microservice, such as an MQTT Broker using a cloud-hosted service, email monitoring using a cloud email service interface, SNMP Trap forwarding via a cloud proxy, verification logic via REST API calls, and a web front-end for the user interface. This implementation is suitable for scenarios where testers need to remotely monitor router test environments distributed in various locations or where multiple teams share verification services.

[0050] In other embodiments of this application, the trigger-transmission-verification three-stage closed loop is not limited to DI / DO scenarios and can be extended to the field of industrial automation to verify whether the SCADA system correctly responds to alarms after the PLC outputs a signal, whether the gateway correctly converts Modbus RTU input to Modbus TCP output, and whether multiple alarm channels are correctly triggered after a sensor exceeds a threshold. It can also be extended to the field of IoT devices to verify whether multiple smart devices perform linked actions after a smart door lock is triggered, whether the T-BOX reports through multiple communication channels after a vehicle event is triggered, and whether multiple alarms are triggered via SMS / email / MQTT after an environmental sensor exceeds a threshold.

[0051] In other embodiments of this application, the verification channels are not limited to SMS, email, digital output, cellular network, MQTT, and SNMP. Other protocol verification channels, such as HTTP callback, WebSocket push, CoAP message, and LoRa uplink, can be extended according to the device's service capabilities. Each new channel only needs to implement two components—a protocol monitor and a verification method—to connect to the system, following the same dual-mode degradation and independent waiter queue pattern.

[0052] Those skilled in the art will understand that the specific parameters described in the above embodiments, such as the timeout period of 120 seconds, the keep-alive command sending cycle of 60 seconds, the character sending interval of 50 milliseconds, and the message buffer queue capacity limit of 10 messages, are merely illustrative examples and do not constitute a limitation on the scope of protection of this application. In actual implementation, these parameters can be adjusted according to the specific performance of the device under test, the network environment, and the testing requirements.

[0053] Although the invention has been specifically shown and described in conjunction with preferred embodiments, those skilled in the art should understand that various changes in form and detail may be made to the invention without departing from the spirit and scope of the invention as defined in the appended claims, all of which shall be within the scope of protection of the invention.

Claims

1. A method for verifying multi-protocol service operations, characterized in that, Includes the following steps: In response to a trigger command, the first device is controlled to output a trigger signal, so that at least one second device receives the trigger signal and triggers the execution of a pre-configured service operation; an independent waiter queue is created for each protocol verification task corresponding to each second device; each waiter queue and its corresponding matching conditions are registered to the waiter list of the protocol monitor; When the protocol monitor receives a protocol message, it iterates through the list of waiters and distributes the protocol message to the matching waiter queue according to the matching conditions. Each protocol verification task retrieves the protocol message from its corresponding independent waiter queue and confirms the execution result of the business operation based on the protocol message.

2. The multi-protocol service operation verification method according to claim 1, characterized in that, The matching conditions include topic filtering conditions for the MQTT protocol and / or source IP address matching conditions for the SNMP protocol. When the protocol message is an MQTT message, it is checked whether the topic of the MQTT message contains the topic filtering conditions of the waiter queue. If so, the MQTT message is distributed to the waiter queue. When the protocol message is an SNMP Trap message, it is checked whether the source IP address of the SNMP Trap message matches the source IP address matching conditions of the waiter queue. If so, the SNMP Trap message is distributed to the waiter queue.

3. The multi-protocol service operation verification method according to claim 2, characterized in that, The protocol verification task retrieves the protocol message from its respective independent waiting queue, specifically including: the protocol verification task blocking and retrieving the protocol message from its corresponding independent waiting queue within a preset timeout period; if the protocol message is successfully retrieved within the preset timeout period, the protocol verification task is deemed to have passed verification; if the protocol message is not retrieved within the preset timeout period, the protocol verification task is deemed to have failed verification; after completing the verification, the corresponding waiting queue is removed from the waiting list.

4. The multi-protocol service operation verification method according to claim 3, characterized in that, The business operation includes email sending, the protocol verification task includes email protocol verification, and the method further includes: upon responding to the trigger instruction, retrieving the entire list of email identifiers of the monitored mailbox via the IMAP protocol, and recording the last email identifier in the entire list of email identifiers as the email baseline identifier; when executing the email protocol verification task, retrieving the entire list of email identifiers of the monitored mailbox, locating the position of the email baseline identifier in the entire list of email identifiers, and only traversing the newly added emails corresponding to the email identifiers to be verified after the email baseline identifier; in the newly added emails, performing dual matching according to preset subject keywords and body keywords, and if the matching is successful, determining that the execution result of the email sending operation has been verified.

5. The multi-protocol service operation verification method according to claim 3, characterized in that, It also includes obtaining a log line count baseline, comprising the following steps: After the second device performs the business operation, a log line count statistics command is sent to the second device via a serial port, and the total number of lines in the current log file is extracted from the returned result as the log line count baseline; The log line count baseline is used to read newly added log lines after the log line count baseline for log verification when the protocol verification channel is unavailable.

6. The multi-protocol service operation verification method according to claim 5, characterized in that, It also includes dual-mode degradation verification, comprising the following steps: For any of the aforementioned protocol verification tasks, end-to-end verification is first performed through the target protocol channel corresponding to the protocol verification task to confirm whether the service operation has been successfully delivered to the target end; the availability of the target protocol channel is checked, and if it is unavailable, the system automatically switches to log verification mode; the log verification mode includes: based on the log line count baseline, sending a log read instruction to the second device to read from the next line after the log line count baseline, obtaining the newly added log lines after the log line count baseline, and performing keyword matching verification in the newly added log lines; wherein, the verification accuracy of the end-to-end verification is higher than that of the log verification mode, the end-to-end verification is used to confirm that the execution result of the service operation has been delivered to the target server, and the log verification mode is used to confirm that the second device has locally executed the sending action of the service operation.

7. The multi-protocol service operation verification method according to claim 6, characterized in that, The method further includes the following steps: For a first type of protocol verification task based on serial communication, multiple first-type protocol verification tasks share a serial port mutex to ensure the atomic execution of serial port commands; For a second type of protocol verification task based on network communication, multiple second-type protocol verification tasks execute in true parallel mode, unaffected by the serial port mutex; The communication protocols corresponding to the first type of protocol verification tasks include at least one of the following: SMS protocol, digital output protocol, cellular network dialing protocol; The communication protocols corresponding to the second type of protocol verification tasks include at least one of the following: MQTT protocol, email protocol, SNMP protocol.

8. The multi-protocol service operation verification method according to claim 1, characterized in that, The trigger command is generated manually by the user or automatically by a timer; the first device and each of the second devices are connected by a signal cable, and the trigger signal is transmitted from the first device to the digital input port of each of the second devices through the signal cable; The step of responding to a trigger command and controlling the first device to output a trigger signal specifically includes: sending a digital output trigger command to the first device via the Telnet protocol to control the digital output port of the first device to output the trigger signal; When sending the digital output trigger command via the Telnet protocol fails, the current Telnet connection is automatically disconnected and a new Telnet connection is established before sending the digital output trigger command again.

9. The multi-protocol service operation verification method according to claim 1, characterized in that, The business operations also include SMS sending operations, digital output operations, cellular network dialing operations, MQTT message publishing operations, and / or SNMP Trap sending operations; the protocol verification tasks include at least two of the following: SMS verification tasks, email verification tasks, digital output verification tasks, cellular network verification tasks, MQTT verification tasks, and SNMP verification tasks; the method also includes: initializing the corresponding global protocol monitor instance according to the protocol monitor enable switch in the configuration file, wherein the global protocol monitor instance includes at least one of the following: IMAP monitor, MQTT client, and SNMP Trap receiving thread.

10. The multi-protocol service operation verification method according to claim 1, characterized in that, It also includes verification result aggregation and alarm steps, specifically including: aggregating the verification results of each protocol verification task, the verification results including the number of successful items, the number of failed items, and the response time of each protocol verification task; calculating the cumulative success rate based on the current verification results and historical verification records, the cumulative success rate being the ratio of the total number of historical successful attempts to the total number of historical triggers; if there are protocol verification tasks that have failed, constructing a structured alarm message, the structured alarm message including a second device identifier, a list of failed protocol verification tasks, the response time of each failed task, and the cumulative success rate; and pushing the structured alarm message to a third-party communication interface to output an alarm notification.

Images