An asynchronous task message passing method and device based on an MCP protocol, an equipment and a storage medium

Abstract

The application discloses an asynchronous task message transmission method and device based on an MCP protocol, equipment and a storage medium, is applied to a calling end registered as an MCP endpoint, relates to the technical field of computer networks, and comprises the following steps: a full-duplex communication session is established based on instance information issued by a service registration center and an execution end, and task semantic information is established based on an initial task request by using an MCP protocol layer; a target task request is sent to the execution end through the session, and the execution end generates an event stream by executing a task by using Nacos service according to the target task request. When a network connection is abnormal, the calling end locates a last successfully received event position based on a globally unique event identifier of the event stream, generates a reconnection request, and sends the reconnection request to the execution end, and the execution end returns the event stream in sequence according to the reconnection request. The calling end sends an acknowledgement instruction to the execution end, the execution end generates an event acknowledgement serial number and returns the event acknowledgement serial number, and the calling end determines that task message transmission is completed after receiving the serial number, so that the efficiency of transmitting task messages is improved.

Description

Technical Field

[0001] This invention relates to the field of computer network technology, and in particular to an asynchronous task message passing method, apparatus, device, and storage medium based on the MCP protocol. Background Technology

[0002] Currently, with the continuous increase in business scale and system complexity, monolithic applications can hardly meet the needs of high concurrency and rapid iteration, and distributed architecture is gradually becoming the mainstream. In a distributed system, business is broken down into multiple independently executable tasks, requiring an "orchestrator" responsible for task dependencies and priorities to distribute tasks to different "executors" and continuously obtain execution status and results for subsequent decision-making or real-time feedback to users.

[0003] In this type of cross-process, cross-host collaboration, asynchronous communication is the usual practice:

[0004] 1. REST Polling: The caller submits a task to the executor by calling an interface (such as POST / tasks), and then calls the interface provided by the executor to query the task execution status (such as GET / task / {id} / status) at fixed intervals until the latest progress or execution result of the task is seen. However, the feedback latency is limited by the polling interval, resulting in a large number of empty polls that waste resources.

[0005] 2. Webhook callback: The caller provides a callback address when submitting a task. The executor sends a POST event to this address when generating logs, progress, or completing the task. However, it is necessary to expose and maintain a reachable callback address. It is complex to cross networks and security governance. Retry after callback failure often requires self-developed and operational support.

[0006] 3. Message Queues (Kafka / RabbitMQ): The caller writes task messages to a queue, the executor consumes and executes the task messages, and then writes the progress, logs, or task results back to another queue as events, which are then consumed and displayed by the caller service. However, there is no built-in unified event format or task management rules (such as how to mark task order, how to assign tasks to different task nodes). These logics need to be implemented manually, such as manually adding task numbers and designing task allocation strategies. This increases the development workload, especially in multi-language collaboration scenarios, where compatibility issues between different systems further increase costs.

[0007] 4. SSE / WebSocket: SSE (Server-Sent Events) supports one-way push from the server, while WebSocket is full-duplex, allowing both sides to send and receive in parallel. After establishing a long connection, the executor can continuously transmit progress, logs, or task results with low latency. However, it is essentially a transmission channel, only responsible for transmitting data and not managing tasks. For example, functions such as task order control, anti-duplicate, and breakpoint resumption need to be developed separately; otherwise, data loss or out-of-order delivery is likely to occur when the network fluctuates.

[0008] In other words, while current mainstream asynchronous communication solutions can achieve task distribution and event pushing, their task state management and error recovery mechanisms are not perfect, which can easily lead to problems such as task delays, inconsistent states, and complex inter-system interfaces. In addition, differences in data formats between different systems and languages ​​will increase additional adaptation costs.

[0009] As can be seen from the above, how to improve the efficiency of asynchronous task message passing in the process of asynchronous task message passing based on the MCP protocol is an urgent problem to be solved. Summary of the Invention

[0010] In view of this, the purpose of this invention is to provide a method, apparatus, device, and storage medium for asynchronous task message passing based on the MCP protocol, which can improve the efficiency of asynchronous task message passing in the process of asynchronous task message passing based on the MCP protocol. The specific solution is as follows:

[0011] Firstly, this application provides an asynchronous task message passing method based on the MCP protocol, applied to a calling end registered as an MCP endpoint, including:

[0012] A full-duplex communication session is established between the service registry and the execution end based on the instance information issued by the service registry. Then, the protocol layer corresponding to the MCP protocol is used and task semantic information is established based on the initial task request.

[0013] The execution terminal sends a target task request, including the task semantic information, to the execution terminal via the full-duplex communication session. The execution terminal then uses the Nacos service to determine the task node based on the target task request, and then executes the corresponding task based on the task node and generates an event stream. The execution terminal has been registered as an MCP endpoint.

[0014] The system determines whether the network connection is abnormal. If abnormal, it determines the location of the last successfully received event based on the globally unique event identifier corresponding to the event stream, and generates a reconnection request based on the event location and sends it to the execution end. The execution end then uses the reconnection request to sequentially transmit the corresponding event stream back to the calling end through the full-duplex communication session. The event stream includes a globally unique event identifier, task acceptance status, execution progress, process log, and task execution result.

[0015] Based on the event stream and the preset confirmation strategy, a confirmation instruction is sent to the execution end, so that the execution end generates an event confirmation sequence number based on the confirmation instruction and sends the event confirmation sequence number to the calling end. Then, after the calling end receives the event confirmation sequence number, it determines that the task message transmission is complete.

[0016] Optionally, the establishment of a full-duplex communication session between the execution end and the instance information issued by the service registry includes:

[0017] The service registry is queried to obtain a list of instances corresponding to each execution end, and the target execution end is determined based on the health status and load indicators of the instances in the instance list, so as to establish a persistent full-duplex communication channel with the target execution end; the full-duplex communication channel supports bidirectional streaming message transmission between the calling end and the target execution end;

[0018] Determine whether the instance list corresponding to the target execution end has undergone scaling up or down operations or a failure. If the instance list corresponding to the target execution end has undergone scaling up or down operations or a failure, call the Nacos service to perform a route update operation, obtain the update result, switch to the current instance list based on the update result, and set the calling end corresponding to the current instance list as the new target execution end.

[0019] Optionally, the step of calling the Nacos service to perform a route update operation and obtaining the update result includes:

[0020] When the execution terminal starts, it sends a registration request to the service registry so that the service registry can register instance metadata based on the registration request; the instance metadata includes network address, service capabilities and instance health status.

[0021] At preset time intervals, the system retrieves the instance list corresponding to each execution terminal from the service registry, and selects the corresponding instance list based on a preset routing strategy to establish a connection with the instance list; the instance list includes the corresponding instance metadata.

