A minimal recursive delegation communication method and system

Abstract

This invention discloses a minimal recursive delegated communication method and system, belonging to the field of computer network communication. The system contains only two protocol primitives, `register` and `push`, and achieves complete dynamic discovery and task delegation functions through delegated interaction between gateway entities and protocol entities. The gateway entity is deconstructed into three protocol entities: server, brain, and agent. It supports topology reversal where the gateway itself is employed by a higher-level gateway as a protocol entity, achieving infinite recursion and indistinguishability of the delegate chain. The method employs a three-layer abstraction system (L0 / L1 / L2) to separate protocol specifications, extension mechanisms, and application semantics, allowing for the emergence of organizational forms such as bureaucracy and market mechanisms through replaceable employment decision rules. This invention demonstrates the minimal completeness of delegated networks and is applicable to scenarios such as AI multi-agent collaboration, IoT device management, and social organization simulation.

Description

Technical Field

[0001] This invention relates to the field of computer network communication and distributed systems, and in particular to a minimal recursive delegated communication method consisting of only two primitives and its gateway system, which can be used in scenarios such as multi-agent collaboration in artificial intelligence, IoT device management, distributed task scheduling, and social organization simulation. Background Technology

[0002] Existing distributed communication protocols (such as Remote Procedure Call (RPC), Representational State Transmission (REST), and Message Queues (MQ)) presuppose fixed client-server relationships or publish-subscribe topologies, and do not support the dynamic generation and infinite recursion of delegation chains. When a system needs to support the requirement that "any entity can recursively hire other entities at runtime," existing protocols cannot directly express this.

[0003] In terms of multi-agent organizational frameworks, frameworks such as MOISE+ and OMNI start from sociological ontology, presuppose meta-models such as roles, groups and norms, and are good at describing established organizational forms, but are difficult to simulate non-standard or adversarial organizational structures.

[0004] Furthermore, existing API gateway systems integrate routing decisions, authentication, and authorization logic within the gateway itself, lacking the topology reversal capability of "being able to be hired" and unable to support infinite recursion of delegation chains.

[0005] Therefore, a minimal recursive delegation communication method and system is needed to support arbitrary distributed delegation networks with a minimum set of primitives, while achieving infinite recursion and indistinguishability of the delegation chain through topology reversal. Summary of the Invention

[0006] The present invention aims to solve the following technical problems existing in the prior art: (1) Existing distributed protocols have a fixed topology and do not support the dynamic generation and infinite recursion of delegation chains; (2) Existing communication primitive sets have not proven their minimality and contain redundant primitives; (3) Existing gateway systems do not have the ability to reverse topology and cannot support the recursive delegation mode of "gateway as employed entity"; (4) Existing systems rely on a preset meta-model for simulating social organizational forms and lack generative capabilities.

[0007] To address the aforementioned technical problems, this invention provides a minimal recursive delegation communication method, applicable to a communication system containing at least one gateway entity, comprising the following steps: Step S1: The protocol entity declares its employability to the gateway through a registration primitive, which includes capability declaration parameters.

[0008] In step S2, the client submits a task intent to the gateway via a push primitive, the task intent containing a target capability identifier.

[0009] Step S3: Based on the target capability identifier, the gateway invokes its internal routing decision logic to select the target protocol entity from the registered protocol entities.

[0010] Step S4: The gateway delegates the task intent to the target protocol entity through the push primitive.

[0011] Step S5: If the target protocol entity is another gateway entity, the gateway entity recursively executes steps S3 to S4 to continue delegating the task intent to other protocol entities, forming an infinite recursion of the delegation chain.

[0012] For the top-level delegator, the internal recursive structure of the delegation chain is indistinguishable. The top-level delegator only perceives that the delegated party has implemented the registration primitive and push primitive, and cannot distinguish whether its internal entity is a terminal executor or a gateway entity that continues to delegate.

