Communication flow control method, apparatus, device, and storage medium

Abstract

The application discloses a communication flow control method, device and equipment and a storage medium, and relates to the technical field of communication flow control, and specifically discloses the following technical scheme: a step sequence corresponding to a to-be-executed communication flow and a conditional transfer rule are acquired; a target primitive instance matched with a current flow step is acquired from a preset primitive pool, and the target primitive instance is activated; the target primitive instance is driven to execute an asynchronous communication operation, and a step execution result and a condition identifier fed back by the target primitive instance are received; a target step is determined from the step sequence according to the step execution result, the condition identifier and the conditional transfer rule, and the current flow step is updated to the target step. According to the application, the step sequence corresponding to the to-be-executed communication flow and the conditional transfer rule are acquired, and the asynchronous operation and the active feedback execution result are encapsulated by using the primitive instance. Compared with the prior art, the application reduces the state management complexity, eliminates the logic fragmentation, and thus improves the development and maintenance efficiency of the embedded communication flow.

Description

Technical Field

[0001] This invention relates to the field of embedded system communication technology, and in particular to a communication flow control method, apparatus, device, and storage medium. Background Technology

[0002] In the field of embedded system communication, the communication process between resource-constrained devices (such as charging piles and smart meters) and cloud platforms is usually implemented using state machines or asynchronous callback mechanisms. Taking the login process of a charging pile as an example, it involves multiple business steps such as login authentication, rate verification, and rate update.

[0003] In existing technologies, traditional implementation schemes suffer from the following technical drawbacks: First, developers typically orthogonally combine each step of the business process with the underlying communication protocol states (such as send, wait, timeout, retry, completion, and failure), resulting in the system needing to maintain a large number of discrete states. For example, a simple process containing three business steps can exponentially increase the number of states to more than ten or even dozens, a phenomenon known as "state explosion." Second, to handle asynchronous communication events, existing solutions rely on multiple layers of nested callback functions, fragmenting the originally continuous business logic into multiple different source files or code snippets, creating "callback hell." State explosion leads to complex and error-prone state transition logic, while logic fragmentation drastically reduces code readability and maintainability. These problems collectively result in low development and maintenance efficiency for embedded communication processes. For example, during the development phase of an embedded communication process, adding or modifying a communication step can take several days, while during the maintenance phase, locating and fixing a logical defect takes an average of several hours.

[0004] Therefore, there is an urgent need for a communication flow control method that can reduce the complexity of state management and eliminate logic fragmentation, thereby improving the development and maintenance efficiency of embedded communication processes. Summary of the Invention

[0005] The main objective of this invention is to provide a communication flow control method, apparatus, device, and storage medium, which aims to solve the technical problem of low development and maintenance efficiency of embedded communication flows due to state explosion and logic fragmentation in existing embedded communication flows.

[0006] To achieve the above objectives, the present invention provides a communication flow control method, the method comprising the following steps: Obtain the step sequence and conditional transfer rules corresponding to the communication process to be executed; For the current process step, obtain the target primitive instance that matches the current process step from the preset primitive pool, and activate the target primitive instance; Drive the target primitive instance to perform asynchronous communication operations, and receive the step execution results and condition identifiers fed back by the target primitive instance; Based on the execution result of the step, the condition identifier, and the condition transfer rule, the target step is determined from the step sequence, and the current process step is updated to the target step.

[0007] Optionally, the step of driving the target primitive instance to perform asynchronous communication operations and receiving the execution result and condition identifier from the target primitive instance includes: Invoke the asynchronous processing interface of the target primitive instance, wherein the asynchronous processing interface saves the current execution breakpoint based on the coroutine control structure; Within the target primitive instance, communication encoding or parsing operations are performed, and while waiting for preset communication conditions to be met, the current execution flow is suspended through the coroutine control structure. After the preset communication conditions are met, the execution of the current execution flow is resumed through the coroutine control structure, and the step execution results and condition identifiers fed back by the target primitive instance are received.

[0008] Optionally, the step of receiving the execution result and condition identifier of the target primitive instance includes: When the execution result of the step indicates failure, the pre-configured completion callback function in the communication process to be executed is invoked; In the completion callback function, the reason for failure is determined based on the condition identifier; If the failure is due to a communication timeout, the underlying transmission interface is called to disconnect the current connection and a delayed reconnection task is scheduled.

[0009] Optionally, before the step of obtaining a target primitive instance matching the current process step from a preset primitive pool and activating the target primitive instance, the method further includes: Define multiple types of primitive instances, including request primitives, callback primitives, notification primitives, and push primitives, where different types of primitive instances correspond to different communication modes; The various types of primitive instances are registered to a preset primitive pool, which is used to provide primitive instances during process execution.

[0010] Optionally, the step of determining the target step from the step sequence based on the step execution result, the condition identifier, and the condition transition rule includes: When the execution result of the step is a completed state, multiple transfer records in the conditional transfer rule are queried according to the identifier of the current process step and the condition identifier. Each transfer record includes the source step identifier, the condition identifier, and the target step identifier. Obtain the identifier of the current process step and the target step identifier that matches the condition identifier from the condition transition rules; The process step corresponding to the target step identifier is identified as the target step, and the current process step is updated to the target step. Accordingly, after the step of determining the process step corresponding to the target step identifier as the target step and updating the current process step to the target step, the method further includes: The process loop counter is incremented, and when the process loop counter exceeds a preset threshold, the communication process to be executed is forcibly terminated.

[0011] Optionally, after the step of receiving the execution result and condition identifier of the target primitive instance, the method further includes: When the result of the step execution is a skipped state, extract the number of skipped steps from the step execution result; Add the index of the current process step to the number of skipped steps to obtain the target step index; The process step corresponding to the target step index in the step sequence is determined as the target step.

[0012] Optionally, after the step of determining the target step from the step sequence based on the step execution result, the condition identifier, and the condition transition rule, and updating the current process step to the target step, the method further includes: Determine whether the target step is a valid step in the step sequence; If the target step is a valid step, then return to the step of obtaining the target primitive instance that matches the current process step from the preset primitive pool and activating the target primitive instance; If the target step is invalid, the pending communication process ends and the pre-configured completion callback function in the pending communication process is called.

[0013] Furthermore, to achieve the above objectives, the present invention also proposes a communication flow control device, the device comprising: The information acquisition module is used to acquire the step sequence and conditional transfer rules corresponding to the communication process to be executed; The primitive matching module is used to obtain a target primitive instance that matches the current process step from a preset primitive pool and activate the target primitive instance. The feedback receiving module is used to drive the target primitive instance to perform asynchronous communication operations and receive the step execution results and condition identifiers fed back by the target primitive instance; The step jump module is used to determine the target step from the step sequence based on the step execution result, the condition identifier, and the condition transfer rule, and update the current process step to the target step.

[0014] Furthermore, to achieve the above objectives, the present invention also proposes a communication flow control device, the device comprising: a memory, a processor, and a communication flow control program stored in the memory and executable on the processor, the communication flow control program being configured to implement the steps of the communication flow control method as described above.

[0015] In addition, to achieve the above objectives, the present invention also proposes a storage medium storing a communication flow control program, which, when executed by a processor, implements the steps of the communication flow control method described above.

