A communication method applied to a Codigger system

By introducing the Vimcall mechanism and a three-layer packet structure into the Codigger system, the complexity and high cost of the traditional RPC model in large-scale distributed systems are solved, achieving efficient, reliable data communication and rapid response.

CN120567908BActive Publication Date: 2026-03-24GUANGZHOU YUNBIAO NETWORK TECH CO LTD
View PDF 2 Cites 0 Cited by

Patent Information

Authority / Receiving Office
CN · China
Patent Type
Patents(China)
Current Assignee / Owner
Filing Date
2025-06-03
Publication Date
2026-03-24

AI Technical Summary

Technical Problem

Traditional RPC communication models suffer from problems such as complex role division, high development and maintenance costs, and insufficient system reliability and scalability in large-scale distributed systems.

Method used

The Vimcall mechanism, based on a point-to-point communication model, simplifies the data exchange process by generating and parsing Vimcall functions. It introduces a three-layer Vimcall data packet structure and optimizes data routing using Mudem and Router nodes to achieve dynamic feedback and flexible data processing.

Benefits of technology

It reduces development and maintenance costs, improves system reliability and scalability, enhances the efficiency and flexibility of inter-node communication, and optimizes system response speed and real-time performance.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure CN120567908B_ABST
    Figure CN120567908B_ABST
Patent Text Reader

Abstract

The application relates to the technical field of communication, in particular to a communication method applied to a Codigger system; the Codigger system is composed of a communication network and a plurality of independent communication nodes connected with the communication network; when communication is carried out between any two communication nodes, the following steps are included: a first communication node generates a first Vimcall based on request data; the first communication node sends the first Vimcall to a second communication node through the communication network; the second communication node receives the first Vimcall; the second communication node analyzes and extracts the request data in the first Vimcall; the second communication node generates feedback data according to the request data; the second communication node generates a second Vimcall based on the feedback data; the second communication node sends the second Vimcall to the first communication node through the communication network; the first communication node receives the second Vimcall; and the first communication node analyzes and extracts the feedback data in the second Vimcall.
Need to check novelty before this filing date? Find Prior Art

Description

Technical Field

[0001] This invention relates to the field of communication technology, and in particular to a communication method applied to the Codigger system. Background Technology

[0002] Traditional Remote Procedure Call (RPC) models typically employ a client-server architecture, requiring a clear division of roles: the client initiates requests, while the server responds. This model increases system design complexity to some extent, especially in scenarios with a large number of nodes and high reliability and scalability requirements, where traditional RPC communication methods struggle to meet these demands. Furthermore, traditional RPC communication models require developers to manually write stubs and proxies, which not only increases development and maintenance workload but also leads to increased complexity and maintenance costs as the system scales, hindering rapid development and efficient expansion. Summary of the Invention

[0003] This invention provides a communication method for the Codigger system, aiming to provide a simplified, point-to-point communication model-based solution to reduce the development and maintenance burden caused by role division, complex client-server architecture, and manual writing of stub and proxy programs in traditional RPC communication, while improving the reliability and scalability of the system in a large-scale distributed environment.

[0004] In one embodiment of the present invention, the communication method applied to the Codigger system, wherein the Codigger system comprises a communication network and several independent communication nodes connected to the communication network, includes the following steps when any two communication nodes communicate: a first communication node generates a first Vimcall based on request data; the first communication node sends the first Vimcall to a second communication node through the communication network; the second communication node receives the first Vimcall; the second communication node parses and extracts the request data from the first Vimcall; the second communication node generates feedback data based on the request data; the second communication node generates a second Vimcall based on the feedback data; the second communication node sends the second Vimcall to the first communication node through the communication network; the first communication node receives the second Vimcall; and the first communication node parses and extracts the feedback data from the second Vimcall. The present invention provides a Vimcall-based communication method that significantly reduces development and maintenance costs by simplifying the client-server architecture in traditional RPC communication. Through a decentralized peer-to-peer communication model, it improves the reliability and fault tolerance of the system, while enhancing the scalability of the system in a large-scale distributed environment. Vimcall's efficient data transmission and flexible feedback mechanism make inter-node communication more efficient, reduce latency, and enable rapid response to business needs. Furthermore, this invention supports dynamic feedback and flexible data processing, effectively improving the system's real-time performance and business adaptability.