[0022] The service registry is invoked to monitor the availability of the instance list in real time. When a failure or offline event is detected in the instance list, the Nacos service is invoked to notify the calling client to update the routing information and obtain the update result. This allows the calling client to perform failover based on the health status of the instances and the update result. The service registry also supports configuration management, allowing the runtime to adjust routing strategies and flow control parameters based on optimization goals that enhance system resilience and maintainability.

[0023] Optionally, the step of utilizing the protocol layer corresponding to the MCP protocol and establishing task semantic information based on the initial task request includes:

[0024] The initial task request is configured with a globally unique event identifier using the protocol layer corresponding to the MCP protocol to obtain the corresponding globally unique event identifier. Based on the globally unique event identifier and the initial task request, the task type code, execution priority, idempotent key, timeout threshold and resume token corresponding to the initial task request are determined.

[0025] Based on the globally unique event identifier, the task type code, the execution priority, the idempotent key, the timeout threshold, and the resume token, standardized semantic fields are determined, and task semantic information corresponding to the initial task request is determined based on the semantic fields.

[0026] Optionally, sending a target task request including the task semantic information to the execution end through the full-duplex communication session, so that the execution end can use the Nacos service and determine the task node based on the target task request, and then execute the corresponding task based on the task node and generate an event stream, includes:

[0027] Based on the task semantic information and the initial task request, a target task request is determined, and the target task request is sent to the execution end through the full-duplex communication session. The execution end then uses the Nacos service and the target task request to determine the corresponding task node, and uses the task node to parse the task semantic information in the target task request to obtain the parsing result.

[0028] The execution end is invoked to perform processing logic matching on the target task request based on the task type encoding in the parsing result, and obtains a logic matching result. Execution resources corresponding to the logic matching result and the execution priority are then scheduled. The task is then executed based on the execution resources, the idempotent key, and the timeout threshold to obtain the corresponding task execution result. The idempotent key is used to prevent the task node from performing duplicate task processing operations, and the timeout threshold is used to terminate the task node when the task execution time exceeds the timeout threshold.

[0029] The execution end is called to determine whether the task execution result indicates that the task was successfully executed. If the task execution result indicates that the task was not successfully executed, the retry strategy is used to re-execute the task, and the continuation token in the parsed result is associated with the task progress to obtain the association result. Then, the event flow is determined based on the task execution result and the association result.

[0030] Optionally, the step of determining whether the network connection is abnormal, and if abnormal, determining the location of the last successfully received event based on the globally unique event identifier corresponding to the event stream, and generating a reconnection request based on the event location and sending it to the execution end, so that the execution end can sequentially transmit the corresponding event stream back to the calling end through the full-duplex communication session based on the reconnection request, includes:

[0031] Determine if the network connection is abnormal. If it is abnormal, the execution end encapsulates the globally unique event identifier corresponding to each task event into a resume token and transmits the resume token to the calling end.

[0032] The system utilizes a breakpoint resumption mechanism and generates the corresponding last successfully received event position based on the resumption token. Then, it determines the corresponding last confirmed event sequence number based on the event position. When the network connection is restored after an interruption, it sends a reconnection request including the last confirmed event sequence number to the execution end. This allows the execution end to replay the undelivered event stream to the calling end from the event position corresponding to the resumption token through the full-duplex communication session and based on the last confirmed event sequence number, and to continue pushing new event streams to the calling end.

[0033] The breakpoint resume mechanism allows the calling end to restore the task state in the new instance based on the resume token after discovering the new instance through the service registry.

[0034] Optionally, the step of sending a confirmation instruction to the execution end based on the event stream and a preset confirmation strategy, so that the execution end generates an event confirmation sequence number based on the confirmation instruction and sends the event confirmation sequence number to the calling end, and then the calling end determines that the task message transmission is complete after receiving the event confirmation sequence number, includes:

[0035] The system receives the event streams returned by the execution end, records the corresponding event sequence numbers according to the order in which the event streams arrive, and caches unacknowledged event streams. Then, it sends the corresponding acknowledgment instructions to the execution end using a preset strategy. The acknowledgment instructions include the sequence number of the last successfully received acknowledgment event. The preset strategy includes periodically sending the corresponding acknowledgment instructions to the execution end and sending the corresponding acknowledgment instructions to the execution end based on a preset event quantity threshold.

[0036] The system detects whether the event stream is abnormal. If the event stream is abnormal, a negative acknowledgment instruction is sent to the execution end so that the execution end can generate a corresponding event stream to be retransmitted based on the negative acknowledgment instruction.

[0037] If no abnormality occurs in the event stream, the confirmation instruction is sent to the execution end, so that the execution end generates an event confirmation sequence number based on the confirmation instruction and sends the event confirmation sequence number to the calling end, so that the calling end can determine that the task message corresponding to the target task request has been successfully delivered after receiving the event confirmation sequence number.

[0038] Secondly, this application provides an asynchronous task message passing device based on the MCP protocol, applied to a calling end registered as an MCP endpoint, including:

[0039] The task semantic information establishment module is used to establish a full-duplex communication session between the execution end and the service registry based on the instance information issued by the service registry. Then, it uses the protocol layer corresponding to the MCP protocol and establishes task semantic information based on the initial task request.

[0040] The event stream generation module is used to send a target task request including the task semantic information to the execution end through the full-duplex communication session, so that the execution end can use the Nacos service and determine the task node based on the target task request, and then execute the corresponding task based on the task node and generate an event stream; the execution end has been registered as an MCP endpoint;

[0041] The network connection judgment module is used to determine whether the network connection is abnormal. If abnormal, it determines the location of the last successfully received event based on the globally unique event identifier corresponding to the event stream, and generates a reconnection request based on the event location and sends it to the execution end, so that the execution end can send the corresponding event stream back to the calling end in sequence through the full-duplex communication session based on the reconnection request. The event stream includes a globally unique event identifier, task acceptance status, execution progress, process log, and task execution result.

[0042] The confirmation instruction issuing module is used to send a confirmation instruction to the execution end based on the event stream and a preset confirmation strategy, so that the execution end generates an event confirmation sequence number based on the confirmation instruction and sends the event confirmation sequence number to the calling end. Then, the calling end determines that the task message transmission is complete after receiving the event confirmation sequence number.

[0043] Thirdly, this application provides an electronic device, comprising:

[0044] Memory, used to store computer programs;

[0045] A processor is used to execute the computer program to implement the aforementioned asynchronous task message passing method based on the MCP protocol.

[0046] Fourthly, this application provides a computer-readable storage medium for storing a computer program, wherein the computer program, when executed by a processor, implements the aforementioned asynchronous task message passing method based on the MCP protocol.