[0016] This invention discloses a method for obtaining the step sequence and conditional transition rules corresponding to a communication process to be executed. For the current process step, a target primitive instance matching the current process step is obtained from a preset primitive pool and activated. The target primitive instance is driven to perform an asynchronous communication operation, and the step execution result and condition identifier fed back by the target primitive instance are received. Based on the step execution result, the condition identifier, and the conditional transition rules, a target step is determined from the step sequence, and the current process step is updated to the target step. Because this invention decouples business logic from communication state through step sequences and conditional transition rules, and encapsulates asynchronous operations using primitive instances, it automatically determines and jumps to the target step based on the fed-back step execution result and condition identifier, combined with the conditional transition rules. Compared to existing technologies, this invention reduces state management complexity and eliminates logic fragmentation, thereby improving the development and maintenance efficiency of embedded communication processes. Attached Figure Description

[0017] Figure 1 This is a flowchart illustrating the first embodiment of the communication flow control method of the present invention; Figure 2 This is a schematic diagram comparing the passive driving mode and the traditional active polling mode corresponding to the communication flow control method of the present invention; Figure 3 This is a flowchart illustrating the second embodiment of the communication flow control method of the present invention; Figure 4 This is a flowchart illustrating the third embodiment of the communication flow control method of the present invention; Figure 5This is a structural block diagram of the first embodiment of the communication process control device of the present invention; Figure 6 This is a schematic diagram of the communication process control device of the hardware operating environment involved in the embodiments of the present invention.

[0018] The realization of the objective, functional features and advantages of the present invention will be further explained in conjunction with the embodiments and with reference to the accompanying drawings. Detailed Implementation

[0019] It should be understood that the specific embodiments described herein are for illustrative purposes only and are not intended to limit the scope of the invention.

[0020] This invention provides a communication flow control method, referring to... Figure 1 , Figure 1 This is a flowchart illustrating the first embodiment of the communication flow control method of the present invention.

[0021] In this embodiment, the communication flow control method includes steps S10 to S40: Step S10: Obtain the step sequence and conditional transfer rules corresponding to the communication process to be executed.

[0022] It should be noted that the executing entity in this embodiment can be a computer server device with data processing, network communication, and program execution functions applied in a communication control scenario, such as a server, tablet computer, or personal computer, or an electronic device capable of performing the above functions (such as a communication flow control device). The following uses a system including a communication flow control device (hereinafter referred to as the system) as an example to illustrate this embodiment and the following embodiments.

[0023] It should be understood that the aforementioned communication process to be executed can refer to a complete communication service process that the system needs to complete, such as the login authentication process of the charging pile, the data reporting process, or the remote control process.

[0024] It should be explained that the above-mentioned sequence of steps can refer to a sequence formed by arranging multiple steps that make up the communication process to be executed in the order of execution, with each step corresponding to a communication primitive. For example, the sequence of steps in a charging pile login process may include a login step, a rate verification step, and a rate update step.

[0025] Furthermore, the aforementioned conditional transition rules can refer to a set of rules used to describe the jump relationship between steps under different conditions. Each rule can define the correspondence between the source step, the condition identifier, and the target step.

[0026] Understandably, the source step can refer to the currently executing step in the communication process. It is the starting point for process transitions, corresponding to a specific position in the step sequence (e.g., the "login authentication" step in a login process). The condition identifier can refer to a result code actively returned after the current primitive instance completes execution. It is not all the states within the primitive, but a highly generalized classification result (e.g., "success," "failure," "timeout," or a custom "rate matching / mismatch"), used to trigger different transition branches. The target step can refer to the next process step to be executed (e.g., if the previous "login authentication" result was "success," then the target step is "rate verification"; if the result was "failure," then the target step is "process end").

[0027] In its implementation, before initiating a communication process, the system first obtains a pre-configured sequence of steps and corresponding conditional transition rules. The step sequence is stored in system memory as an array or linked list, with each element pointing to a definition of a process step, including the step index and the primitive type identifier corresponding to the step. The conditional transition rules are stored in a transition table, with each transition record containing at least a source step identifier, a condition identifier, and a target step identifier. By reading this configuration information, the system provides a basis for subsequent process scheduling and step jumps.

[0028] For ease of understanding, the following explanation uses examples, but does not impose specific limitations on this embodiment. For instance, after powering on, the charging pile device needs to execute a login process. The system's pre-configured step sequence is: [Step 0: Login authentication, Step 1: Rate verification, Step 2: Rate update]. The system also configures 7 conditional transition rules, such as: when the source step is Step 0 and the condition is marked as successful, the target step is Step 1; when the source step is Step 1 and the condition is marked as custom condition 0 (rate matching), the target step is process end. When initiating the login process, the system first obtains the above step sequence and conditional transition rules for subsequent process control.

[0029] Step S20: For the current process step, obtain the target primitive instance that matches the current process step from the preset primitive pool, and activate the target primitive instance.

[0030] It should be understood that the aforementioned current process step can refer to the step that the system is currently processing or about to begin processing when executing a communication process. Each process step corresponds to a communication primitive instance, used to complete a specific communication operation, such as sending a login request or waiting for a response.

[0031] Understandably, the aforementioned pre-defined primitive pool can refer to a static storage area pre-allocated by the system during compilation or initialization to store primitive instances. Each primitive instance in the primitive pool can be reused during runtime without dynamic memory allocation.

[0032] It should be noted that the aforementioned target primitive instance can refer to a specific primitive object selected from the primitive pool that matches the type and function of the current process step, such as an instantiated login request primitive. The aforementioned activation can refer to the process of switching a primitive instance from an idle state to an active state. Activation operations typically include setting the primitive instance's internal flags and resetting internal state variables (such as retry counters, timer initial values, etc.) to prepare it for process execution.

[0033] In its implementation, after acquiring the step sequence and conditional transition rules, the system begins to execute each step in the sequence sequentially. The system first determines the current process step to be processed, indicated by an internally maintained step index variable, for example, an initial value of 0 representing the first step. Next, the system accesses a preset primitive pool based on the current process step's identifier information, such as the step number or step type code. This preset primitive pool is an array of structures or objects, where each element stores a pointer or index to a primitive instance. The system traverses or directly indexes the primitive pool to find a primitive instance that matches the current process step. The matching criteria can be a primitive type identifier pre-specified in the step configuration, for example, step 0 corresponds to the login request primitive. After finding a matching primitive instance, the system calls the primitive instance's activation interface, which executes activation logic: setting the primitive instance's internal state field to "activated," resetting the execution result field to its default value, clearing the condition identifier field, and initializing the coroutine control block (if coroutines are used). After activation, the target primitive instance is in a pending execution state, waiting to be scheduled.

[0034] It should be noted that by pre-compiling and statically allocating primitive pools and instances, direct binding and on-demand activation between process steps and primitive instances are achieved. This completely eliminates the uncertainty and memory fragmentation risks caused by dynamic memory allocation at runtime, ensuring that memory usage is predictable and controllable throughout the process in resource-constrained embedded systems. At the same time, this mechanism cohedes each business process step and its corresponding communication behavior within a single primitive instance. The process framework only needs to activate the existing instance to drive step execution, without having to recreate or parse primitive objects every time a step is switched. This completely decouples the process scheduling logic from the complex communication state within the primitives, significantly reducing the coupling of step transitions and avoiding the logic dispersion and state expansion caused by the increase in steps in traditional solutions. This makes the implementation of the entire communication process more modular and linear, ultimately improving the development efficiency, maintainability, and long-term stability of embedded communication processes.