[0005] In this embodiment or other embodiments, the generation of a Vimcall by any communication node includes the following steps: the communication node calls the Vimcall function; the communication node generates a Vimcall based on request data or feedback data through the Vimcall function. When the Vimcall function is called by the communication node to generate a Vimcall, the Vimcall function performs the following steps: generating an initial request based on the request data or feedback data; serializing the initial request to generate a standard request; and encapsulating the standard request to generate a Vimcall data packet. This invention simplifies the data exchange process between communication nodes by introducing a Vimcall function generation and encapsulation mechanism. Each communication node automatically generates a Vimcall data packet based on request data or feedback data by calling the Vimcall function, avoiding the tedious work of manually writing stub programs and proxy programs in the traditional RPC communication model. This not only reduces development and maintenance costs but also improves the development efficiency and flexibility of the system. Through standardized request and data packet encapsulation, the efficiency and accuracy of data transmission are ensured, and the stability and reliability of inter-node communication are improved. Meanwhile, the use of the Vimcall mechanism enhances the system's scalability, enabling nodes to quickly adapt to different business needs and supporting flexible data processing and feedback generation, further optimizing the system's response speed and real-time performance.

[0006] In this embodiment or other embodiments, the parsing of a Vimcall by any communication node includes the following steps: the communication node calls the Vimcall function; the communication node parses the Vimcall data packet using the Vimcall function. When the Vimcall function is called by the communication node to parse the Vimcall, the Vimcall function performs the following steps: extracting the standard request from the Vimcall data packet; deserializing the standard request to obtain the request data or the feedback data. This invention simplifies the processing of Vimcall data packets by introducing a parsing mechanism for the Vimcall function. The communication node parses the data packet using the Vimcall function, extracts the standard request, and deserializes it to obtain the request data or feedback data. This process reduces reliance on complex parsing logic and improves the efficiency and accuracy of data processing. Simultaneously, the standardized parsing of the Vimcall function ensures data compatibility and consistency between different nodes, reducing the difficulty of interoperability between systems. This method not only accelerates the data exchange process but also optimizes the use of system resources, ensuring efficient and reliable data communication in a distributed environment.

[0007] In this embodiment or other embodiments, any communication node calling the Vimcall function to generate a Vimcall includes the following steps: the communication node obtains the Vimcall interface, which includes at least transport layer data input items and application layer data input items; the communication node inputs request data based on the Vimcall interface and calls the Vimcall function to generate a Vimcall data packet. This invention simplifies the process of communication nodes generating Vimcall data packets by introducing the Vimcall function interface. Nodes can flexibly input request data by obtaining the Vimcall interface, transport layer data, and application layer data items, thereby generating Vimcall data packets. This method reduces the need for manually writing complex code and improves development efficiency. Through the standardized Vimcall interface, nodes can efficiently and accurately generate data packets that conform to the specifications, ensuring data compatibility and consistency among communication nodes in the system. Furthermore, the design of the Vimcall interface allows nodes to quickly adapt to different business needs, enhancing the scalability and flexibility of the system and improving the overall system performance.

[0008] In this embodiment or other embodiments, when any communication node calls the Vimcall function to parse a Vimcall, the process further includes the following step: outputting the feedback data parsed from the Vimcall through the Vimcall interface. This invention further simplifies the parsing process of Vimcall data packets by introducing the Vimcall interface. After parsing the Vimcall data packet through the Vimcall interface, the node can directly output the parsed feedback data, thereby reducing complex subsequent processing steps. This method improves the efficiency of data transmission and processing, ensuring rapid data exchange and real-time feedback between nodes. Through standardized interfaces, the system can better support data processing needs in different business scenarios, while enhancing the system's flexibility and scalability. Furthermore, the rapid output of feedback data optimizes the system's response speed, further improving overall performance and reliability.

[0009] In this embodiment or other embodiments, any Vimcall data packet includes at least the following three layers of data: transport layer data, which includes at least routing data; extension layer data, which includes at least one type of transport task management data; and application layer data, which includes request data or feedback data. This invention optimizes the data transmission process by designing a Vimcall data packet with a three-layer structure, which helps improve data transmission efficiency and thus enhances the scalability and reliability of the system in a large-scale distributed environment.