[0013] This invention also provides a minimal recursive delegation communication system, including a gateway entity. The gateway entity interacts with external protocol entities only through two communication primitives: a registration primitive, sent by the protocol entity to the gateway entity, used to declare the employable capabilities of the protocol entity; and a push primitive, used to delegate task intent to a target protocol entity. When the delegator submits a task intent to the gateway via the push primitive, the target protocol entity identifier can be a specific entity identifier or a capability requirement identifier. After the gateway completes capability matching, it forwards the task to the successfully matched target protocol entity via the push primitive.

[0014] The gateway entity is deconstructed into a collaborative combination of three independent protocol entities: a server protocol entity, responsible for monitoring transport layer connections, maintaining the set of registered protocol entities, performing heartbeat detection and timeout management, and receiving external messages and forwarding them through the registration primitive or push primitive; a brain protocol entity, responsible for making routing decisions based on capability matching; and a proxy protocol entity, responsible for registering itself as an employable protocol entity with the upper-level gateway, enabling the current gateway to be employed by the upper-level gateway as a protocol entity. When the upper-level gateway delegates a task to this gateway through a push primitive, the proxy protocol entity receives the task and imports it locally, where it is then processed by the local server protocol entity and brain protocol entity.

[0015] The interaction semantics between the three independent protocol entities, and between the three independent protocol entities and external protocol entities, all follow the interaction semantics of the registration primitives and push primitives. In tight mode, the interaction is implemented through function calls, maintaining consistency with the protocol semantics of the registration / push primitives. In loose mode, the interaction is implemented through network communication.

[0016] The technical solution of this invention has the following beneficial effects: (1) Minimal Completeness. This invention proves that the two primitives (register and push) are complete and minimal for a delegated network. Register alone cannot convey intent, and push alone cannot dynamically discover new employable entities; therefore, the two primitives are incompressible lower bounds. Furthermore, the two primitives possess orthogonal completeness: depending on the interaction mode, protocol entities can flexibly choose a subset of primitives; synchronization clients can use only the push primitive, worker nodes can use only the registration primitive, and the complete agent uses both simultaneously. This flexibility does not change the minimum completeness at the protocol level.

[0017] (2) Recursive indistinguishability. This invention achieves infinite recursion of the delegation chain through topological reversal, where "the gateway itself can also be employed as a protocol entity." For the top-level delegator, the internal structure of the delegate is imperceptible; it can only observe the registration and push interfaces and cannot distinguish between the terminal executor and the recursive gateway. This accurately models the essential characteristics of "outsourcing" in real-world organizations.

[0018] (3) Three-layer abstraction system. This invention adopts a three-layer abstraction system of L0 / L1 / L2 to separate the protocol specification from the implementation details. The L0 layer defines the minimum primitives (registration / push), the L1 layer provides technical conveniences (heartbeat, backhaul, transmission adaptation), and the L2 layer is defined by the application itself (payload structure, encryption mode). This ensures a balance between protocol strictness and flexibility.

[0019] (4) No pre-defined organizational model. This invention does not pre-define roles, groups, or norms. The organizational form depends entirely on the hiring decision rules of the brain protocol entity. By replacing the rules, the same infrastructure can give rise to diverse structures such as bureaucracy, market system, and relationship network, and can also simulate non-standard structures such as ghost organizations and circular employment networks.

[0020] (5) Dual-mode transmission support. It supports two heterogeneous transmission modes: WebSocket long connection and HTTP long polling. The transport layer implementation can be replaced with Unix Domain Socket, shared memory and other mechanisms to keep the protocol semantics unchanged. Attached Figure Description

[0021] Figure 1 This is a schematic diagram of the minimal recursive delegate communication method provided in an embodiment of the present invention.

[0022] Figure 2 This is a schematic diagram illustrating the indistinguishability of topological reversal and recursion provided in an embodiment of the present invention.

[0023] Figure 3 This is a schematic diagram of the transmission mode and three-layer abstraction system provided in the embodiments of the present invention.

[0024] Figure 4This is a schematic diagram of a three-pivot gateway architecture provided in an embodiment of the present invention.

[0025] Figure 5 A comparison table of plug-in rules and organizational morphology emergence provided for embodiments of the present invention. Detailed Implementation

[0026] To make the objectives, technical solutions, and advantages of the present invention clearer, the present invention will be further described in detail below with reference to the accompanying drawings.