[0035] Step S30: Drive the target primitive instance to perform asynchronous communication operations, and receive the step execution results and condition identifiers fed back by the target primitive instance.

[0036] It should be understood that the above asynchronous communication operation can refer to the operation mode in which the primitive instance does not block the caller thread when performing the communication task. After the primitive instance initiates a communication operation (such as sending a request or waiting for a response), it returns immediately. The actual communication process is carried out in the background, and the caller is notified through state changes or callback mechanisms when events such as communication completion or timeout occur.

[0037] It should be explained that the execution result of the above steps can refer to the execution status information fed back to the process framework after the primitive instance completes the current step operation. For example, the execution result of a step can include a completion status, a skipped status, a failure status, or a waiting status. The above condition identifiers can refer to the identifier information attached to the primitive instance during execution to distinguish different completion reasons or branch conditions. For example, condition identifiers can represent success, failure, timeout, retry, or multiple user-defined condition types.

[0038] In its implementation, after activating the target primitive instance, the system calls the driver interface of the target primitive instance, triggering it to perform asynchronous communication operations. When the driver interface is called, the target primitive instance begins executing its defined communication logic, such as encoding request data, calling the underlying sending interface to send data, and starting a timeout timer. It then immediately returns control to the system without waiting for a server response. The system continues to execute other tasks or re-drives the primitive instance using a polling method. During or after the asynchronous communication operation, the target primitive instance sets the step execution result and condition flag based on the current communication state. The step execution result can be one of completed, skipped, failed, or waiting; the condition flag can be success, failure, timeout, or a custom value. The system receives the feedback information by reading the step execution result field and condition flag field stored internally by the target primitive instance. The system is not concerned with the specific communication details within the primitive instance; it only makes subsequent process decisions based on the values ​​of the two fields read.

[0039] To facilitate understanding, the following explanation uses examples, but does not impose specific limitations on this embodiment. For example, in the charging pile login process, the currently active target primitive instance is a login request primitive. After the system calls the driver method of this primitive, the primitive internally constructs a login request message, sends it to the server through the underlying network interface, starts a 1000-millisecond timeout timer, and then returns immediately. During subsequent system polling, the system reads the step execution result and condition flag of the primitive again. If the server responds successfully before the timeout, the primitive internally sets the step execution result to DONE and the condition flag to SUCCESS. After reading these two values, the system can obtain the information fed back by the primitive. If the server does not respond and a timeout occurs, the primitive sets the step execution result to FAIL and the condition flag to TIMEOUT.

[0040] To improve the development efficiency and long-term stability of embedded communication processes, the step of driving the target primitive instance to perform asynchronous communication operations and receiving the step execution results and condition identifiers fed back by the target primitive instance includes: calling the asynchronous processing interface of the target primitive instance, wherein the asynchronous processing interface saves the current execution breakpoint based on a coroutine control structure; performing communication encoding or communication parsing operations inside the target primitive instance, and suspending the current execution flow through the coroutine control structure while waiting for preset communication conditions to be met; and resuming the execution of the current execution flow through the coroutine control structure after the preset communication conditions are met, and receiving the step execution results and condition identifiers fed back by the target primitive instance.

[0041] It is understandable that the aforementioned asynchronous processing interface can refer to the method function provided by the primitive instance for performing asynchronous communication operations. The internal implementation of this method function is based on a coroutine mechanism, which can complete the communication operation without blocking the calling thread.

[0042] It should be noted that the aforementioned coroutine control structure refers to a lightweight data structure used to store the execution state of a coroutine. It typically contains only a program counter or line number variable to record the current position of the coroutine. In a Protothread coroutine, the coroutine control structure occupies only 2 bytes of storage space.

[0043] It should be understood that the aforementioned current execution breakpoint can refer to a marker indicating the location of the code being executed when the coroutine is currently suspended. When the coroutine resumes execution, the program continues execution from that marked location. The aforementioned communication encoding operation can refer to the process by which the primitive instance fills the data to be sent into the transmit buffer according to the protocol format, such as converting voltage and current values ​​into network byte order. The aforementioned communication parsing operation can refer to the process by which the primitive instance extracts data from the receive buffer and parses out the values ​​of each field according to the protocol format.

[0044] Understandably, the aforementioned preset communication conditions can refer to specific events or states that the primitive instance needs to wait for to be met during asynchronous communication, such as receiving a complete acknowledgment message, waiting for the timeout timer to expire, or the underlying transmission completing. The aforementioned suspension of the current execution flow can refer to the coroutine actively releasing CPU control, saving the current execution breakpoint, and returning to the scheduler. In this case, the primitive instance does not consume CPU resources for idle waiting. The aforementioned resumption of the current execution flow can refer to the mechanism whereby, after the scheduler calls the primitive instance's asynchronous processing interface again, the coroutine continues execution from the previously saved execution breakpoint.

[0045] In its implementation, after activating a target primitive instance, the system calls its asynchronous processing interface. This asynchronous processing interface integrates execution logic based on a coroutine control structure. When this interface is called for the first time, the breakpoint stored within the coroutine control structure is the function entry point, and the system begins executing the business code defined by the primitive instance. Next, the target primitive instance performs communication encoding or parsing operations. For example, for request primitives, the primitive instance fills the data to be sent into the sending buffer according to the protocol encoding; for callback primitives, the primitive instance parses the content sent by the server from the receiving buffer. After performing encoding or parsing operations, the primitive instance may need to wait for external conditions, such as waiting for the server to return a response message, waiting for the physical layer to complete the transmission interruption, or waiting for a timeout period. While waiting for the aforementioned preset communication conditions to be met, the primitive instance suspends the current execution flow through the coroutine control structure. The suspension operation saves the current line number in the coroutine control structure and then immediately returns from the asynchronous processing interface without blocking other tasks in the system. When the preset communication conditions are met (e.g., the underlying protocol stack notifies that a complete response has been received, or a timeout timer is triggered), the system will call the asynchronous processing interface of the target primitive instance again. At this time, the coroutine control structure resumes the execution of the current execution flow based on the previously saved breakpoint information, that is, continues execution from the last suspended code position. After resuming execution, the primitive instance checks the communication result and sets the step execution result (e.g., completion, failure, or waiting) and condition flags (e.g., success, timeout, or custom value). Subsequently, the system reads the above step execution result and condition flags for subsequent process decisions.

[0046] It should be noted that by introducing an asynchronous processing mechanism based on a coroutine control structure, the originally fragmented and nested callback logic is transformed into a linear and continuously executable code flow, thereby fundamentally eliminating the callback hell problem and significantly improving the readability and maintainability of the communication process. At the same time, this coroutine mechanism only saves a very small execution breakpoint state when waiting for communication conditions without retaining the complete stack space, which greatly reduces the memory consumption of embedded devices when performing multi-step asynchronous communication. This makes it possible to achieve high-concurrency, non-blocking communication processes in resource-constrained environments, thereby comprehensively improving the development efficiency and long-term stability of embedded communication processes.

[0047] Step S40: Based on the step execution result, the condition identifier, and the condition transfer rule, determine the target step from the step sequence, and update the current process step to the target step.