[0010] In this embodiment or other embodiments, during the transmission of any Vimcall in the communication network, the communication network performs the following steps based on the Vimcall: at the network transport layer, the transport layer data of the Vimcall data packet is parsed, and a routing node in the communication network is selected according to the transport layer data to send the Vimcall data packet to the corresponding communication node. This invention optimizes the routing and forwarding process of data packets by parsing the transport layer data of Vimcall data packets at the transport layer of the communication network. During the transmission of data packets, the network dynamically selects the most suitable routing node according to the transport layer data, ensuring that the data packets can be transmitted accurately and quickly to the target communication node. This mechanism significantly improves the efficiency of data transmission and reduces delays or packet loss caused by network congestion or node failures. Through this method, the network can intelligently select the optimal path, enhancing the system's adaptability and reliability, especially in large-scale distributed environments, ensuring stable data transmission.

[0011] In this embodiment or other embodiments, the routing nodes selected by any Vimcall data packet during transmission include at least one Mudem node and / or at least one Router node. This invention further optimizes the data routing and forwarding mechanism by introducing Mudem and Router nodes during Vimcall data packet transmission. Mudem nodes are primarily responsible for data forwarding within the local network, while Router nodes are responsible for routing across networks or subnets. This design enhances the flexibility and transmission efficiency of data packets, improves the system's fault tolerance and scalability, ensures that Vimcall data packets can quickly and accurately reach the target node in complex network environments, and optimizes the system's performance in large-scale distributed networks.

[0012] In this embodiment or other embodiments, during the transmission of any Vimcall in the communication network, the communication network, based on the Vimcall, further performs the following steps: at the network function layer, it parses the function layer data of the Vimcall data packet and manages the transmission process of the Vimcall data packet in the network according to the function layer data. This invention further enhances the flexibility and management capability of the data transmission process by parsing the function layer data of the Vimcall data packet at the network function layer and then monitoring and adjusting the transmission status of the Vimcall data packet in the network in real time based on the function layer data.

[0013] In this embodiment or other embodiments, the functional layer data includes, but is not limited to, task scheduling data, network status data, error detection and recovery data, and flow control data. This invention optimizes the transmission process of Vimcall data packets by introducing multiple data types, including task scheduling data, network status data, error detection and recovery data, and flow control data, into the functional layer. Attached Figure Description

[0014] Figure 1 This is a schematic diagram of the Codigger system structure provided in an embodiment of the present invention;

[0015] Figure 2 This is a flowchart of the communication method applied to the Codigger system provided by the present invention. Detailed Implementation

[0016] In the following description, specific details such as particular systems, structures, and techniques are set forth for illustrative purposes rather than limiting, in order to provide a thorough understanding of the embodiments of this application.

[0017] Those skilled in the art will understand that this application can also be implemented in other embodiments without these specific details.

[0018] In the description of this application, detailed descriptions of well-known systems, devices, circuits and methods have been omitted so as not to obscure the description of this application with unnecessary details; in addition, the terms "first", "second", etc. are used only to distinguish descriptions and should not be construed as indicating or implying relative importance.

[0019] Based on the shortcomings of the traditional Remote Procedure Call (RPC) model in existing distributed systems, this invention provides a simplified solution based on a point-to-point communication model to reduce the development and maintenance burden caused by role division, complex client-server architecture, and manual writing of stub and proxy programs in traditional RPC communication, while improving the reliability and scalability of the system in large-scale distributed environments.

[0020] It should be noted that the Codigger system described in this invention is a distributed operating system, which is mainly used to provide users with security vulnerability detection and code analysis services; however, in other application scenarios, the Codigger system described in this invention can be understood as a distributed operating system that provides the same or different services as this invention.

[0021] In one embodiment, see Figure 1 , Figure 1 This is a schematic diagram of the Codigger system structure provided in an embodiment of the present invention. Figure 1As shown, the Codigger system includes several independent communication nodes, from peer1 to peerN; and each communication node, specifically peer1, peer2, ... and peerN, is connected to the same communication network. Any two communication nodes are independent of each other and have equal communication capabilities. That is, each communication node can be used as an independent computing unit, and can perform tasks without relying on other nodes. It can also exchange data and cooperate to complete more complex tasks.