[0027] I. Minimal Recursive Delegation Communication Method like Figure 1 As shown, the communication method proposed in this invention only specifies two interaction primitives: a registration primitive, sent by the protocol entity to the gateway, with the semantics "I exist, I can be hired." The capabilities parameter declares the capabilities supported by the entity, such as chat, calc, etc., and a push primitive, used to delegate task intent to the target protocol entity. In a typical delegation process, the delegator submits the task intent to the gateway through the push primitive (at this time, the target identifier can be a capability requirement rather than a specific entity identifier). After the gateway completes capability matching, it forwards the task to the successfully matched target protocol entity through the push primitive. The message includes the sender identifier, target identifier, message type, payload, tracking identifier, and timestamp. At the L2 application semantic layer, protocol entities can also agree to direct point-to-point push, bypassing the gateway intermediary.

[0028] Specific implementation of the method and process: Step S1 (Registration Declaration): After the protocol entity starts, it sends a capability declaration to the server protocol entity of the gateway via a registration primitive. The server protocol entity forwards the registration information to the brain protocol entity, which then updates the capability index table.

[0029] Step S2 (Task Submission): The delegating party (which can be an external protocol entity or an upstream gateway) submits the task intent to the gateway via push primitives. The task payload includes a sync flag (to distinguish between synchronous / asynchronous modes), required capability identifiers, task data, etc.

[0030] Step S3 (Route Decision): The server protocol entity forwards the task to the brain protocol entity via push primitives. The brain protocol entity executes the routing decision algorithm: extracting the required capabilities, filtering candidate entities, load balancing and sorting, and selecting the target entity.

[0031] Step S4 (Task Delegation): Based on the decision of the brain protocol entity, the server protocol entity delegates the task to the selected target protocol entity through push primitives.

[0032] Step S5 (Recursive Delegation): If the target protocol entity is a gateway (i.e., the upstream gateway uses the proxy protocol entity to target this gateway), then this gateway receives the task through the proxy protocol entity and recursively executes steps S3-S4 locally. If the target protocol entity is another downstream gateway, then the proxy protocol entity forwards the task to that downstream gateway for continued recursive processing. During this process, the proxy protocol entity maintains semantic transparency and does not parse the payload content.

[0033] Implementation of recursive indistinguishability: For the top-level delegator (Root Client), it only perceives that the peer it directly interacts with implements the registration and push interfaces. Regardless of whether the peer is a terminal executor (directly handling tasks) or a recursive gateway (continuing to delegate to other entities through an internal proxy protocol entity), the code implementation of the top-level delegator requires no modification. This recursive indistinguishability is achieved through the uniformity of the protocol layer interface, rather than through encapsulation or proxy techniques.

[0034] II. Three-pivot gateway architecture like Figure 4 As shown, the gateway system is deconstructed into a collaborative combination of three independent protocol entities: The server protocol entity is responsible for transport layer governance, including: listening to HTTP and WebSocket ports (which can be configured as shared ports), managing the lifecycle of the protocol entity (registration, heartbeat, disconnection, reconnection), maintaining the connection state mapping table (WebSocket long connection or HTTP long polling suspended response), and protocol adaptation (unifying the parsing of data from different transport layers into push / registration semantic objects).

[0035] For WebSocket long connections: After registration, start heartbeat detection (every 30-second interval) and timeout disconnection (60 seconds of no response). Update the last heartbeat time when any message is received.

[0036] For HTTP long polling: After registration, the reply object is suspended to the waiting queue. When the main protocol entity determines that a message needs to be sent, it writes the message to the response using the overridden send method and ends the request. Upon receiving the response, the protocol entity immediately re-initiates the registration request, forming a "request-suspend-response-reconnect" loop.

[0037] The brain protocol entity, responsible for routing decisions, operates as a pluggable hiring decision rule engine. Its implementation is equivalent to the server protocol entity, also registering with the server protocol entity via registration primitives and receiving task distribution requests via push primitives.