[0047] As can be seen from the above, before performing asynchronous task message transmission based on the MCP protocol, this application needs to establish a full-duplex communication session with the execution end based on the instance information issued by the service registry. Then, it uses the protocol layer corresponding to the MCP protocol and establishes task semantic information based on the initial task request. A target task request including task semantic information is sent to the execution end through the full-duplex communication session, so that the execution end can use the Nacos service and determine the task node based on the target task request. Then, it executes the corresponding task based on the task node and generates an event stream. The execution end has been registered as an MCP endpoint. It then checks whether the network connection is abnormal; if abnormal, then... The location of the last successfully received event is determined based on the globally unique event identifier corresponding to the event stream. A reconnection request is generated based on the event location and sent to the execution end. The execution end then uses the reconnection request to send the corresponding event stream back to the calling end in sequence through a full-duplex communication session. The event stream includes the globally unique event identifier, task acceptance status, execution progress, process log, and task execution result. An acknowledgment instruction is sent to the execution end based on the event stream and a preset acknowledgment strategy. The execution end generates an event acknowledgment number based on the acknowledgment instruction and sends the event acknowledgment number to the calling end. The calling end then determines that the task message transmission is complete upon receiving the event acknowledgment number.

[0048] Therefore, this application first needs to establish a full-duplex communication session with the execution end based on the instance information issued by the service registry. Then, it uses the protocol layer corresponding to the MCP protocol and establishes task semantic information based on the initial task request. Second, it sends a target task request including task semantic information to the execution end through the full-duplex communication session, so that the execution end can use the Nacos service and determine the task node based on the target task request. Then, it executes the corresponding task based on the task node and generates an event stream. The execution end has been registered as an MCP endpoint. Then, it determines whether the network connection is abnormal. If it is abnormal, it determines the location of the last successfully received event based on the globally unique event identifier corresponding to the event stream, and generates a reconnection request based on the event location and sends it to the execution end, so that the execution end can send the corresponding event stream back to the calling end in order through the full-duplex communication session based on the reconnection request. Finally, it sends a confirmation instruction to the execution end based on the event stream and the preset confirmation strategy, so that the execution end can generate an event confirmation sequence number based on the confirmation instruction and send the event confirmation sequence number to the calling end. Then, the calling end determines that the task message transmission is complete after receiving the event confirmation sequence number. This improves the efficiency of asynchronous task message passing based on the MCP protocol, thereby enhancing the user experience. Attached Figure Description

[0049] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on the provided drawings without creative effort.

[0050] Figure 1 This application discloses a flowchart of an asynchronous task message passing method based on the MCP protocol.

[0051] Figure 2 This is a schematic diagram of a specific hybrid architecture process disclosed in this application;

[0052] Figure 3 This is a schematic diagram illustrating the relationship between specific modules disclosed in this application;

[0053] Figure 4 This is a schematic diagram of a specific Nacos service registration and discovery module disclosed in this application;

[0054] Figure 5 This is a schematic diagram illustrating a specific resumable download mechanism using ResumeToken disclosed in this application.

[0055] Figure 6This is a flowchart illustrating a specific confirmation mechanism disclosed in this application.

[0056] Figure 7 This is a schematic diagram of an asynchronous task message passing device based on the MCP protocol disclosed in this application;

[0057] Figure 8 This is a structural diagram of an electronic device disclosed in this application. Detailed Implementation

[0058] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0059] Currently, with the increasing scale of business and system complexity, monolithic applications struggle to meet the demands of high concurrency and rapid iteration, making distributed architecture increasingly mainstream. In this cross-process, cross-host collaboration, asynchronous communication is a common practice: 1. REST polling: Feedback latency is limited by the polling interval, resulting in numerous wasted resources from empty polls; 2. Webhook callbacks: Require the public and maintenance of reachable callback addresses, leading to complex cross-network and security governance, and retrying after callback failures often requires in-house development and maintenance support; 3. Message queues: Require significant development effort, especially in multi-language collaboration scenarios, where compatibility issues between different systems further increase costs; 4. SSE / WebSocket: Essentially a transmission channel, responsible only for data transmission and not task management. Therefore, this application provides an asynchronous task message passing method based on the MCP protocol, which can improve the efficiency of asynchronous task message passing in the MCP-based asynchronous task message passing process.

[0060] See Figure 1 As shown, this embodiment of the invention discloses an asynchronous task message passing method based on the MCP protocol, applied to a calling end registered as an MCP endpoint, including:

[0061] Step S11: Establish a full-duplex communication session between the execution end and the service registry based on the instance information issued by the service registry. Then, use the protocol layer corresponding to the MCP protocol and establish task semantic information based on the initial task request.

[0062] In this embodiment, to meet the requirements of distributed task orchestration for real-time feedback and asynchronous processing, this application adopts a three-layer hybrid architecture of "synchronous submission via REST interface + asynchronous decoupling via message queue + real-time push via WebSocket". The core process is as follows: First, in the task submission layer, the caller submits a task request via REST API. Second, in the asynchronous processing layer, the task is persisted to the task queue of the message queue so that execution nodes can asynchronously consume and process the task, generating execution events (acceptance confirmation, progress update, log stream, result data). Then, in the real-time push layer, the execution events are written to the event topic of the message queue, and the service consumption events are pushed actively to the subscribing clients via a WebSocket long connection. The flowchart of the above hybrid architecture is shown below. Figure 2 As shown.

[0063] In this embodiment, the task processing flow is as follows: First, task submission: The client submits task parameters through the REST interface, and the system generates a unique task ID and records the initial state. Second, task queuing: The task is placed in the task queue of the message queue. Then, task acceptance: The execution end retrieves the task from the queue, performs verification and resource allocation, generates a "task acceptance" event, and places it in the event queue. Subsequently, the execution process begins: The execution end generates events such as "progress update, execution log, and intermediate results" in real time and writes them to the event queue. Furthermore, real-time push: The push service retrieves messages from the event queue and pushes them to clients subscribed to the task in real time via WebSocket. Finally, result storage: The final result is stored in the database for querying and auditing, and the final task state is updated. It is worth mentioning that this embodiment supports exception handling: When push fails or execution errors occur, automatic recovery (retry or alarm) is performed using the message queue's retry mechanism and task state management; connection management: The push service maintains the subscription relationship between the task and the client, automatically cleans up when the connection is broken, and supports resending messages after reconnection.