[0048] It should be understood that the aforementioned target step can refer to the next process step that the system determines to be executed based on the execution result and condition identifier of the current process step, combined with the condition transfer rules.

[0049] It should be explained that the target step can be a step following the current step in a step sequence, the current step itself (e.g., a loop waiting), or an invalid step indicating the end of the process. The above update can refer to the process of the system modifying the internally maintained pointer or index variable of the current process step from its original value to the value corresponding to the target step.

[0050] It should be noted that the step of determining the target step from the step sequence based on the step execution result, the condition identifier, and the condition transfer rule includes: when the step execution result is in a completed state, querying multiple transfer records in the condition transfer rule based on the identifier of the current process step and the condition identifier, each transfer record including the source step identifier, the condition identifier, and the target step identifier; obtaining the target step identifier that matches the identifier of the current process step and the condition identifier from the condition transfer rule; determining the process step corresponding to the target step identifier as the target step, and updating the current process step to the target step.

[0051] In its implementation, after receiving the step execution result and condition identifier from the target primitive instance, the system determines the target step from the step sequence based on the result, the condition identifier, and pre-acquired conditional transition rules. The system first reads the step execution result to determine the current step's execution status. When the result is "complete," the system indicates that the primitive instance has successfully completed the communication operation and needs to jump to the next step according to the conditional transition rules. The system uses the identifier of the current process step (e.g., step index or step number) and the condition identifier from the target primitive instance as query keys to search for a matching transition record in the conditional transition rules. Each transition record defines the target step identifier that should jump to under a specific condition identifier, starting from a specific source step. If a matching transition record is found, the system extracts the target step identifier from that record and determines the corresponding target step from the step sequence based on that identifier. Next, the system updates the current process step to the target step, i.e., it modifies the current step index variable stored internally to point to the target step. After the update, the system can execute the primitive instance corresponding to the target step in the next scheduling round.

[0052] For example, in the charging pile login process, the current step is the login authentication step (step index 0). The system receives a feedback from the target primitive instance indicating a completed state and a successful condition flag. The system's pre-configured conditional transition rules include a record: source step flag 0, condition flag successful, target step flag 1. Based on the current step flag 0 and the successful condition flag, the system finds the above record and extracts the target step flag 1. Subsequently, the system searches for the step corresponding to index 1 in the step sequence, which is the rate verification step. The system updates the internally maintained current step index variable from 0 to 1. In the next scheduling round, the system will execute the primitive instance corresponding to the rate verification step.

[0053] To ensure system stability and robustness, and to avoid the risk of the entire communication module resetting or crashing due to a single process malfunction, after the step of determining the process step corresponding to the target step identifier as the target step and updating the current process step to the target step, the method further includes: incrementing a process loop counter, and forcibly terminating the communication process to be executed when the process loop counter exceeds a preset threshold.

[0054] It should be explained that the aforementioned process loop counter can refer to an integer variable maintained by the system for each communication process to be executed, used to record the number of steps jumps or loop executions in the current communication process. The counter increments each time a step jump occurs. The aforementioned preset threshold can refer to a pre-set maximum allowed number of loops, used to prevent the process from entering an infinite loop due to configuration errors or abnormal conditions. For example, the preset threshold could be set to 8 times. The aforementioned forced termination can refer to the system actively interrupting the execution of the communication process to be executed, no longer continuing to execute subsequent steps, and setting the process status to terminated, no longer participating in subsequent scheduling.

[0055] In its implementation, the system increments the process loop counter after updating the current process step to the target step, or when executing step jump logic. The increment operation is typically performed after each valid step jump. The system first reads the currently stored value of the process loop counter, increments it by 1, and then writes the result back to the process loop counter variable. After incrementing, the system compares the incremented counter value with a preset threshold. This preset threshold is obtained from the configuration during process initialization or uses a system default value. If the system determines that the process loop counter value exceeds the preset threshold, i.e., reaches or exceeds the preset maximum allowed number of loops, the system determines that the current communication process may have a configuration error or logical anomaly, such as a loop formed in the conditional transfer rule without a jump condition. In this case, the system performs a forced termination operation: the system sets the internal state of the communication process to be executed to the terminated state, clears the current step index, stops further execution of the process, and optionally calls the process completion callback function with a failure reason code. After termination, the communication process to be executed no longer participates in the system's main loop scheduling.

[0056] To facilitate understanding, the following explanation uses examples, but does not impose specific limitations on this embodiment. For example, assume that the system is configured with a preset threshold of 8 times for the charging pile login process. When the process executes normally, after each step jump (such as jumping from the login step to the rate verification step, and then to the rate update step), the process loop counter increments sequentially to 1, 2, and 3. If a loop is formed in the step sequence due to an incorrect transfer table configuration (for example, jumping back to the login step after a rate verification failure, and then the login step jumping back to the rate verification step, forming an infinite loop), the process loop counter will increment after each loop is completed. When the counter value reaches 9, the system determines that the counter exceeds the preset threshold of 8, and thus forcibly terminates the login process to prevent the system from getting stuck in an invalid loop. The system can then call a pre-configured error handling callback to report the process execution exception to the upper layer.

[0057] It should be understood that by incrementing the loop counter during execution and forcibly terminating the communication process when it exceeds a preset threshold, infinite loops caused by misconfigured conditional transfer rules, logical defects, or abnormal branches can be effectively prevented. This protection mechanism ensures that even if there are design flaws in the upper-layer business logic, the communication process will not permanently occupy processing resources or cause the system to freeze, thereby guaranteeing the long-term operational stability and system robustness of embedded devices and avoiding the risk of the entire communication module resetting or crashing due to the loss of control of a single process.

[0058] It should be added that when the execution result of the above step is a failure, the pre-configured completion callback function in the communication process to be executed is called; in the completion callback function, the reason for failure is determined according to the condition identifier; if the reason for failure is communication timeout, the underlying transmission interface is called to disconnect the current connection and a delayed reconnection task is scheduled.

[0059] It should be understood that the aforementioned completion callback function can refer to a function pointer pre-configured in the communication process to be executed. When the process finishes execution (whether successfully completed or terminated with failure), the system will call this function. The completion callback function is used for cleanup work after the execution process ends, such as releasing resources, reporting execution results, or triggering exception recovery operations.

[0060] Understandably, the aforementioned failure reasons can refer to specific categories of causes leading to the execution failure of primitive instances, such as communication timeouts, protocol parsing errors, server rejection, or physical layer failures. The system distinguishes different failure reasons through the conditional identifiers returned by the primitive instances. The aforementioned underlying transport interface can refer to a set of function interfaces provided by the system's underlying network protocol stack, used to perform actual transport layer operations, such as establishing connections, disconnecting connections, sending data, and receiving data.

[0061] It should be noted that the aforementioned delayed reconnection task can refer to a task whose execution is delayed, and which performs network reconnection operations after a specified delay period has elapsed. Delayed reconnection tasks are typically implemented through the system's timer mechanism or task scheduling mechanism, rather than being executed immediately.