[0038] The core function `onTaskSubmit` determines which protocol entity a new task should employ. Technically, the brain protocol entity can be designed as: a built-in module (tight mode, function call), an external service (loose mode, network push), or multiple redundant instances (high-availability deployment).

[0039] The proxy protocol entity is responsible for topology reversal and gateway cascading. It registers itself as an employable protocol entity with the upper-level gateway, making the current gateway a regular protocol entity in the upper-level gateway's view.

[0040] When the upper-level gateway delegates a task to this gateway through a push primitive: (1) the proxy protocol entity receives the push message from the upper-level gateway; (2) the message is handed over to the local server protocol entity and the brain protocol entity for processing; (3) the local brain protocol entity performs routing decisions and selects local or other downstream protocol entities to execute; (4) the execution result is returned to the upper-level gateway by the proxy protocol entity through the push primitive.

[0041] The proxy protocol entity only forwards the protocol during this process and does not parse the L2 layer payload semantics. Through this mechanism, the upper-level gateway treats this gateway as a black-box protocol entity, realizing topology reversal where the "gateway acts as an employee".

[0042] III. Implementation of Transport Layer Replaceability like Figure 3 As shown, the transport layer implementation supports substitutability: L0 layer protocol semantics: an abstract interaction between registration primitives and push primitives, independent of the transmission mechanism.

[0043] L1 layer transport adaptation: Supports multiple transport mechanisms, including: WebSocket (bidirectional long connection, suitable for high-frequency interaction), HTTP long polling (one-way pull, suitable for firewall-restricted environments), Unix Domain Socket (inter-process communication on the same host, zero TCP overhead), and shared memory (tight mode, nanosecond-level latency).

[0044] When replacing the transport layer, the implementation method that keeps the protocol semantics unchanged is as follows: the server protocol entity configures the transport adapter (TransportAdapter interface). The adapter is responsible for uniformly parsing the transport layer specific data (HTTP request body, WebSocket frame, UDS data packet) into registration / push semantic objects, thus decoupling the business logic of the protocol entity layer from the specific transport mechanism.

[0045] IV. Emergence and Implementation of Organizational Forms like Figure 5 As shown, by replacing the employment decision rules of the brain protocol entities, different organizational forms emerge from the same protocol infrastructure: Bureaucratic hierarchical structure: The hiring decision rule is based on matching with fixed department identifiers. The implementation involves a task payload containing a "department" field, and the brain protocol entity filters protocol entities with the corresponding departmental capabilities. This corresponds to a hierarchical organization where tasks are allocated according to departmental responsibilities.

[0046] Market-based competitive bidding structure: The hiring decision rule is an auction mechanism, with the lowest bidder winning. The implementation involves the agreement entity declaring a cost parameter during registration, and the central agreement entity selecting the entity with the lowest cost and meeting its capabilities. In reality, this corresponds to bidding and procurement, where economic agents make rational choices.

[0047] Relationship network structure: The hiring decision rule is reputation ranking, prioritizing entities with high historical success rates. The implementation involves the brain-like agreement entity maintaining historical success rate statistics and using weighted ranking for selection. In reality, this corresponds to relational transactions and a trust network.

[0048] Flat network structure: The hiring decision rule is random assignment or round-robin. The implementation method is random selection from a candidate protocol entity list or Round-Robin. The corresponding reality is decentralized collaboration with no hierarchical structure.

[0049] Non-standard structure simulation: Ghost organizations: When the intent initiator (task owner or controller) goes offline or loses contact, the protocol entities in the established delegation chain continue to execute the task according to the established rules, but the system loses the ability to receive new intents or change existing intents. This corresponds to the structural phenomenon in real-world organizations where ownership and management are separated, resulting in the absence of an owner but the business continuing to operate.

[0050] Circular employment network: Gateway A's proxy protocol entity registers with Gateway B, and Gateway B's proxy protocol entity registers with Gateway A, forming a cross-employment. Recursive delegation can create circular paths, which are terminated by hop count limits or business layer detection.