[0064] In this embodiment, key fields are fixed through the MCP (Model Context Protocol) protocol layer, and Nacos is integrated to achieve service registration and discovery, resolving issues such as inconsistent task semantics and complex recovery. In this embodiment, both the calling end and the executing end are registered as MCP endpoints to achieve automatic service discovery. Subsequently, the calling end (MCP Client) initiates tasks and receives events, while the executing end (MCP Server) executes tasks and returns events (progress, logs, structure). The MCP session (full-duplex channel) connects the calling end and the executing end, supporting real-time bidirectional communication. Task semantic fields are fixed through the protocol layer. It is worth noting that the relationship diagram between the modules is as follows: Figure 3As shown, and the schematic diagram of the Nacos service registration and discovery module is as follows. Figure 4 As shown: The Nacos (Naming and Configuration Service) service registration and discovery module is used to achieve elastic scheduling by dynamically managing MCP endpoints (calling end / executing end): the execution end automatically registers instance information when it starts up, and the calling end queries and selects the best available nodes through Nacos.

[0065] Specifically, establishing a full-duplex communication session between the caller and the execution end based on instance information issued by the service registry can include: obtaining an instance list corresponding to each execution end by querying the service registry, and determining the target execution end based on the health status and load indicators of the instances in the instance list, so as to establish a persistent full-duplex communication channel with the target execution end; the full-duplex communication channel supports bidirectional streaming message transmission between the caller and the target execution end; determining whether the instance list corresponding to the target execution end has undergone scaling up or down operations or failures; if the instance list corresponding to the target execution end has undergone scaling up or down operations or failures, calling the Nacos service to perform a route update operation, obtaining the update result, switching to the current instance list based on the update result, and setting the caller corresponding to the current instance list as the new target execution end.

[0066] In this embodiment, when an instance is scaled up or down or fails, the Nacos service is used to push route updates in real time to ensure that the calling end can seamlessly switch instances and maintain breakpoint resume. In this way, it replaces static configuration, reduces connection maintenance costs, and is the core support for distributed task elastic orchestration and reliable cross-instance communication.

[0067] Specifically, calling the Nacos service to perform route update operations and obtain update results can include: when the execution end starts, sending a registration request to the service registry so that the service registry can register instance metadata based on the registration request; instance metadata includes network address, service capabilities, and instance health status; retrieving the instance list corresponding to each execution end from the service registry at preset time intervals, and selecting the corresponding instance list based on a preset routing strategy to establish a connection with the instance list; the instance list includes the corresponding instance metadata; calling the service registry to monitor the availability of the instance list in real time, and when a failure or offline of the instance list is detected, calling the Nacos service to notify the calling end to update the routing information and obtain update results so that the calling end can perform failover based on the instance health status and update results; the service registry also supports configuration management, allowing the runtime to adjust routing strategies and flow control parameters based on optimization goals to enhance system elasticity and maintainability.

[0068] In this embodiment, the core function of the calling client (MCP Client) is to uniformly send and receive tasks and manage their status: when sending a task, the protocol layer uses fixed task semantic information (such as task ID, priority, etc.) to receive progress, logs, and results returned by the execution end in sequence, supporting confirmation mechanisms and flow control; after network disconnection and reconnection, the client continues to receive incomplete information through the ResumeToken (i.e., the resumption token), without having to start from scratch. Specifically, using the protocol layer corresponding to the MCP protocol and establishing task semantic information based on the initial task request can include: configuring a globally unique event identifier for the initial task request using the protocol layer corresponding to the MCP protocol to obtain the corresponding globally unique event identifier, and determining the task type code, execution priority, idempotent key, timeout threshold, and resumption token corresponding to the initial task request based on the globally unique event identifier and the initial task request; determining standardized semantic fields based on the globally unique event identifier, task type code, execution priority, idempotent key, timeout threshold, and resumption token, and determining the task semantic information corresponding to the initial task request based on the semantic fields.

[0069] Step S12: Send a target task request including the task semantic information to the execution end through the full-duplex communication session, so that the execution end can use the Nacos service and determine the task node based on the target task request, and then execute the corresponding task and generate an event stream based on the task node; the execution end has been registered as an MCP endpoint.

[0070] In this embodiment, the execution end (MCP Server) is responsible for receiving asynchronous execution tasks from the calling end and sending back standardized event streams. Its core function is to provide a reliable task processing and status feedback mechanism: receiving task semantic information from the caller through the MCP session, executing tasks and generating acceptance, progress, log, stage, and final result events in sequence; supporting ResumeToken to enable breakpoint resumption, ensuring that the state is not lost after network interruption; and combining idempotency key and sequence mechanism to ensure event deduplication and consistency.

[0071] Specifically, a target task request, including task semantic information, is sent to the execution end via a full-duplex communication session. The execution end then utilizes the Nacos service and determines the task node based on the target task request. Finally, it executes the corresponding task based on the task node and generates an event stream. This process can include: determining the target task request based on the task semantic information and the initial task request, and sending the target task request to the execution end via a full-duplex communication session. The execution end then utilizes the Nacos service and determines the corresponding task node based on the target task request. The task node is used to parse the task semantic information in the target task request to obtain the parsing result. Finally, the execution end performs a processing logic match on the target task request based on the task type encoding in the parsing result. Upon receiving the logical matching result, execution resources corresponding to the logical matching result and execution priority are scheduled. Then, task execution is performed based on the execution resources, idempotent keys, and timeout thresholds to obtain the corresponding task execution results. Among them, idempotent keys are used to prevent task nodes from performing duplicate task processing operations, and timeout thresholds are used to terminate task nodes when the task execution time exceeds the timeout threshold. The calling execution end determines whether the task execution result indicates that the task execution was successful. If the task execution result indicates that the task execution was unsuccessful, the retry strategy is used to re-execute the task, and the continuation token in the parsed result is associated with the task progress to obtain the association result. Then, the event flow is determined based on the task execution result and the association result.

[0072] In this embodiment, the MCP session module acts as a communication bridge between the calling end and the executing end, providing a standardized channel for full-duplex, streaming transmission. Its core function is to solidify task event semantics and achieve reliable interaction: the session embeds key fields such as taskId, sequence, and idempotencyKey to ensure event ordering and deduplication; it supports ACK (Acknowledgment) and NACK (Negative Acknowledgment) confirmation mechanisms to form an end-to-end backpressure closed loop; and it implements breakpoint resumption through ResumeToken and lastAckSeq to ensure connection recovery after network interruption.

[0073] Step S13: Determine if the network connection is abnormal. If abnormal, determine the location of the last successfully received event based on the globally unique event identifier corresponding to the event stream, and generate a reconnection request based on the event location and send it to the execution end, so that the execution end can send the corresponding event stream back to the calling end in sequence through the full-duplex communication session based on the reconnection request. The event stream includes a globally unique event identifier, task acceptance status, execution progress, process log and task execution result.

[0074] In this embodiment, the present application utilizes the MCP protocol to predefine task semantic information to standardize task collaboration in a distributed environment and avoid confusion caused by inconsistent descriptions. The task semantic information includes the following key elements:

[0075] (1) Basic identifier: used to ensure task traceability;