[0022] Further, please see Figure 2 , Figure 2 This is a flowchart illustrating the communication method applied to the Codigger system provided by the present invention. It should be noted that in this communication method, the first communication node and the second communication node are different nodes within the same communication network. However, the first and second nodes are not fixed; each communication node can play different roles in different communication scenarios. Specifically, when a communication node initiates a communication request, it is considered the first communication node; and when the node receives a communication request from another node, it acts as the second communication node. This means that the identity of a communication node dynamically changes in different communication processes, depending on whether it is the initiator or the receiver at a specific moment.

[0023] In this embodiment, as Figure 2 As shown, when two communication nodes communicate with each other, the communication method includes the following steps:

[0024] S01. The first communication node generates the first Vimcall based on the request data.

[0025] Furthermore, the request data in step S01 refers to the demand information contained by the first communication node when initiating the communication request, which typically includes, but is not limited to, the operation type requested, the required parameters, the target node information, and other detailed data related to the execution of the task.

[0026] Specifically, the request data represents the core content of the task initiated by the first communication node, such as the requested operation, the input parameters required for the operation, and information about the target node. For example, if the first communication node requests to execute a vulnerability scanning task, the request data may include information such as the scan target, scan type, and scan configuration. The request data provides the second communication node with clear task requirements, ensuring that the task can be executed accurately according to the requested content, and providing the necessary basis for the generation of subsequent feedback data.

[0027] It should be noted that Vimcall refers to a standardized data packet used for communication in the Codigger system, carrying business data (i.e., task request or feedback data) exchanged between communication nodes. As a communication unit, Vimcall achieves data exchange and task collaboration between nodes through steps such as generation, sending, receiving, and parsing.

[0028] Furthermore, the first Vimcall is a Vimcall data packet generated and sent by the first communication node. This Vimcall contains business data, namely the request or task requirement initiated by the first communication node. Through the first Vimcall, the first communication node transmits information such as the operation it needs to perform, input parameters, and target node to the second communication node. The business data carried in the first Vimcall provides clear task guidance for the second communication node, ensuring that the second communication node can correctly respond and execute the corresponding operation.

[0029] S02, the first communication node sends the first Vimcall to the second communication node through the communication network.

[0030] S03, the second communication node receives the first Vimcall.

[0031] S04. The second communication node parses and extracts the request data from the first Vimcall.

[0032] S05. The second communication node generates feedback data based on the requested data.

[0033] Furthermore, the feedback data in step S05 refers to the response information or processing result generated by the second communication node based on the received request data, which typically includes, but is not limited to, the result of task execution, operation status, calculation output, success or failure indicators, etc.

[0034] Specifically, after the second communication node executes the corresponding task (such as code analysis, vulnerability scanning, etc.) based on the request data transmitted by the first communication node, the feedback data is the execution result or status information of that task. For example, if the first communication node requests code analysis, the feedback data may include the analysis results, discovered vulnerabilities, analysis report, etc. The feedback data provides the first communication node with important information about the task execution status, ensuring effective response and correct execution of the task.

[0035] Furthermore, the second Vimcall is a Vimcall data packet generated by the second communication node and sent back to the first communication node. This Vimcall contains feedback data, namely, task execution results or status information generated by the second communication node based on the received service data (from the first communication node). The feedback data of the second Vimcall may include task execution results, status updates, success or failure indicators, etc. This feedback data provides the first communication node with important information about the task execution status, ensuring effective task response and subsequent processing.

[0036] S06. The second communication node generates a second Vimcall based on the feedback data.

[0037] S07, the second communication node sends the second Vimcall to the first communication node through the communication network.

[0038] S08, the first communication node receives the second Vimcall.

[0039] S09. The first communication node parses and extracts the feedback data from the second Vimcall.

[0040] Furthermore, in one or more other embodiments, any communication node generates a Vimcall, including the following steps:

[0041] S11, The communication node calls the Vimcall function.

[0042] S12. The communication node generates a Vimcall based on the request data or feedback data using the Vimcall function. When the Vimcall function is called by the communication node to generate a Vimcall, the Vimcall function performs the following steps:

[0043] S121. Generate an initial request based on the request data or feedback data;

[0044] S122. Serialize the initial request to generate a standard request;

[0045] S123. Encapsulate the standard request to generate a Vimcall data packet.