[0051] V. Implementation of Synchronous and Asynchronous Dual Mode Synchronous blocking mode: The implementation involves the server protocol entity maintaining a pendingRequests mapping table (traceId to Promise callback). The process is as follows: send a push primitive, register for a waiting callback, the target entity processes the request, returns a response carrying the same traceId, wakes up the Promise, and returns to the delegator. Timeout management is a 30-second timeout; after the timeout, the request is rejected and the mapping table is cleaned up.

[0052] Asynchronous non-blocking mode: The implementation involves the server protocol entity recording the taskId and mapping it to the pivotId, which is then mapped to the TaskRouter. It immediately returns the accepted value and the taskId. Subsequent queries are performed by the delegating party using the task identifier to check the status, or by the target entity actively pushing progress / results.

[0053] VI. Zero-copy streaming (preferred implementation) As a preferred implementation of the L1 layer extension mechanism, the system supports zero-copy streaming: Use cases: large file transfer, real-time audio and video streaming, sensor data streaming.

[0054] Implementation Mechanism: The consumer protocol entity initiates a GET request to the pipe endpoint, and the server protocol entity suspends the response object. The producer protocol entity submits the data stream to the pipe endpoint via a POST request. The server protocol entity disables default request body parsing. The POST request body is directly forwarded to the GET response object via piped transmission, without memory buffering.

[0055] Protocol positioning: This mechanism is a convenience of L1 layer technology and is not necessary for L0 layer protocols. Protocol entities can completely bypass this mechanism and agree on their own peer-to-peer private channels at L2 layer (such as QUIC direct connection, WebRTC DataChannel).

[0056] VII. Reference Implementation Architecture The reference implementation of this invention adopts the Node.js / TypeScript technology stack, and the core modules include: Unified Message Protocol Module: Parses all transport layer data into Message objects (including senderId, targetId, type, payload, traceId, timestamp), and business logic is processed based on Message, decoupled from the transport protocol.

[0057] Gateway server module: The HTTP server and WebSocket server share a port, and the protocols are distinguished by the Upgrade header.

[0058] Connection governance module: Unified management of WebSocket long connections (heartbeat detection) and HTTP long polling (response suspension queue).

[0059] Plugin routing module: The brain protocol entity is registered in localMode and runs in the same process as the server protocol entity. It makes decisions through direct method calls, without network serialization overhead.

[0060] VIII. Relationship with Existing Plans Relationship with MOISE+: MOISE+ pre-sets its structure based on "roles" and "groups." This invention starts with "delegation relationships," where roles are merely protocol entities that implement registration, groups are simply collections of entities sharing the gateway, and the structure is dynamically generated by hiring rules rather than being statically pre-set.

[0061] IX. Limitations The current reference implementation is a proof-of-concept: the brain protocol entity does not yet support independent process deployment; the security layers (authentication, encryption, reputation) need to be implemented by the L2 layer application itself; only HTTP / WebSocket transmission is verified, and large-scale concurrent performance requires further testing. Furthermore, as a minimal delegation layer, this invention does not introduce additional computational overhead; end-to-end latency depends on the processing time of the underlying transport protocol and the execution entity.

[0062] The above description represents the preferred embodiments of the present invention. It should be noted that those skilled in the art can make various improvements and modifications without departing from the principles of the present invention, and these improvements and modifications should also be considered within the scope of protection of the present invention.

Claims

1. A minimal recursive delegation communication method, applied to a communication system containing at least one gateway entity, characterized in that, Includes the following steps: Step S1: The protocol entity declares its employability to the gateway through a registration primitive, wherein the registration primitive includes capability declaration parameters; Step S2: The client submits a task intent to the gateway via a push primitive, and the task intent includes a target capability identifier. Step S3: Based on the target capability identifier, the gateway invokes its internal routing decision logic to select a target protocol entity from the registered protocol entities; Step S4: The gateway delegates the task intent to the target protocol entity through the push primitive; Step S5: If the target protocol entity is another gateway entity, the gateway entity recursively executes steps S3 to S4 to continue delegating the task intent to other protocol entities, forming an infinite recursion of the delegation chain. For the top-level delegator, the internal recursive structure of the delegation chain is indistinguishable. The top-level delegator only perceives that the delegated party has implemented the registration primitive and push primitive, and cannot distinguish whether its internal entity is a terminal executor or a gateway entity that continues to delegate.