[0076] TaskID: A globally unique task ID (such as UUID) used to distinguish different tasks and is the core association key for all operations.

[0077] TaskType: Task type. The executor can automatically match the processing logic based on the type.

[0078] (2) Behavior control: used to define task execution rules and resource scheduling strategies;

[0079] Priority: Priority is used by the execution end to schedule resources (e.g., high-priority tasks occupy CPU first).

[0080] IdempotencyKey: An idempotency key (such as TaskID + version number) to prevent duplicate execution.

[0081] Timeout: Timeout threshold. The task will automatically terminate or retry if the timeout is exceeded to prevent it from freezing.

[0082] (3) Fault tolerance and recovery: used to support resume download from interruption;

[0083] ResumeToken: Resume token (associated with the latest progress position of the task), so that it does not need to be executed from the beginning after disconnection;

[0084] RetryPolicy: Retry strategy (e.g., "retry 3 times after failure, with a 2-second interval"), the execution end automatically retryes according to the rules, without requiring additional coding from the calling end.

[0085] Specifically, the process involves determining whether the network connection is abnormal. If abnormal, the last successfully received event location is determined based on the globally unique event identifier corresponding to the event stream. A reconnection request is then generated based on the event location and sent to the execution end. This allows the execution end to sequentially transmit the corresponding event stream back to the calling end via a full-duplex communication session based on the reconnection request. This can include: determining whether the network connection is abnormal; if abnormal, the calling execution end encapsulates the globally unique event identifier corresponding to each task event into a resume token and transmits the resume token to the calling end; utilizing the breakpoint resume mechanism and generating the corresponding last successfully received event location based on the resume token; determining the corresponding last confirmed event sequence number based on the event location; and sending a reconnection request including the last confirmed event sequence number to the execution end when the network connection is restored after an interruption. This allows the execution end to replay the undelivered event stream to the calling end from the event location corresponding to the resume token via a full-duplex communication session based on the last confirmed event sequence number, and continue pushing new event streams to the calling end. The breakpoint resume mechanism supports restoring the task state in the new instance based on the resume token after the calling end discovers a new instance through the service registry.

[0086] In this embodiment, the ResumeToken breakpoint resume mechanism is used for breakpoint resume, and the corresponding schematic diagram is shown below. Figure 5 As shown: It's worth noting that ResumeToken is a key mechanism for supporting resuming interrupted connections. The server assigns a globally unique ID to each task event, serving as a cursor for its position in the stream. This ID constitutes the core of ResumeToken. When a client encounters a network interruption and needs to reconnect, it informs the server of the last successfully received event position via the LastEventID header. Based on this, the server replays messages that were not delivered after the disconnection and continues to push new events, thereby ensuring the integrity and sequential consistency of the event stream.

[0087] Step S14: Based on the event stream and the preset confirmation strategy, send a confirmation instruction to the execution end, so that the execution end generates an event confirmation sequence number based on the confirmation instruction and sends the event confirmation sequence number to the calling end. Then, after the calling end receives the event confirmation sequence number, it determines that the task message transmission is complete.

[0088] In this embodiment, the ACK / NACK acknowledgment mechanism is the core means to ensure reliable event transmission in an MCP session, and the flowchart corresponding to the ACK / NACK acknowledgment mechanism is shown below. Figure 6As shown, after the calling end receives the event returned by the executing end, this embodiment of the application needs to send an ACK (acknowledgment of receipt) or NACK (retransmission request) instruction according to the strategy. ACK can be sent in batches (e.g., once every 50 events or every 100ms) to reduce network round-trip overhead; NACK is used to mark abnormal or lost events and trigger selective retransmission. This mechanism combines the sequence number and the idempotencyKey deduplication key to approximate the "exactly once" delivery effect, solving the problems of event loss, duplication, and lack of acknowledgment closure in traditional MQ or WebSocket solutions, and significantly improving the reliability and latency stability of distributed task orchestration.

[0089] Specifically, based on the event stream and a preset confirmation strategy, a confirmation instruction is sent to the execution end. The execution end generates an event confirmation sequence number based on the confirmation instruction and sends it to the calling end. Upon receiving the event confirmation sequence number, the calling end determines that the task message delivery is complete. This process can include: receiving the event stream returned by the execution end, recording the corresponding event sequence numbers according to the arrival order of each event stream, and caching unconfirmed event streams. Then, a corresponding confirmation instruction is sent to the execution end using the preset strategy. The confirmation instruction includes the last successfully received confirmation event sequence number. The preset strategy includes periodically sending the corresponding confirmation instruction to the execution end and sending the corresponding confirmation instruction to the execution end based on a preset event quantity threshold. The process also involves detecting whether the event stream is abnormal. If an event stream is abnormal, a negative confirmation instruction is sent to the execution end, enabling the execution end to generate a corresponding event stream to be retransmitted based on the negative confirmation instruction. If the event stream is not abnormal, a confirmation instruction is sent to the execution end, enabling the execution end to generate an event confirmation sequence number based on the confirmation instruction and send it to the calling end. Upon receiving the event confirmation sequence number, the calling end determines that the task message corresponding to the target task request has been successfully delivered.

[0090] As can be seen from the above, the embodiments of this application first need to establish a full-duplex communication session between the execution end and the service registry based on the instance information issued by the service registry. Then, the protocol layer corresponding to the MCP protocol is used to establish task semantic information based on the initial task request. Next, a target task request including task semantic information is sent to the execution end through the full-duplex communication session so that the execution end can use the Nacos service and determine the task node based on the target task request. Then, the execution end executes the corresponding task and generates an event stream based on the task node. The execution end has been registered as an MCP endpoint. Then, it is determined whether the network connection is abnormal. If it is abnormal, the location of the last successfully received event is determined based on the globally unique event identifier corresponding to the event stream. A reconnection request is generated based on the event location and sent to the execution end so that the execution end can send the corresponding event stream back to the calling end in order through the full-duplex communication session based on the reconnection request. Finally, a confirmation instruction is sent to the execution end based on the event stream and the preset confirmation strategy so that the execution end can generate an event confirmation sequence number based on the confirmation instruction and send the event confirmation sequence number to the calling end. Then, the calling end determines that the task message transmission is complete after receiving the event confirmation sequence number. This improves the efficiency of asynchronous task message passing based on the MCP protocol, thereby enhancing the user experience.

[0091] Accordingly, see Figure 7 As shown, this application also provides an asynchronous task message passing device based on the MCP protocol, applied to a calling end registered as an MCP endpoint, including:

[0092] The task semantic information establishment module 11 is used to establish a full-duplex communication session between the execution end and the service registry based on the instance information issued by the service registry, and then use the protocol layer corresponding to the MCP protocol to establish task semantic information based on the initial task request.