[0062] In its implementation, after receiving the step execution result from the target primitive instance, the system first determines whether the step execution result is a failure. If the system determines that the step execution result is a failure, it will not continue executing subsequent steps in the step sequence, but will immediately call the pre-configured completion callback function in the communication process to be executed. The system reads the function pointer of the completion callback function from the flow control block and executes the function, passing the context information of the current process (such as the process identifier, step execution result, and condition identifier) ​​as parameters to the completion callback function. After entering the completion callback function, the system determines the reason for failure based on the condition identifier fed back by the target primitive instance. For example, a condition identifier of timeout indicates that the failure reason is a communication timeout, and a condition identifier of protocol error indicates that the failure reason is a protocol parsing failure. If the system determines that the failure reason is a communication timeout based on the condition identifier, the system calls the underlying transport interface to disconnect the current connection. The disconnection operation of the underlying transport interface will release the currently occupied socket or connection resources and reset the network state to an idle state. After the connection is lost, the system schedules a delayed reconnection task: the system starts a timer, sets a delay time (e.g., 30 seconds), and registers the reconnection task in the task scheduling queue. When the delay time is reached, the system automatically executes the reconnection task, attempting to re-establish the connection with the server so that subsequent processes can resume normal execution.

[0063] It should be understood that when the execution result of the step returned by the target primitive instance is a failure and the reason for the failure is a communication timeout, the pre-configured completion callback function is called, and the operation of disconnecting the current connection and scheduling the delayed reconnection task is performed centrally in this callback function. This consolidates the exception handling logic scattered in various primitives or callback functions into a framework-level callback function, eliminating the logic fragmentation problem caused by the scattered deployment of exception recovery code in traditional solutions, and improving the automatic recovery capability and maintenance efficiency of the communication process in network anomaly scenarios.

[0064] It should be added that when the execution result of the step is a skipped state, the skipped step number is extracted from the execution result; the index of the current process step is added to the skipped step number to obtain the target step index; and the process step corresponding to the target step index in the step sequence is determined as the target step.

[0065] Understandably, the aforementioned skip state can refer to a value of the step execution result, indicating that the current primitive instance decides to skip several subsequent steps and not execute the primitive instances corresponding to the skipped steps. The aforementioned skipped step number can refer to the number of steps set by the primitive instance during execution, indicating that steps need to be skipped consecutively. The skipped step number is a non-negative integer; for example, a value of 2 indicates skipping the two steps following the current step.

[0066] It should be understood that the aforementioned index can refer to a number used to identify the positional order of process steps in the step sequence, typically starting from 0 and incrementing. For example, the index of the first step in the step sequence is 0, and the index of the second step is 1. The aforementioned target step index can refer to the calculated positional number of the target step to which the jump is expected to occur within the step sequence.

[0067] In its implementation, after receiving the step execution result from the target primitive instance, the system determines whether the result is in a skipped state. If the system determines the result is skipped, it indicates that the current primitive instance actively requests to skip several subsequent specified steps, rather than jumping according to the conditional transition rules. The system extracts the skipped steps from the step execution result. The step execution result can be a structure or a composite value, containing a result status field and a skipped steps field. This skipped steps are pre-set by the target primitive instance during execution. After extracting the skipped steps, the system obtains the index of the current process step. The index of the current process step is provided by a current step index variable maintained internally by the system. The system adds the current process step index to the skipped steps, performing numerical addition to obtain the target step index. For example, if the current step index is 0 and the skipped steps are 2, then the target step index is 2. Next, the system uses the obtained target step index as a positional basis to search for the corresponding process step in the step sequence. If the length of the step sequence is greater than the target step index, then a corresponding process step exists, and the system identifies this process step as the target step. Once the target step is determined, the system updates the current process step to the target step.

[0068] It should be noted that by directly extracting the skipped steps from the execution result when the step execution result is a skipped state, and then adding the current process step index to the skipped steps to locate the target step, a step quantification jump mechanism based on primitive feedback is implemented. This avoids the state bloat and code complexity problems caused by defining state transition paths separately for each conditional branch or writing nested callback logic, thereby reducing the state management complexity of the communication process in the presence of conditional branches, and significantly improving the flexibility and development efficiency of process definition.

[0069] For example, refer to Figure 2 , Figure 2This diagram illustrates a comparison between the passive-driven mode and the traditional active polling mode of the communication flow control method of this invention. The left side of the diagram shows the traditional active polling mode: the framework loop sequentially checks the states of primitives A, B, and C, and then determines the next step based on the state. This mode, requiring active polling of each primitive's state, is prone to state explosion and logic fragmentation, leading to low efficiency in the development and maintenance of embedded communication flows. The right side of the diagram shows the passive-driven mode of this invention: the framework loop first drives the current primitive to execute the `async_process()` asynchronous communication operation, then reads the step execution result (`get_step_result()`), and finally automatically schedules (DONE / SKIP / FAIL) based on the step execution result, condition flags, and conditional transfer rules, and updates the current flow step. This mode, through active feedback of results from primitives combined with conditional transfer rules to drive the flow, solves the state explosion and logic fragmentation problems of the traditional mode, significantly improving the development and maintenance efficiency of embedded communication flows (e.g., reducing new command development time from 2-3 days to 0.5 days, and bug fixing time from 2.5 hours to 0.8 hours).

[0070] This embodiment discloses a method for obtaining the step sequence and conditional transition rules corresponding to a communication process to be executed. For the current process step, a target primitive instance matching the current process step is obtained from a preset primitive pool, and the target primitive instance is activated. The target primitive instance is driven to perform an asynchronous communication operation, and the step execution result and condition identifier fed back by the target primitive instance are received. Based on the step execution result, the condition identifier, and the conditional transition rules, a target step is determined from the step sequence, and the current process step is updated to the target step. Because this embodiment decouples business logic from communication state through step sequences and conditional transition rules, and encapsulates asynchronous operations using primitive instances, it automatically determines and jumps to the target step based on the fed-back step execution result and condition identifier, combined with the conditional transition rules. Compared to existing technologies, this embodiment reduces state management complexity and eliminates logic fragmentation, thereby improving the development and maintenance efficiency of embedded communication processes.

[0071] refer to Figure 3 , Figure 3 This is a flowchart illustrating the second embodiment of the communication flow control method of the present invention.

[0072] Based on the first embodiment described above, in this embodiment, before step S20, steps S101 to S102 are further included: Step S101: Define multiple types of primitive instances, including request primitives, callback primitives, notification primitives and push primitives, where different types of primitive instances correspond to different communication modes.

[0073] It should be noted that the aforementioned request-type primitives refer to primitive types used to implement a communication pattern where the client actively initiates a request and waits for a response from the server. Request-type primitives are suitable for bidirectional interaction scenarios involving client requests and server responses, such as login requests, heartbeat requests, or data upload requests.

[0074] The callback primitives mentioned above refer to primitive types used to implement a communication pattern where the server actively sends requests and the client passively responds. Callback primitives are suitable for reverse interaction scenarios involving server requests and client responses, such as remote start commands, remote stop commands, or parameter setting commands.

[0075] The aforementioned notification primitives refer to primitive types used to implement a communication mode where the client sends data unidirectionally without requiring a server response. Notification primitives are suitable for high-frequency reporting scenarios, such as real-time voltage and current reporting, fault alarm reporting, or heartbeat reporting.