[0046] Furthermore, in one or more other embodiments, any communication node calls the Vimcall function to generate a Vimcall, including the following steps:

[0047] The communication node obtains the Vimcall interface, which includes at least transport layer data input items and application layer data input items; the communication node inputs request data based on the Vimcall interface and calls the Vimcall function to generate a Vimcall data packet.

[0048] Furthermore, in one or more other embodiments, any communication node resolving a Vimcall includes the following steps:

[0049] S21. The communication node calls the Vimcall function;

[0050] S22. The communication node parses the Vimcall data packet through the Vimcall function. When the Vimcall function is called by the communication node to parse the Vimcall, the Vimcall function performs the following steps:

[0051] S221. Extract the standard request from the Vimcall data packet;

[0052] S222. Deserialize the standard request to obtain the request data or the feedback data.

[0053] Furthermore, in one or more other embodiments, when any communication node calls the Vimcall function to parse Vimcall, the following steps are also included: outputting the feedback data parsed from Vimcall through the Vimcall interface.

[0054] Furthermore, in any of the above embodiments or in one or more other embodiments, any Vimcall data packet includes at least transport layer data, extension layer data, and application layer data.

[0055] Specifically, transport layer data is used to identify the source and destination nodes of data packets. It includes routing data, such as the destination address, source address, and transport protocol, and is used for the correct forwarding of data packets within the network. Transport layer data ensures that Vimcall packets can be successfully transmitted to the destination node along the predetermined path and can optimize routing based on the real-time network status in multi-hop environments.

[0056] The extension layer data includes at least one type of transmission task management data, which can be used to track packet transmission progress, transmission priority, status updates, retransmission requests, and other information. For example, in the event of packet loss or delay, the extension layer data can trigger a retransmission mechanism or adjust priorities to ensure tasks are executed as required, and can appropriately adjust the processing order of tasks during system load peaks. Through dynamic management of transmission tasks, the extension layer ensures the stability and reliability of data transmission.

[0057] Application layer data is the core component carrying specific business requests or feedback data. It includes request data (such as operation type, input parameters, and task objectives) or feedback data (such as processing results, task status, and error messages). For example, if the first communication node requests to execute a code analysis task, the application layer data will include information such as the target file for code analysis, scan configuration, and relevant parameters. Application layer data ensures that the core task data exchanged between communication nodes can be accurately transmitted and parsed.

[0058] Through this three-layer architecture design, Vimcall packets can be processed more flexibly and efficiently under different network conditions and inter-node collaborations, while also facilitating the expansion and modification of subsequent tasks and supporting system scalability.

[0059] Furthermore, based on the three-layer data packet structure, during the transmission of any Vimcall over the communication network, the communication network performs the following steps based on the Vimcall:

[0060] SA: At the network transport layer, the transport layer data of the Vimcall data packet is parsed, and a routing node in the communication network is selected based on the transport layer data to send the Vimcall data packet to the corresponding communication node.

[0061] Furthermore, the routing nodes selected during the transmission of any Vimcall packet include at least one Mudem node and / or at least one Router node.

[0062] The parsing of transport layer data primarily focuses on the physical and logical transmission paths of the network. It includes information about the destination node, such as the destination address, destination port, and routing policies, and selects the appropriate path for forwarding based on the current network topology. The network transport layer needs to assess network conditions (such as bandwidth and latency) in real time and select the optimal routing node based on these conditions to ensure that data packets are delivered efficiently and without errors to the target communication node.

[0063] In practice, the network transport layer selects the most suitable node in the network for packet forwarding based on routing information. Mudem nodes and Router nodes play a crucial role here. Mudem nodes are mainly responsible for data forwarding within the local network, while Router nodes handle communication forwarding tasks across network segments or networks. Through the collaborative work of Mudem and Router nodes, the system can maintain efficient data transmission in complex network environments, ensuring uninterrupted communication between different subnets or networks.

[0064] SB: At the network function layer, the function layer data of the Vimcall data packet is parsed, and the transmission process of the Vimcall data packet in the network is managed according to the function layer data.

[0065] Specifically, the functional layer data includes, but is not limited to, task scheduling data, network status data, error detection and recovery data, and flow control data.