[0093] The event stream generation module 12 is used to send a target task request including the task semantic information to the execution end through the full-duplex communication session, so that the execution end can use the Nacos service and determine the task node based on the target task request, and then execute the corresponding task based on the task node and generate an event stream; the execution end has been registered as an MCP endpoint;

[0094] The network connection judgment module 13 is used to determine whether the network connection is abnormal. If abnormal, it determines the location of the last successfully received event based on the globally unique event identifier corresponding to the event stream, and generates a reconnection request based on the event location and sends it to the execution end, so that the execution end can send the corresponding event stream back to the calling end in sequence through the full-duplex communication session based on the reconnection request. The event stream includes a globally unique event identifier, task acceptance status, execution progress, process log, and task execution result.

[0095] The confirmation instruction issuing module 14 is used to send a confirmation instruction to the execution end based on the event stream and the preset confirmation strategy, so that the execution end generates an event confirmation sequence number based on the confirmation instruction and sends the event confirmation sequence number to the calling end. Then, the calling end determines that the task message transmission is completed after receiving the event confirmation sequence number.

[0096] In some specific embodiments, the task semantic information establishment module 11 may specifically include:

[0097] The communication channel establishment unit is used to obtain the instance list corresponding to each execution end by querying the service registry center, and determine the target execution end based on the health status and load indicators of the instances in the instance list, so as to establish a persistent full-duplex communication channel with the target execution end; the full-duplex communication channel supports bidirectional streaming message transmission between the calling end and the target execution end;

[0098] The update result determination unit is used to determine whether the instance list corresponding to the target execution end has undergone scaling up or down operations or a failure. If the instance list corresponding to the target execution end has undergone scaling up or down operations or a failure, the Nacos service is called to perform a route update operation to obtain an update result. Based on the update result, the current instance list is switched to, and the calling end corresponding to the current instance list is set as the new target execution end.

[0099] In some specific embodiments, the task semantic information establishment module 11 may specifically include:

[0100] The instance metadata registration unit is used to send a registration request to the service registry center when the execution terminal starts, so that the service registry center can register instance metadata based on the registration request; the instance metadata includes network address, service capabilities, and instance health status;

[0101] The instance list determination unit is used to pull the instance list corresponding to each execution terminal from the service registry at preset time intervals, and select the corresponding instance list based on a preset routing strategy to establish a connection with the instance list; the instance list includes the corresponding instance metadata;

[0102] The routing information update unit is used to call the service registry to monitor the availability of the instance list in real time. When a failure or offline event is detected in the instance list, the unit calls the Nacos service to notify the caller to update the routing information and obtain the update result. This allows the caller to switch over based on the instance health status and the update result. The service registry also supports configuration management, allowing the runtime to adjust routing strategies and flow control parameters based on optimization goals that enhance system resilience and maintainability.

[0103] In some specific embodiments, the task semantic information establishment module 11 may specifically include:

[0104] The event identifier determination unit is used to configure a globally unique event identifier for the initial task request using the protocol layer corresponding to the MCP protocol, obtain the corresponding globally unique event identifier, and determine the task type code, execution priority, idempotent key, timeout threshold and resume token corresponding to the initial task request based on the globally unique event identifier and the initial task request.

[0105] The task semantic information establishment subunit is used to determine standardized semantic fields based on the globally unique event identifier, the task type encoding, the execution priority, the idempotent key, the timeout threshold and the resume token, and to determine the task semantic information corresponding to the initial task request based on the semantic fields.

[0106] In some specific embodiments, the event stream generation module 12 may specifically include:

[0107] The parsing result determination unit is used to determine the target task request based on the task semantic information and the initial task request, and send the target task request to the execution end through the full-duplex communication session, so that the execution end can use the Nacos service and determine the corresponding task node based on the target task request, and use the task node to parse the task semantic information in the target task request to obtain the parsing result;

[0108] The logical matching result determination unit is used to call the execution end to perform logical matching on the target task request based on the task type encoding in the parsing result, obtain a logical matching result, schedule the corresponding execution resources based on the logical matching result and the execution priority, and then perform task execution based on the execution resources, the idempotent key and the timeout threshold to obtain the corresponding task execution result; wherein, the idempotent key is used to prevent the task node from performing duplicate task processing operations, and the timeout threshold is used to terminate the task node when the task execution time exceeds the timeout threshold.

[0109] The event stream generation subunit is used to call the execution end to determine whether the task execution result indicates that the task was executed successfully. If the task execution result indicates that the task was not executed successfully, the retry strategy is used to re-execute the task, and the continuation token in the parsing result is associated with the task progress to obtain the association result. Then, the event stream is determined based on the task execution result and the association result.

[0110] In some specific embodiments, the network connection determination module 13 may specifically include:

[0111] The resume token determination unit is used to determine whether the network connection is abnormal. If it is abnormal, the calling execution end encapsulates the globally unique event identifier corresponding to each task event into a resume token and transmits the resume token to the calling end.

[0112] The reconnection request sending unit is used to utilize the breakpoint resumption mechanism and generate the corresponding last successfully received event position based on the resumption token. Then, based on the event position, it determines the corresponding last confirmed event sequence number. When the network connection is restored after an interruption, it sends a reconnection request including the last confirmed event sequence number to the execution end. This allows the execution end to replay the undelivered event stream to the calling end from the event position corresponding to the resumption token through the full-duplex communication session and based on the last confirmed event sequence number, and to continue pushing new event streams to the calling end. The breakpoint resumption mechanism supports the calling end restoring the task state in the new instance based on the resumption token after discovering a new instance through the service registry.

[0113] In some specific embodiments, the confirmation instruction issuing module 14 may specifically include:

[0114] The confirmation instruction issuing subunit is used to receive the event stream returned by the execution end, record the corresponding event sequence number according to the arrival order of each event stream, and cache unconfirmed event streams. Then, it sends the corresponding confirmation instruction to the execution end using a preset strategy. The confirmation instruction includes the sequence number of the last successfully received confirmed event. The preset strategy includes periodically sending the corresponding confirmation instruction to the execution end and sending the corresponding confirmation instruction to the execution end based on a preset event quantity threshold.

[0115] The event stream to be retransmitted determination unit is used to detect whether the event stream is abnormal. If the event stream is abnormal, it sends a negative confirmation instruction to the execution end so that the execution end can generate a corresponding event stream to be retransmitted based on the negative confirmation instruction.

[0116] The confirmation instruction issuing subunit is used to send the confirmation instruction to the execution end if no abnormality occurs in the event stream, so that the execution end can generate an event confirmation sequence number based on the confirmation instruction and send the event confirmation sequence number to the calling end, so that the calling end can determine that the task message corresponding to the target task request has been successfully delivered after receiving the event confirmation sequence number.