[0076] The aforementioned push primitives refer to primitive types used to implement a communication mode where the server pushes data unidirectionally and the client does not need to respond. Push primitives are suitable for scenarios where the server actively sends information without requiring client confirmation, such as rate update pushes, time synchronization pushes, or QR code update pushes.

[0077] It should be understood that the above communication modes can refer to the interaction methods adopted by the two parties during data exchange, including request-response mode, response-acknowledgment mode, one-way notification mode, and one-way push mode. Different types of primitive instances implement the corresponding communication modes through their respective specific processing flows.

[0078] In its implementation, the system predefines several types of primitive instances, including request primitives, callback primitives, notification primitives, and push primitives. The system distinguishes these four primitive types by defining different classes or structures. Request primitive instances correspond to a communication mode where the client actively initiates a request and waits for a server response. Internally, they include encoding hook functions, response parsing hook functions, a timeout retry mechanism, and a timeout threshold configuration. Callback primitive instances correspond to a communication mode where the server actively sends a request and the client passively responds. Internally, they include parsing hook functions, business processing hook functions, and response encoding hook functions, used to process the instructions sent by the server and return the execution result. Notification primitive instances correspond to a communication mode where the client unidirectionally sends data without requiring a server response. Internally, they include encoding hook functions and a sending completion notification mechanism, but do not include logic for waiting for a response. Push primitive instances correspond to a communication mode where the server unidirectionally pushes data without requiring a client response. Internally, they include parsing hook functions and data persistence hook functions, used to parse the data pushed by the server and perform subsequent storage operations, but do not include logic for sending a response. All four primitive types mentioned above inherit from the same abstract base class and share common fields such as coroutine control structure, step execution result, and condition identifier, but each implements different asynchronous processing logic to adapt to the corresponding communication mode.

[0079] For ease of understanding, the following examples illustrate the concepts, but do not impose specific limitations on this embodiment. For instance, in a charging pile system, the system defines a login request primitive as a request-type primitive instance. This primitive is used to send a login authentication request to the cloud platform and wait for a response. The system defines a remote stop primitive as a callback-type primitive instance. This primitive is used to receive a stop command issued by the cloud platform and return the execution result. The system defines a real-time data reporting primitive as a notification-type primitive instance. This primitive is used to send voltage, current, and power data to the cloud platform at 10-second intervals without waiting for server confirmation. The system defines a rate update push primitive as a push-type primitive instance. This primitive is used to receive rate version information actively pushed by the cloud platform and write it to local flash memory. The above four primitive types—request-type, callback-type, notification-type, and push-type—correspond to four communication modes: request-response, server request-client response, client one-way notification, and server one-way push, respectively.

[0080] Step S102: Register the various types of primitive instances to a preset primitive pool, which is used to provide primitive instances during process execution.

[0081] Understandably, the aforementioned registration refers to the process of associating primitive instances with a predefined primitive pool, enabling the predefined primitive pool to manage, index, and provide these primitive instances. The registration operation typically involves storing a pointer or index of the primitive instance in the primitive pool's storage area and initializing the status information of the corresponding slot in the primitive pool, such as setting the slot to an idle or occupied flag. After registration, the primitive instance becomes a schedulable resource of the primitive pool.

[0082] In its implementation, after defining various types of primitive instances, the system registers these instances into a pre-defined primitive pool. This pool is a statically allocated array of structures or objects at compile time. Each element corresponds to a slot, which can store a pointer to a primitive instance or the instance itself. During registration, the system iterates through the primitive instances of each type. For each instance, it searches for an available slot in the pool. An available slot is determined by whether it is currently unoccupied or if the primitive instance stored there is inactive. Once a slot is found, the system stores the pointer to the primitive instance and sets its status to registered or available. The system can also create a type index table for different slots based on the primitive instance's type identifier, allowing for quick matching of the corresponding primitive instance based on the type of process step. After registration, the pre-defined primitive pool becomes available, providing corresponding primitive instances based on step matching conditions during process execution.

[0083] For ease of understanding, the following explanation uses examples, but does not impose specific limitations on this embodiment. For instance, a charging pile system defines a login request primitive instance (request primitive), a remote stop primitive instance (callback primitive), a real-time data reporting primitive instance (notification primitive), and a rate update push primitive instance (push primitive). The system performs a registration operation during the initialization phase. The preset primitive pool is a static array with 8 slots, each slot large enough to store a pointer to a primitive instance. The system sequentially stores the pointers to the above four primitive instances into slots 0 to 3 of the preset primitive pool and sets the flag of the corresponding slot to registered. When a subsequent login process needs to retrieve the login request primitive, the system searches the preset primitive pool based on the type identifier of the process step, retrieves the pointer to the login request primitive instance from slot 0, and returns it to the caller.

[0084] It should be understood that by centrally registering different types of primitive instances in the primitive pool, the communication process is decoupled from the specific primitive implementation. This not only improves the system's scalability and maintenance efficiency, but also ensures that resource-constrained embedded systems can manage various communication primitives in a predictable and zero-dynamic memory allocation manner, thereby enhancing the stability and reliability of long-term operation.

[0085] This embodiment discloses the definition of multiple types of primitive instances, including request primitives, callback primitives, notification primitives, and push primitives, where different types of primitive instances correspond to different communication modes. These primitive instances of various types are registered in a preset primitive pool, which is used to provide primitive instances during process execution. Because this embodiment defines multiple types of primitive instances and registers them in a preset primitive pool, compared to existing technologies, this embodiment not only reduces code redundancy but also improves system scalability and maintenance efficiency.

[0086] refer to Figure 4 , Figure 4 This is a flowchart illustrating the third embodiment of the communication flow control method of the present invention.

[0087] Based on the above embodiments, in this embodiment, after step S40, steps S50 to S70 are further included: Step S50: Determine whether the target step is a valid step in the step sequence.

[0088] Step S60: If the target step is a valid step, then return to the step of obtaining the target primitive instance that matches the current process step from the preset primitive pool and activating the target primitive instance.

[0089] Step S70: If the target step is an invalid step, then the communication process to be executed is terminated, and the pre-configured completion callback function in the communication process to be executed is called.

[0090] It should be explained that the above-mentioned valid steps can refer to process steps that exist in the step sequence and can be executed normally. A step is considered a valid step if it meets the following conditions: the index value corresponding to the target step is less than the length of the step sequence, and the step definition stored at that index position is not empty.

[0091] Furthermore, the aforementioned invalid step can refer to a process step that is absent or cannot be executed normally in the step sequence. A target step is determined to be invalid if: the index value corresponding to the target step is greater than or equal to the length of the step sequence, or the step stored at that index position is defined as a null pointer or an invalid identifier.

[0092] It should be noted that ending a pending communication process can mean that the system terminates the execution of the current communication process, stops traversing the step sequence and scheduling primitive instances, releases the control block resources occupied by the process, and sets the process state to the end state.