[0066] Furthermore, task scheduling data is used to determine the priority and scheduling order of data packets. Under high network load, task scheduling data can dynamically adjust the priority of data packets based on the importance and urgency of tasks, as well as resource availability. High-priority tasks will receive faster transmission, ensuring that critical tasks are not delayed due to network congestion. This priority management mechanism can significantly improve system response efficiency when processing data streams in large-scale distributed systems.

[0067] Specifically, the priority weight of any Vimcall data packet during transmission is obtained according to the following calculation model: W Vimcall =α×P Vimcall +β×E Vimcall +γ×R Vimcall Among them, W Vimcall P represents the priority weight of Vimcall packets during transmission. Vimcall R is the priority of Vimcall packets during transmission. Vimcall To ensure the urgency of Vimcall packets during transmission, R i Let α, β, and γ represent the resource requirements of the Vimcall data packet during transmission, with α, β, and γ being the weighting coefficients of task priority, urgency, and resource requirements, respectively.

[0068] Understandably, in this embodiment, the weight of a Vimcall packet during transmission is determined by a combination of three factors: priority, urgency, and resource requirement. Priority reflects the importance of the task, urgency indicates the timeliness of the task, and resource requirement measures the computational resources consumed by the Vimcall packet during transmission. The total priority weight is obtained by weighting these factors together. Furthermore, by adjusting the values ​​of the various coefficients (α, β, γ), the system can flexibly respond to different network loads and task requirements, thereby improving the efficiency and accuracy of task scheduling.

[0069] For example, when network load is high, the priority coefficient α of a task can be increased to ensure the execution of high-priority tasks and prevent low-priority tasks from consuming too many resources. Similarly, when network latency is high, the urgency coefficient β of a task can be increased to ensure that urgent tasks are prioritized and prevent critical tasks from failing to complete on time due to excessive latency. Furthermore, when resource-intensive tasks occur, the system can appropriately adjust the resource requirement coefficient γ to prioritize scheduling tasks with lower resource consumption, preventing high-resource-consuming tasks from consuming too much computing power or bandwidth, leading to delays or resource contention for other tasks.

[0070] Through this dynamic scheduling mechanism, the task scheduling algorithm can effectively improve the system's operating efficiency and stability in a large-scale distributed environment, ensuring that critical tasks can be executed in a timely manner, while rationally allocating network resources to avoid system congestion and delays.

[0071] Furthermore, network status data provides real-time network operation information, such as current network bandwidth utilization, latency, link quality, and node load. This information enables the network to react to changes during data transmission, automatically selecting the optimal transmission path and avoiding data packet transmission under conditions of network congestion or poor link quality, thereby improving the stability and reliability of data transmission.

[0072] Specifically, the transmission path of any Vimcall data packet is determined by path cost; furthermore, path cost is determined by a comprehensive evaluation of bandwidth, latency, and link quality. Among them, C S Let S be the path cost of link S, B be the real-time network bandwidth, D be the real-time network latency, L be the packet loss rate of link S (ranging from 0 to 1), and F be the node load, representing the utilization of node resources. S F represents the total load of nodes in link S, and s represents the number of nodes in link S.

[0073] Furthermore, once the cost of each candidate path is calculated, the system sorts them according to the magnitude of the path cost and selects the path with the lowest cost as the transmission route for the data packet.

[0074] Specifically, the system will select the path that provides the lowest transmission cost to ensure efficient transmission of data packets; if the costs of multiple paths are the same or similar, the system can further optimize the selection based on other factors (such as network load, path stability, etc.).

[0075] As we know, path cost is not static; changes in network state will affect path cost, so path selection needs to be updated periodically or in real time.

[0076] Furthermore, if the cost of a certain path increases during transmission due to network issues (such as decreased bandwidth or increased latency), the system will recalculate the cost of all paths and select a new optimal path for data transmission. This dynamic adjustment mechanism helps to cope with changes in the network environment and ensures that the system always selects the best path.

[0077] Furthermore, error detection and recovery are crucial for ensuring data integrity and reliability. The network functional layer monitors data packets in real time for errors during transmission, such as packet loss, corruption, and delays. Once an error is detected, the system triggers an error recovery mechanism, typically including packet retransmission, route reselection, or other recovery methods. This mechanism ensures that data can reliably reach its destination node even when network problems occur, preventing data loss and system interruption.