[0117] Furthermore, embodiments of this application also disclose an electronic device, Figure 8This is a structural diagram of an electronic device 20 according to an exemplary embodiment. The content of the diagram should not be construed as limiting the scope of this application. The electronic device 20 may specifically include: at least one processor 21, at least one memory 22, a power supply 23, a communication interface 24, an input / output interface 25, and a communication bus 26. The memory 22 stores a computer program, which is loaded and executed by the processor 21 to implement the relevant steps in the asynchronous task message passing method based on the MCP protocol disclosed in any of the foregoing embodiments. Furthermore, the electronic device 20 in this embodiment may specifically be an electronic computer.

[0118] In this embodiment, the power supply 23 is used to provide operating voltage for each hardware device on the electronic device 20; the communication interface 24 can create a data transmission channel between the electronic device 20 and external devices, and the communication protocol it follows can be any communication protocol applicable to the technical solution of this application, and is not specifically limited here; the input / output interface 25 is used to acquire external input data or output data to the outside world, and its specific interface type can be selected according to specific application needs, and is not specifically limited here.

[0119] In addition, the memory 22, as a carrier for resource storage, can be a read-only memory, random access memory, disk or optical disk, etc. The resources stored thereon can include operating system 221, computer program 222, etc., and the storage method can be temporary storage or permanent storage.

[0120] The operating system 221 is used to manage and control the various hardware devices on the electronic device 20 and the computer program 222, which may be Windows Server, Netware, Unix, Linux, etc. In addition to including a computer program capable of performing the asynchronous task message passing method based on the MCP protocol executed by the electronic device 20 as disclosed in any of the foregoing embodiments, the computer program 222 may further include computer programs capable of performing other specific tasks.

[0121] Furthermore, this application also discloses a computer-readable storage medium for storing a computer program; wherein, when the computer program is executed by a processor, it implements the aforementioned asynchronous task message passing method based on the MCP protocol. Specific steps of this method can be found in the corresponding content disclosed in the foregoing embodiments, and will not be repeated here.

[0122] The various embodiments in this specification are described in a progressive manner, with each embodiment focusing on its differences from other embodiments. Similar or identical parts between embodiments can be referred to interchangeably. For the apparatus disclosed in the embodiments, since it corresponds to the method disclosed in the embodiments, the description is relatively simple; relevant parts can be referred to in the method section.

[0123] Those skilled in the art will further recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of both. To clearly illustrate the interchangeability of hardware and software, the components and steps of the various examples have been generally described in terms of functionality in the foregoing description. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0124] The steps of the methods or algorithms described in conjunction with the embodiments disclosed herein can be implemented directly by hardware, a software module executed by a processor, or a combination of both. The software module can be located in random access memory (RAM), main memory, read-only memory (ROM), electrically programmable ROM, electrically erasable programmable ROM, registers, hard disk, removable disk, CD-ROM, or any other form of storage medium known in the art.

[0125] Finally, it should be noted that in this document, relational terms such as "first" and "second" are used only to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus 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 apparatus. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.

[0126] The technical solutions provided in this application have been described in detail above. Specific examples have been used to illustrate the principles and implementation methods of this application. The descriptions of the above embodiments are only for the purpose of helping to understand the methods and core ideas of this application. At the same time, for those skilled in the art, there will be changes in the specific implementation methods and application scope based on the ideas of this application. Therefore, the content of this specification should not be construed as a limitation of this application.

Claims

1. An asynchronous task message passing method based on the MCP protocol, characterized in that, Applied to callers registered as MCP endpoints, including: A full-duplex communication session is established between the service registry and the execution end based on the instance information issued by the service registry. Then, the protocol layer corresponding to the MCP protocol is used and task semantic information is established based on the initial task request. The execution end sends a target task request, including the task semantic information, to the execution terminal via the full-duplex communication session. The execution terminal then uses the Nacos service to determine a task node based on the target task request, and executes the corresponding task based on the task node, generating an event stream. The execution terminal has been registered as an MCP endpoint. Specifically, the target task request is determined based on the task semantic information and the initial task request, and sent to the execution terminal via the full-duplex communication session. The execution terminal uses the Nacos service to determine the corresponding task node based on the target task request, and uses the task node to parse the task semantic information in the target task request to obtain a parsing result. The execution terminal then calls the execution terminal to process the target task request based on the task type encoding in the parsing result. The system performs line processing logic matching to obtain a logic matching result. Based on the logic matching result and execution priority, it schedules the corresponding execution resources. Then, based on the execution resources, idempotent keys, and timeout thresholds, it executes the task to obtain the corresponding task execution result. The idempotent key is used to prevent the task node from performing repeated task processing operations, and the timeout threshold is used to terminate the task node when its execution time exceeds the timeout threshold. The system then calls the execution end to determine whether the task execution result indicates successful task execution. If the result indicates unsuccessful task execution, a retry strategy is used to re-execute the task, and the continuation token in the parsed result is associated with the task progress to obtain an association result. Finally, the event flow is determined based on the task execution result and the association result. The system determines whether the network connection is abnormal. If abnormal, it determines the location of the last successfully received event based on the globally unique event identifier corresponding to the event stream, and generates a reconnection request based on the event location and sends it to the execution end. The execution end then uses the reconnection request to sequentially transmit the corresponding event stream back to the calling end through the full-duplex communication session. The event stream includes a globally unique event identifier, task acceptance status, execution progress, process log, and task execution result. Based on the event stream and the preset confirmation strategy, a confirmation instruction is sent to the execution end, so that the execution end generates an event confirmation sequence number based on the confirmation instruction and sends the event confirmation sequence number to the calling end. Then, after the calling end receives the event confirmation sequence number, it determines that the task message transmission is complete.

2. The asynchronous task message passing method based on the MCP protocol according to claim 1, characterized in that, The establishment of a full-duplex communication session between the execution end and the service registry based on instance information issued by the service registry includes: The service registry is queried to obtain a list of instances corresponding to each execution end, and the target execution end is determined based on the health status and load indicators of the instances in the instance list, so as to establish a persistent full-duplex communication channel with the target execution end; the full-duplex communication channel supports bidirectional streaming message transmission between the calling end and the target execution end; Determine whether the instance list corresponding to the target execution end has undergone scaling up or down operations or a failure. If the instance list corresponding to the target execution end has undergone scaling up or down operations or a failure, call the Nacos service to perform a route update operation, obtain the update result, switch to the current instance list based on the update result, and set the calling end corresponding to the current instance list as the new target execution end.