2. The method according to claim 1, characterized in that, The gateway entity itself is also employed by other gateway entities as a protocol entity. When employed as a protocol entity, the gateway entity runs its internal routing decision logic after receiving the push primitive to achieve topology reversal of the delegation chain.

3. The method according to claim 1, characterized in that, The method employs a three-layer abstraction system: The L0 protocol primitive layer includes two core primitives: the registration primitive and the push primitive. The L1 extension mechanism layer includes heartbeat keep-alive, result feedback, and progress query technology message types, which are provided by the reference implementation but are allowed to be replaced in other ways. The L2 application semantic layer includes the data structure of the task payload, end-to-end encryption mode, and point-to-point private communication channel, which are agreed upon by the protocol entities themselves.

4. The method according to claim 1, characterized in that, The gateway supports synchronous blocking mode and asynchronous non-blocking mode: In the synchronous blocking mode, the gateway enters a waiting state after sending the push primitive until it receives a response message carrying the same tracking identifier, and then returns the response data to the delegator. In the asynchronous non-blocking mode, the gateway immediately returns a task accepted status after sending the push primitive and records the mapping relationship between the task identifier and the target protocol entity identifier for subsequent querying.

5. The method according to claim 1, characterized in that, The registration primitives and push primitives are transmitted through a heterogeneous transmission mode, which includes WebSocket long connection and HTTP long polling. For WebSocket long connections, a heartbeat detection timer and a timeout disconnect timer are started after the protocol entity is registered. The last heartbeat time is updated when a message is received from the protocol entity. For HTTP long polling connections, the response object is suspended after the protocol entity has completed registration. When there are messages to be sent, the message is returned to the protocol entity through the overridden send method, and the protocol entity re-initiates the registration request to continue receiving messages.

6. The method according to claim 5, characterized in that, The underlying transmission implementation of the heterogeneous transmission mode can be replaced by any one or more of Unix Domain Socket, shared memory, named pipe, QUIC protocol or TCP direct connection. When the registration primitive and push primitive are transmitted through the replaced transmission mechanism, the protocol semantics remain unchanged.

7. The method according to claim 1, characterized in that, The routing decision logic is configured to support replaceable hiring decision rules. By replacing different hiring decision rules, the communication system can generate different organizational topologies, which include any one of the following: bureaucratic hierarchical structure, market-based bidding structure, relational network structure, or flat network structure.

8. The method according to claim 1, characterized in that, In step S3, the routing decision logic includes: Extract the required capability identifiers from the mission payload; Retrieve capability claims information for all registered protocol entities; Filter out candidate protocol entities whose capability declarations match the required capability identifiers; The candidate protocol entities are sorted by load balancing based on the number of tasks assigned to each entity, and the entity with the lowest load is selected as the target protocol entity.

9. The method according to claim 1, characterized in that, When a protocol entity disconnects, the gateway caches the registration and status information of that protocol entity in the disconnection cache and sets an expiration time. When the protocol entity reconnects, it restores the registration information and status information from the disconnection cache to complete the reconnection.

10. A minimal recursive delegated communication system, comprising a gateway entity, characterized in that, The gateway entity interacts with the external protocol entity using only two communication primitives: Registration primitives are sent by the protocol entity to the gateway entity to declare the employability of the protocol entity; Push primitives are used to delegate task intent to target protocol entities. When the delegating party submits task intent to the gateway through push primitives, the target protocol entity identifier can be a specific entity identifier or a capability requirement identifier. After the gateway completes capability matching, it forwards the task to the successfully matched target protocol entity through push primitives. The gateway entity is deconstructed into a collaborative combination of three independent protocol entities: The server protocol entity is responsible for listening to transport layer connections, maintaining the set of registered protocol entities, performing heartbeat detection and timeout management, receiving external messages and forwarding them through the registration primitives or push primitives; The brain protocol entity is responsible for making routing decisions based on capability matching. The proxy protocol entity is responsible for registering itself as an employable protocol entity with the superior gateway, so that the current gateway can be employed by the superior gateway as a protocol entity. When the upper-level gateway delegates a task to this gateway through the push primitive, the proxy protocol entity receives the task and imports it into the local area, where it is processed by the local server protocol entity and the brain protocol entity. The interaction semantics between the three independent protocol entities, as well as between the three independent protocol entities and external protocol entities, all follow the interaction semantics of the registration primitives and push primitives. In tight mode, the interaction is implemented through function calls, maintaining consistency with the protocol semantics of the registration primitives / push primitives. In loose mode, the interaction is implemented through network communication.