[0093] In its implementation, after updating the current process step to the target step, the system first determines whether the target step is a valid step in the step sequence. During this determination, the system obtains the index value corresponding to the target step and the total length of the step sequence. The system compares the target step index value with the step sequence length. If the target step index value is less than the step sequence length, the system indicates that the target step exists in the step sequence and further checks whether the step definition stored at that index position is a valid definition, such as whether the step primitive type identifier is a valid value. If both conditions are met, the system determines that the target step is a valid step. Next, if the target step is a valid step, the system indicates that the current communication process has not ended and subsequent steps need to be executed. The system returns to the step of retrieving a target primitive instance from the preset primitive pool that matches the current process step and activating the target primitive instance. The system uses the updated current process step as the new current process step and re-enters the main loop of process execution. Conversely, if the target step index value is greater than or equal to the step sequence length, or the step definition is invalid, the system determines that the target step is an invalid step. At this point, the system indicates that the current communication process has completed all valid steps and needs to terminate the process. The system performs operations to terminate the pending communication process, including setting the process status to complete, clearing the current step index, and stopping process scheduling. Subsequently, the system calls the pre-configured completion callback function in the pending communication process, passing in the step execution result and condition flag, so that the upper-layer business logic can perform cleanup work after the process is completed.

[0094] For ease of understanding, the following explanation uses examples, but does not impose specific limitations on this embodiment. For instance, the charging pile login process consists of three steps, indexed 0, 1, and 2, corresponding to login authentication, rate verification, and rate update. After completing the rate update step, the system determines the target step according to the conditional transition rules. In the conditional transition rules, the target step identifier corresponding to a successful rate update step is 3. The system obtains the target step index 3 and compares it with the step sequence length 3. Since the target step index 3 is greater than or equal to the step sequence length 3, the system determines the target step is invalid. Therefore, the system ends the login process, sets the process status to complete, and calls the pre-configured completion callback function `on_flow_complete` to notify the upper-layer business logic that the login process has been fully executed. If the conditional transition rules after the rate update step indicate that the target step is 2 (i.e., the rate update is repeated), the system determines index 2 as a valid step, and then returns to the step of obtaining and activating the rate update primitive instance, re-executing the rate update operation.

[0095] This embodiment discloses a method for determining whether the target step is a valid step in the step sequence. If the target step is valid, the method returns to the step of obtaining a target primitive instance matching the current process step from a preset primitive pool and activating the target primitive instance. If the target step is invalid, the method terminates the communication process to be executed and calls the pre-configured completion callback function in the communication process to be executed. Because this embodiment, after updating the current process step to the target step, further determines whether the target step is a valid step in the step sequence, and actively terminates the process and calls the pre-configured completion callback function when it is determined to be invalid, compared to the prior art, this embodiment introduces a clear boundary check and automatic termination mechanism, effectively avoiding process deadlocks or system freezes caused by incorrect transfer rule configuration, step index out of bounds, or abnormal jumps, thereby improving the robustness and predictability of the communication process execution.

[0096] Furthermore, embodiments of the present invention also propose a storage medium storing a communication flow control program, wherein when the communication flow control program is executed by a processor, it implements the steps of the communication flow control method described above.

[0097] Reference Figure 5 , Figure 5 This is a structural block diagram of the first embodiment of the communication flow control device of the present invention.

[0098] like Figure 5 As shown, the communication flow control device proposed in this embodiment of the invention includes: an information acquisition module 501, a primitive matching module 502, a feedback receiving module 503, and a step jump module 504.

[0099] The information acquisition module 501 is used to acquire the step sequence and conditional transfer rules corresponding to the communication process to be executed.

[0100] The primitive matching module 502 is used to obtain a target primitive instance that matches the current process step from a preset primitive pool for the current process step, and activate the target primitive instance.

[0101] The feedback receiving module 503 is used to drive the target primitive instance to perform asynchronous communication operations and receive the step execution results and condition identifiers fed back by the target primitive instance.

[0102] The step jump module 504 is used to determine the target step from the step sequence based on the step execution result, the condition identifier and the condition transfer rule, and update the current process step to the target step.

[0103] The feedback receiving module 503 is further configured to call the asynchronous processing interface of the target primitive instance, wherein the asynchronous processing interface saves the current execution breakpoint based on the coroutine control structure; performs communication encoding or communication parsing operations inside the target primitive instance, and suspends the current execution flow through the coroutine control structure while waiting for the preset communication conditions to be met; and resumes the execution of the current execution flow through the coroutine control structure after the preset communication conditions are met, and receives the step execution results and condition identifiers fed back by the target primitive instance.

[0104] The step jump module 504 is further configured to, when the step execution result is a completed state, query multiple transfer records in the conditional transfer rules according to the identifier of the current process step and the condition identifier, each transfer record including the source step identifier, the condition identifier and the target step identifier; obtain the target step identifier that matches the identifier of the current process step and the condition identifier from the conditional transfer rules; determine the process step corresponding to the target step identifier as the target step, and update the current process step to the target step.

[0105] This device embodiment discloses a method for acquiring the step sequence and conditional transition rules corresponding to a communication process to be executed. For the current process step, a target primitive instance matching the current process step is obtained from a preset primitive pool, and the target primitive instance is activated. The target primitive instance is driven to perform an asynchronous communication operation, and the step execution result and condition identifier fed back by the target primitive instance are received. Based on the step execution result, the condition identifier, and the conditional transition rules, a target step is determined from the step sequence, and the current process step is updated to the target step. Because this device embodiment decouples business logic from communication state through step sequences and conditional transition rules, and encapsulates asynchronous operations using primitive instances, it automatically determines and jumps to the target step based on the fed-back step execution result and condition identifier, combined with the conditional transition rules. Compared to existing technologies, this device embodiment reduces state management complexity and eliminates logic fragmentation, thereby improving the development and maintenance efficiency of embedded communication processes.

[0106] Based on the first embodiment of the communication flow control device of the present invention described above, a second embodiment of the communication flow control device of the present invention is proposed.

[0107] In this embodiment, the primitive matching module 502 is further configured to define multiple types of primitive instances, including request primitives, callback primitives, notification primitives, and push primitives, wherein different types of primitive instances correspond to different communication modes; and register the multiple types of primitive instances to a preset primitive pool, which is used to provide primitive instances during process execution.

[0108] Other embodiments or specific implementations of the communication process control device of the present invention can be referred to the above-described method embodiments, and will not be repeated here.

[0109] This application provides a communication flow control device, which includes: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, and the instructions are executed by the at least one processor to enable the at least one processor to execute the communication flow control method in the first embodiment described above.

[0110] The following is for reference. Figure 6This document illustrates a structural diagram of a communication flow control device suitable for implementing embodiments of this application. The communication flow control device in the embodiments of this application may include, but is not limited to, mobile terminals such as mobile phones, laptops, digital broadcast receivers, PDAs (Personal Digital Assistants), PADs (Portable Application Description), PMPs (Portable Media Players), in-vehicle terminals (e.g., in-vehicle navigation terminals), and fixed terminals such as digital TVs and desktop computers. Figure 6 The communication flow control device shown is merely an example and should not impose any limitations on the functionality and scope of use of the embodiments of this application.