3. The asynchronous task message passing method based on the MCP protocol according to claim 2, characterized in that, The process of calling the Nacos service to perform a route update operation and obtaining the update result includes: When the execution terminal starts, it sends a registration request to the service registry so that the service registry can register instance metadata based on the registration request; the instance metadata includes network address, service capabilities and instance health status. At preset time intervals, the system retrieves the instance list corresponding to each execution terminal from the service registry, and selects the corresponding instance list based on a preset routing strategy to establish a connection with the instance list; the instance list includes the corresponding instance metadata. The service registry is invoked to monitor the availability of the instance list in real time. When a failure or offline event is detected in the instance list, the Nacos service is invoked to notify the calling client to update the routing information and obtain the update result. This allows the calling client to perform failover based on the health status of the instances and the update result. The service registry also supports configuration management, allowing the runtime to adjust routing strategies and flow control parameters based on optimization goals that enhance system resilience and maintainability.

4. The asynchronous task message passing method based on the MCP protocol according to claim 1, characterized in that, The step of utilizing the protocol layer corresponding to the MCP protocol and establishing task semantic information based on the initial task request includes: The initial task request is configured with a globally unique event identifier using the protocol layer corresponding to the MCP protocol to obtain the corresponding globally unique event identifier. Based on the globally unique event identifier and the initial task request, the task type code, execution priority, idempotent key, timeout threshold and resume token corresponding to the initial task request are determined. Based on the globally unique event identifier, the task type code, the execution priority, the idempotent key, the timeout threshold, and the resume token, standardized semantic fields are determined, and task semantic information corresponding to the initial task request is determined based on the semantic fields.

5. The asynchronous task message passing method based on the MCP protocol according to claim 4, characterized in that, The process of determining whether the network connection is abnormal, and if so, determining the location of the last successfully received event based on the globally unique event identifier corresponding to the event stream, generating a reconnection request based on the event location and sending it to the execution end, so that the execution end can sequentially transmit the corresponding event stream back to the calling end through the full-duplex communication session based on the reconnection request, including: Determine if the network connection is abnormal. If it is abnormal, the execution end encapsulates the globally unique event identifier corresponding to each task event into a resume token and transmits the resume token to the calling end. The system utilizes a breakpoint resumption mechanism and generates the corresponding last successfully received event position based on the resumption token. Then, it determines the corresponding last confirmed event sequence number based on the event position. When the network connection is restored after an interruption, it sends a reconnection request including the last confirmed event sequence number to the execution end. This allows the execution end to replay the undelivered event stream to the calling end from the event position corresponding to the resumption token through the full-duplex communication session and based on the last confirmed event sequence number, and to continue pushing new event streams to the calling end. The breakpoint resume mechanism allows the calling end to restore the task state in the new instance based on the resume token after discovering the new instance through the service registry.

6. The asynchronous task message passing method based on the MCP protocol according to claim 5, characterized in that, The step of sending a confirmation instruction to the execution end based on the event stream and a preset confirmation strategy, so that the execution end generates an event confirmation sequence number based on the confirmation instruction and sends the event confirmation sequence number to the calling end, and then the calling end determines that the task message transmission is complete after receiving the event confirmation sequence number, includes: The system receives the event streams returned by the execution end, records the corresponding event sequence numbers according to the order in which the event streams arrive, and caches unacknowledged event streams. Then, it sends the corresponding acknowledgment instructions to the execution end using a preset strategy. The acknowledgment instructions include the sequence number of the last successfully received acknowledgment event. The preset strategy includes periodically sending the corresponding acknowledgment instructions to the execution end and sending the corresponding acknowledgment instructions to the execution end based on a preset event quantity threshold. The system detects whether the event stream is abnormal. If the event stream is abnormal, a negative acknowledgment instruction is sent to the execution end so that the execution end can generate a corresponding event stream to be retransmitted based on the negative acknowledgment instruction. If no abnormality occurs in the event stream, the confirmation instruction is sent to the execution end, so that the execution end generates an event confirmation sequence number based on the confirmation instruction and sends the event confirmation sequence number to the calling end, so that the calling end can determine that the task message corresponding to the target task request has been successfully delivered after receiving the event confirmation sequence number.

7. An asynchronous task message passing device based on the MCP protocol, characterized in that, Applied to callers registered as MCP endpoints, including: The task semantic information establishment module is used to establish a full-duplex communication session between the execution end and the service registry based on the instance information issued by the service registry. Then, it uses the protocol layer corresponding to the MCP protocol and establishes task semantic information based on the initial task request. An event stream generation module is used to send a target task request, including the task semantic information, to the execution end through the full-duplex communication session. This allows the execution end to utilize the Nacos service and determine the task node based on the target task request, then execute the corresponding task based on the task node and generate an event stream. The execution end has been registered as an MCP endpoint. Specifically, the module determines a target task request based on the task semantic information and the initial task request, and sends the target task request to the execution end through the full-duplex communication session. The execution end then utilizes the Nacos service and determines the corresponding task node based on the target task request. The task node is used to parse the task semantic information in the target task request to obtain a parsing result. Finally, the execution end calls the task type encoding in the parsing result to perform an event stream on the target task. The task request undergoes logical matching to obtain a logical matching result. Based on this result and the execution priority, corresponding execution resources are scheduled. Then, based on the execution resources, an idempotent key, and a timeout threshold, the task is executed to obtain the corresponding task execution result. The idempotent key is used to prevent the task node from performing duplicate task processing operations, and the timeout threshold is used to terminate the task node when its execution time exceeds the threshold. The execution end is then called to determine whether the task execution result indicates successful execution. If the result indicates unsuccessful execution, a retry strategy is used to re-execute the task, and the continuation token in the parsed result is associated with the task progress to obtain an association result. Finally, the event flow is determined based on the task execution result and the association result. The network connection judgment module is used to determine whether the network connection is abnormal. If abnormal, it determines the location of the last successfully received event based on the globally unique event identifier corresponding to the event stream, and generates a reconnection request based on the event location and sends it to the execution end, so that the execution end can send the corresponding event stream back to the calling end in sequence through the full-duplex communication session based on the reconnection request. The event stream includes a globally unique event identifier, task acceptance status, execution progress, process log, and task execution result. The confirmation instruction issuing module is used to send a confirmation instruction to the execution end based on the event stream and a preset confirmation strategy, so that the execution end generates an event confirmation sequence number based on the confirmation instruction and sends the event confirmation sequence number to the calling end. Then, the calling end determines that the task message transmission is complete after receiving the event confirmation sequence number.

8. An electronic device, characterized in that, include: Memory, used to store computer programs; A processor is configured to execute the computer program to implement the asynchronous task message passing method based on the MCP protocol as described in any one of claims 1 to 6.

9. A computer-readable storage medium, characterized in that, Used to store a computer program, wherein the computer program, when executed by a processor, implements the asynchronous task message passing method based on the MCP protocol as described in any one of claims 1 to 6.

Images