11. The system according to claim 10, characterized in that, The operating modes of the three independent protocol entities include: Tight mode: The three protocol entities reside in the same process, and the registration primitives and push primitives are implemented through function calls, following protocol semantics and maintaining interface compatibility; Loose mode: The three protocol entities are deployed independently on different processes or different machines, and the registration primitives and push primitives are implemented through network communication.

12. The system according to claim 10, characterized in that, The brain protocol entity and the external protocol entity are completely equivalent in architecture. The brain protocol entity completes registration by sending a registration primitive to the server protocol entity. The server protocol entity sends a task distribution request to it by pushing a primitive. After the brain protocol entity processes the request, it returns the decision result.

13. The system according to claim 10, characterized in that, The brain protocol entity is configured to support a pluggable hiring decision rule engine, which includes at least one of the following types: Fixed-level matching rule: Match the corresponding protocol entity based on the department identifier in the task payload; Auction bidding rules: Select the target entity based on the bid or resource consumption indicators of the agreement entity; Reputation-weighted rule: Selected based on the historical execution success rate of the agreement entities; Random allocation rule: Select randomly from candidate protocol entities; By changing the employment decision rule engine, the system can generate different organizational topologies.

14. The system according to claim 10, characterized in that, The proxy protocol entity maintains multiple connection configurations to the upper-level gateway. When the upper-level gateway delegates a task to this gateway through a push primitive, the proxy protocol entity receives the task and imports it locally. The local brain protocol entity then makes a routing decision and selects a local or other downstream protocol entity to execute the task. The execution result is returned to the upper-level gateway by the proxy protocol entity through a push primitive.

15. The system according to claim 10, characterized in that, The server protocol entity is configured to manage two heterogeneous transmission modes: WebSocket long-connection and HTTP long polling connection. For WebSocket long connections, a heartbeat detection timer and a timeout disconnect timer are started after the protocol entity is registered. When any message is received from the protocol entity, the last heartbeat time is updated and the timeout timer is reset. For HTTP long polling connections, the response object is suspended after the protocol entity completes registration. When there is a message to be sent, the message is returned to the protocol entity through the rewritten sending method and the connection is cleaned up. The protocol entity then re-initiates the registration request to continue receiving messages.

16. The system according to claim 15, characterized in that, The transport layer adapter of the server protocol entity is configured to support any one or more communication mechanisms, such as WebSocket, HTTP long polling, Unix Domain Socket, and shared memory. When the registration primitive and push primitive are transmitted through the transport layer adapter, the protocol semantics remain unchanged.

17. The system according to claim 10, characterized in that, The server protocol entity is configured to support two task distribution modes: synchronous blocking mode and asynchronous non-blocking mode. In the synchronous blocking mode, after the server protocol entity sends the push primitive to the target protocol entity, it enters a waiting state until it receives a response message carrying the same end-to-end tracing identifier, and then directly returns the response data to the client. In the asynchronous non-blocking mode, after the server protocol entity sends the push primitive to the target protocol entity, it immediately returns the task accepted status and records the mapping relationship between the task identifier and the target protocol entity identifier for subsequent querying.

18. The system according to claim 10, characterized in that, The brain protocol entity is configured to cache the registration information and status information of the protocol entity to the disconnection cache and set an expiration time when the protocol entity disconnects. When the protocol entity reconnects, it restores the registration information and status information from the disconnection cache to complete the reconnection.

19. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by a processor, it implements the minimal recursive delegate communication method as described in any one of claims 1 to 9.

Images