[0078] Furthermore, flow control data is used to control and regulate data traffic to avoid network congestion. When the load on certain nodes or links in the network is too high, flow control data will dynamically adjust the data transmission rate or priority to prevent network congestion. Through this flow control, the system can optimize bandwidth usage, ensure that data packets are allocated resources on demand, and improve the throughput and response speed of the entire network.

[0079] In the above embodiments, the descriptions of each embodiment have different focuses. For parts that are not described in detail or recorded in a certain embodiment, please refer to the relevant descriptions of other embodiments.

[0080] It should be noted that the above embodiments can be freely combined as needed. The above are merely preferred embodiments of the present invention; it should be observed that those skilled in the art can make several improvements and modifications without departing from the principle 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 communication method applied to a Codigger system, the Codigger system comprising a communication network and several independent communication nodes connected to the communication network, characterized in that, Any two communication nodes are independent of each other and have equal communication capabilities. When any two communication nodes communicate with each other, the following steps are included: The first communication node generates the first Vimcall based on the request data; The first communication node sends the first Vimcall to the second communication node through the communication network; The second communication node receives the first Vimcall; The second communication node parses and extracts the request data from the first Vimcall; The second communication node generates feedback data based on the requested data; The second communication node generates a second Vimcall based on the feedback data; The second communication node sends the second Vimcall to the first communication node through the communication network; The first communication node receives the second Vimcall; The first communication node parses and extracts the feedback data from the second Vimcall; any communication node generates a Vimcall, including the following steps: The communication node calls the Vimcall function; Based on request or feedback data, the communication node generates a Vimcall using the Vimcall function. When the Vimcall function is called by the communication node to generate a Vimcall, the Vimcall function performs the following steps: Based on the request data or feedback data, generate an initial request; serialize the initial request to generate a standard request; encapsulate the standard request to generate a Vimcall data packet; Any Vimcall data packet shall include at least the following three layers of data: Transport layer data, which includes at least routing data; Extended layer data, the extended layer data including at least one type of transmission task management data; Application layer data, which includes request data or feedback data.

2. The communication method applied to the Codigger system according to claim 1, characterized in that, The process of resolving a Vimcall by any communication node includes the following steps: The communication node calls the Vimcall function; The communication node parses the Vimcall data packet using the Vimcall function. When the Vimcall function is called by the communication node to parse the Vimcall, it performs the following steps: Extract the standard request from the Vimcall data packet; The standard request is deserialized to obtain the request data or the feedback data.

3. The communication method applied to the Codigger system according to claim 2, characterized in that, Any communication node generates a Vimcall by calling the Vimcall function, which includes the following steps: The communication node obtains the Vimcall interface, which includes at least transport layer data input items and application layer data input items. The communication node inputs request data based on the Vimcall interface and calls the Vimcall function to generate a Vimcall data packet.

4. The communication method applied to the Codigger system according to claim 3, characterized in that, The process of any communication node calling the Vimcall function to parse Vimcall also includes the following steps: outputting the feedback data parsed from Vimcall through the Vimcall interface.

5. The communication method applied to the Codigger system according to claim 1, characterized in that, During the transmission of any Vimcall over the communication network, the communication network performs the following steps based on the Vimcall: At the network transport layer, the transport layer data of the Vimcall data packet is parsed, and a routing node in the communication network is selected based on the transport layer data to send the Vimcall data packet to the corresponding communication node.

6. The communication method applied to the Codigger system according to claim 5, characterized in that, Any Vimcall packet selects at least one Mudem node and / or at least one Router node during transmission.

7. The communication method applied to the Codigger system according to claim 1, characterized in that, During the transmission of any Vimcall over the communication network, the communication network, based on the Vimcall, further performs the following steps: At the network function layer, the function layer data of the Vimcall data packet is parsed, and the transmission process of the Vimcall data packet in the network is managed based on the function layer data.

8. The communication method applied to the Codigger system according to claim 7, characterized in that, The functional layer data includes, but is not limited to, task scheduling data, network status data, error detection and recovery data, and flow control data.

Citation Information

Patent Citations

  • Data packet processing method and device, storage medium and electronic equipment

    CN118590345A

  • Multi-space programming method for application development

    CN118885172A