[0111] like Figure 6 As shown, the communication flow control device may include a processing unit 1001 (e.g., a central processing unit, a graphics processing unit, etc.), which can perform various appropriate actions and processes according to a program stored in a read-only memory 1002 or a program loaded from a storage device 1003 into a random access memory 1004. The random access memory 1004 also stores various programs and data required for the operation of the communication flow control device. The processing unit 1001, the read-only memory 1002, and the random access memory 1004 are interconnected via a bus 1005. An input / output interface 1006 is also connected to the bus. Typically, the following systems can be connected to the input / output interface 1006: input devices 1007 including, for example, touchscreens, touchpads, keyboards, mice, image sensors, microphones, accelerometers, gyroscopes, etc.; output devices 1008 including, for example, liquid crystal displays (LCDs), speakers, vibrators, etc.; storage devices 1003 including, for example, magnetic tapes, hard disks, etc.; and communication devices 1009. Communication device 1009 allows the communication flow control device to communicate wirelessly or wiredly with other devices to exchange data. Although the figures show communication flow control devices with various systems, it should be understood that implementation or possession of all the systems shown is not required. More or fewer systems may be implemented alternatively.

[0112] Specifically, according to the embodiments disclosed in this application, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, embodiments disclosed in this application include a computer program product comprising a computer program carried on a computer-readable medium, the computer program containing program code for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via a communication device, or installed from storage device 1003, or installed from read-only memory 1002. When the computer program is executed by processing device 1001, it performs the functions defined in the methods of the embodiments disclosed in this application.

[0113] The communication flow control device provided in this application, employing the communication flow control method in the above embodiments, can solve the technical problem of low development and maintenance efficiency of embedded communication flows due to state explosion and logic fragmentation in existing embedded communication flows. Compared with the prior art, the beneficial effects of the communication flow control device provided in this application are the same as those of the communication flow control method provided in the above embodiments, and other technical features of this communication flow control device are the same as those disclosed in the previous embodiment method, and will not be repeated here.

[0114] It should be understood that the various parts disclosed in this application can be implemented using hardware, software, firmware, or a combination thereof. In the description of the above embodiments, specific features, structures, materials, or characteristics can be combined in any suitable manner in one or more embodiments or examples.

[0115] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

[0116] It should be noted that, in this document, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or system that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or system. Unless otherwise specified, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or system that includes that element.

[0117] The sequence numbers of the above embodiments of the present invention are for descriptive purposes only and do not represent the superiority or inferiority of the embodiments.

[0118] Through the above description of the embodiments, those skilled in the art can clearly understand that the methods of the above embodiments can be implemented by means of software plus necessary general-purpose hardware platforms. Of course, they can also be implemented by hardware, but in many cases the former is a better implementation method. Based on this understanding, the technical solution of the present invention, or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product is stored in a storage medium (such as read-only memory / random access memory, magnetic disk, optical disk) and includes several instructions to cause a terminal device (which may be a mobile phone, computer, server, air conditioner, or network device, etc.) to execute the methods described in the various embodiments of the present invention.

[0119] The above are merely preferred embodiments of the present invention and do not limit the scope of the patent. Any equivalent structural or procedural transformations made based on the description and drawings of the present invention, or direct or indirect applications in other related technical fields, are similarly included within the scope of patent protection of the present invention.

Claims

1. A communication flow control method, characterized in that, The method includes: Obtain the step sequence and conditional transfer rules corresponding to the communication process to be executed; For the current process step, obtain the target primitive instance that matches the current process step from the preset primitive pool, and activate the target primitive instance; Drive the target primitive instance to perform asynchronous communication operations, and receive the step execution results and condition identifiers fed back by the target primitive instance; Based on the execution result of the step, the condition identifier, and the condition transfer rule, the target step is determined from the step sequence, and the current process step is updated to the target step.

2. The communication flow control method as described in claim 1, characterized in that, The step of driving the target primitive instance to perform asynchronous communication operations and receiving the execution result and condition identifier from the target primitive instance includes: Invoke the asynchronous processing interface of the target primitive instance, wherein the asynchronous processing interface saves the current execution breakpoint based on the coroutine control structure; Within the target primitive instance, communication encoding or parsing operations are performed, and while waiting for preset communication conditions to be met, the current execution flow is suspended through the coroutine control structure. After the preset communication conditions are met, the execution of the current execution flow is resumed through the coroutine control structure, and the step execution results and condition identifiers fed back by the target primitive instance are received.

3. The communication flow control method as described in claim 2, characterized in that, The step of receiving the execution result and condition identifier of the target primitive instance includes: When the execution result of the step indicates failure, the pre-configured completion callback function in the communication process to be executed is invoked; In the completion callback function, the reason for failure is determined based on the condition identifier; If the failure is due to a communication timeout, the underlying transmission interface is called to disconnect the current connection and a delayed reconnection task is scheduled.

4. The communication flow control method as described in claim 1, characterized in that, Before the step of obtaining a target primitive instance matching the current process step from a preset primitive pool and activating the target primitive instance, the method further includes: Define multiple types of primitive instances, including request primitives, callback primitives, notification primitives, and push primitives, where different types of primitive instances correspond to different communication modes; The various types of primitive instances are registered to a preset primitive pool, which is used to provide primitive instances during process execution.

5. The communication flow control method as described in claim 1, characterized in that, The step of determining the target step from the step sequence based on the execution result of the step, the condition identifier, and the condition transition rule includes: When the execution result of the step is a completed state, multiple transfer records in the conditional transfer rule are queried according to the identifier of the current process step and the condition identifier. Each transfer record includes the source step identifier, the condition identifier, and the target step identifier. Obtain the identifier of the current process step and the target step identifier that matches the condition identifier from the condition transition rules; The process step corresponding to the target step identifier is identified as the target step, and the current process step is updated to the target step. Accordingly, after the step of determining the process step corresponding to the target step identifier as the target step and updating the current process step to the target step, the method further includes: The process loop counter is incremented, and when the process loop counter exceeds a preset threshold, the communication process to be executed is forcibly terminated.

6. The communication flow control method as described in claim 2, characterized in that, After the step of receiving the execution result and condition identifier of the target primitive instance, the method further includes: When the result of the step execution is a skipped state, extract the number of skipped steps from the step execution result; Add the index of the current process step to the number of skipped steps to obtain the target step index; The process step corresponding to the target step index in the step sequence is determined as the target step.

7. The communication flow control method according to any one of claims 1-6, characterized in that, After the step of determining the target step from the step sequence based on the step execution result, the condition identifier, and the condition transition rule, and updating the current process step to the target step, the method further includes: Determine whether the target step is a valid step in the step sequence; If the target step is a valid step, then return to the step of obtaining the target primitive instance that matches the current process step from the preset primitive pool and activating the target primitive instance; If the target step is invalid, the pending communication process ends and the pre-configured completion callback function in the pending communication process is called.

8. A communication flow control device, characterized in that, The device includes: The information acquisition module is used to acquire the step sequence and conditional transfer rules corresponding to the communication process to be executed; The primitive matching module is used to obtain a target primitive instance that matches the current process step from a preset primitive pool and activate the target primitive instance. The feedback receiving module is used to drive the target primitive instance to perform asynchronous communication operations and receive the step execution results and condition identifiers fed back by the target primitive instance; The step jump module is used to determine the target step from the step sequence based on the step execution result, the condition identifier, and the condition transfer rule, and update the current process step to the target step.

9. A communication process control device, characterized in that, The device includes: a memory, a processor, and a communication flow control program stored in the memory and executable on the processor, the communication flow control program being configured to implement the steps of the communication flow control method as described in any one of claims 1 to 7.

10. A storage medium, characterized in that, The storage medium stores a communication flow control program, which, when executed by a processor, implements the steps of the communication flow control method as described in any one of claims 1 to 7.

Images