Communication method applied to Codiger system

Abstract

The invention relates to the technical field of communication, in particular to a communication method applied to a Codiger system. According to the communication method applied to the Codiger system, the Codiger system is composed of a communication network and a plurality of independent communication nodes connected with the communication network, and when any two communication nodes communicate, the communication method comprises the following steps that 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 a 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 a 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.

Description

Technical Field

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

[0002] The traditional remote procedure call (RPC) model typically adopts a client-server architecture, requiring a clear division of roles: the client is responsible for initiating requests, while the server is responsible for responding. This model increases the complexity of system design. This is particularly true in scenarios with a large number of nodes and high system reliability and scalability requirements, as traditional RPC communication methods struggle to meet these requirements. Furthermore, the traditional RPC communication model requires developers to manually write stubs and proxies, which not only increases development and maintenance workload but also increases the complexity and maintenance costs of RPC calls as the system scales, hindering rapid development and efficient expansion. Summary of the Invention

[0003] The present invention provides a communication method for a Codigger system, aiming to provide a simplified solution based on a point-to-point communication model, thereby reducing the development and maintenance burden caused by role division, complex client-server architecture, and manual writing of stub programs 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 provided by the present invention, a communication method for a Codigger system comprises a communication network and a plurality of independent communication nodes connected to the communication network. When any two communication nodes communicate with each other, the method comprises the following steps: 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 via 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 via 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 of traditional RPC communication. Through a decentralized point-to-point communication model, the system's reliability and fault tolerance are improved, while also enhancing the system's scalability in large-scale distributed environments. 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, the present invention supports dynamic feedback and flexible data processing, effectively improving the system's real-time performance and business adaptability.

[0005] In this embodiment or some other embodiments, any communication node generates a Vimcall, including the following steps: the communication node calls a Vimcall function; the communication node generates a Vimcall through the Vimcall function based on request data or feedback data. 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. The present 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 the request data or feedback data by calling the Vimcall function, avoiding the tedious manual coding of stub 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. By encapsulating standardized requests and data packets, the efficiency and accuracy of data transmission are guaranteed, and the stability and reliability of inter-node communication are improved. At the same time, the use of the Vimcall mechanism enhances the scalability of the system, allowing nodes to quickly adapt to different business needs, and supports flexible data processing and feedback generation, further optimizing the system's response speed and real-time performance.

[0006] In this embodiment or some other embodiments, any communication node parses a Vimcall packet, including the following steps: the communication node calls a Vimcall function; the communication node parses a Vimcall packet using the Vimcall function. When the Vimcall function is called by the communication node to parse the Vimcall packet, the Vimcall function performs the following steps: extracting the standard request from the Vimcall packet; and deserializing the standard request to obtain the request data or the feedback data. By introducing the parsing mechanism of the Vimcall function, the present invention simplifies the processing of Vimcall packets by the communication node. The communication node parses the packet using the Vimcall function, extracts the standard request, and deserializes it to obtain the request data or the feedback data. This process reduces reliance on complex parsing logic and improves data processing efficiency and accuracy. Furthermore, the standardized parsing of the Vimcall function ensures data compatibility and consistency across 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 some other embodiments, any communication node calls the Vimcall function to generate a Vimcall, including the following steps: the communication node obtains a Vimcall interface, wherein the Vimcall interface includes at least a transport layer data input item and an application layer data input item; the communication node inputs request data based on the Vimcall interface and calls the Vimcall function to generate a Vimcall data packet. The present invention simplifies the process of generating Vimcall data packets by communication nodes by introducing the Vimcall function interface. By obtaining the Vimcall interface, transport layer data, and application layer data items, the node flexibly inputs request data to generate a Vimcall data packet. This method reduces the need to manually write complex code and improves development efficiency. Through the standardized Vimcall interface, nodes can efficiently and accurately generate data packets that meet specifications, ensuring data compatibility and consistency among communication nodes in the system. In addition, the design of the Vimcall interface enables nodes to quickly adapt to different business needs, enhances the scalability and flexibility of the system, and improves the performance of the entire system.

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

[0009] In this or other embodiments, any of the Vimcall packets includes at least three layers of data: transport layer data, including at least routing data; extension layer data, including at least one type of transmission task management data; and application layer data, including request data or feedback data. By designing a three-layered Vimcall packet, the present invention optimizes the data transmission process, helps improve data transmission efficiency, and thereby enhances the scalability and reliability of the system in large-scale distributed environments.

[0010] In this embodiment or some 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 according to the transport layer data, a routing node in the communication network is selected to send the Vimcall data packet to the corresponding communication node. The present invention optimizes the routing and forwarding process of the data packet by parsing the transport layer data of the Vimcall data packet at the transport layer of the communication network. During the transmission of the data packet, the network dynamically selects the most appropriate routing node according to the transport layer data to ensure that the data packet can be accurately and quickly transmitted 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 best path, enhance the system's adaptability and reliability, and ensure stable data transmission, especially in large-scale distributed environments.

[0011] In this embodiment or some 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. The present invention further optimizes the data routing and forwarding mechanism by introducing Mudem nodes and Router nodes during the transmission of Vimcall data packets. Mudem nodes are mainly responsible for data forwarding in local networks, while Router nodes are responsible for routing across networks or subnets. This design enhances the flexibility and transmission efficiency of data packets, improves the fault tolerance and scalability of the system, ensures that Vimcall data packets can reach the target node quickly and accurately in complex network environments, and optimizes the performance of the system in large-scale distributed networks.

[0012] In this or other embodiments, during the transmission of any Vimcall over a communication network, the communication network, based on the Vimcall, further performs the following steps: parsing the functional layer data of the Vimcall packet at the network functional layer, and managing the transmission of the Vimcall packet over the network based on the functional layer data. By parsing the functional layer data of the Vimcall packet at the network functional layer and then monitoring and adjusting the transmission status of the Vimcall packet over the network in real time based on the functional layer data, the present invention further enhances the flexibility and management capabilities of the data transmission process.

[0013] In this embodiment or some 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. The present 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. BRIEF DESCRIPTION OF THE DRAWINGS

[0014] Figure 1 A schematic diagram of the Codigger system structure provided by an embodiment of the present invention;

[0015] Figure 2 This is a flow chart of the communication method applied to the Codigger system provided by the present invention. DETAILED DESCRIPTION

[0016] In the following description, for the purpose of explanation rather than limitation, specific details such as particular systems, structures, and technologies are set forth to provide a thorough understanding of the embodiments of the present application.

[0017] It should be apparent to those skilled in the art that the present application can 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 are omitted to avoid obstructing the description of this application with unnecessary details; in addition, the terms "first", "second", etc. are only used to distinguish the description and cannot be understood as indicating or implying relative importance.

[0019] Based on the shortcomings of the traditional remote procedure call (RPC) model applied to existing distributed systems, the present 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 programs 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 the present invention is a distributed operating system, which is mainly used to provide security vulnerability detection and code analysis services to users; however, in other application scenarios, the Codigger system described in the present invention can be understood as a distributed operating system that provides the same services or different services as the present invention.

[0021] In one embodiment, see Figure 1 , Figure 1 This is a schematic diagram of the Codigger system structure provided by 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 serve as an independent computing unit, does not rely on other nodes when performing tasks, and can exchange data with each other and collaborate to complete more complex tasks.

[0022] Further, see Figure 2 , Figure 2 This is a flow chart of the communication method applied to the Codigger system provided by the present invention; it should be noted that, in the communication method, the first communication node and the second communication node are different nodes in the same communication network. However, the first node and the second node are not fixed, and each communication node can play different roles in different communication scenarios. Specifically, when a communication node initiates a communication request, it is regarded as 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 the communication node changes dynamically in different communication processes, depending on whether it is the initiator or the receiver at a specific moment.

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

[0024] S01. A first communication node generates a first Vimcall based on request data.

[0025] Furthermore, the request data in step S01 refers to the demand information included by the first communication node when initiating a communication request, which generally includes but is not limited to the requested operation type, required parameters, 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 required input parameters, and information about the target node. For example, if the first communication node requests a vulnerability scan, the request data might 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 is accurately executed according to the request and providing the necessary basis for subsequent feedback data generation.

[0027] It should be noted that Vimcall refers to a standardized data packet used for communication within the Codigger system, carrying business data (i.e., task requests or feedback data) exchanged between communication nodes. As a communication unit, Vimcall implements data exchange and task collaboration between nodes through steps such as generation, transmission, reception, 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 required operation, input parameters, and target node to the second communication node. The business data carried in the first Vimcall provides the second communication node with clear task guidance, 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 in the first Vimcall.

[0032] S05. The second communication node generates feedback data according to the request data.

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

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

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

[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 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 the feedback data through the Vimcall function. When the Vimcall function is called by the communication node to generate the Vimcall, the Vimcall function executes 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 and 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 a Vimcall interface, which includes at least a transport layer data input item and an application layer data input item; the communication node inputs request data based on the Vimcall interface, and calls a Vimcall function to generate a Vimcall data packet.

[0048] Furthermore, in one or more other embodiments, any communication node parses Vimcall, including 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. Extracting 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 some other embodiments, any communication node calls the Vimcall function to parse the Vimcall, further comprising the following step: outputting feedback data parsed from the Vimcall through the Vimcall interface.

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

[0055] Specifically, transport layer data identifies the source and destination nodes of a data packet and includes routing data, including the destination address, source address, and transport protocol, for the correct forwarding of data packets within the network. This data ensures that Vimcall data packets are successfully transmitted to their destination nodes along the predetermined path, and in multi-hop environments, routes can be optimized based on the network's real-time status.

[0056] 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, extension layer data can trigger retransmission mechanisms or adjust priorities to ensure that tasks are executed as required. It can also appropriately adjust the processing order of tasks during peak system loads. By dynamically managing transmission tasks, the extension layer ensures stable and reliable data transmission.

[0057] Application layer data is the core component that carries specific business requests or feedback data. It contains request data (such as operation type, input parameters, task objectives) or feedback data (such as processing results, task status, error information, etc.). For example, if the first communication node requests to perform a code analysis task, the application layer data will include information such as the target file for code analysis, scanning configuration, and related 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 structure design, Vimcall data packets can provide more flexible and efficient processing in different network conditions and inter-node collaboration, while also facilitating the expansion and modification of subsequent tasks and supporting the scalability of the system.

[0059] Furthermore, based on the three-layer structure of the data packet, during the transmission of any Vimcall in 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 according to the transport layer data, a routing node in the communication network is selected to send the Vimcall data packet to the corresponding communication node.

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

[0062] Transport layer data analysis focuses on the network's physical and logical transmission paths. This includes information about the destination node, such as the destination address, destination port, and routing policy, and selects the appropriate path for forwarding based on the current network topology. The transport layer assesses network conditions (such as bandwidth and latency) in real time and selects the optimal routing node based on these conditions to ensure efficient and accurate delivery of data packets to their target communication nodes.

[0063] In practice, the network transport layer selects the most appropriate node within the network to forward data packets based on routing information. Mudem nodes and router nodes play a key role in this. Mudem nodes primarily forward data within a local network, while router nodes forward communications across network segments or networks. Through the collaborative work of Mudem and router nodes, the system maintains efficient data transmission in complex network environments, ensuring unimpeded communication between different subnets or networks.

[0064] SB: At the network function layer, parse the function layer data of the Vimcall data packet, and manage the transmission process of the Vimcall data packet in the network 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 dispatch 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 the task, as well as resource availability. High-priority tasks receive faster transmission, ensuring that critical tasks are not delayed due to network congestion. This priority management mechanism can significantly improve system responsiveness 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: Vimcall =α×P Vimcall +β×E Vimcall +γ×R Vimcall , where W Vimcall is the priority weight of the Vimcall data packet during transmission, P Vimcall is the priority of the Vimcall data packet during transmission, R Vimcall The urgency of the Vimcall data packet during transmission, R i is the resource requirement of the Vimcall data packet during transmission, and α, β, and γ are the weight coefficients of task priority, urgency, and resource requirement, respectively.

[0068] It is understood that in this embodiment, the weight of a Vimcall packet during transmission is determined by a combination of three factors: priority, urgency, and resource requirements. Priority reflects the importance of the task, urgency indicates the timeliness of the task, and resource requirements measure the computing resource consumption of the Vimcall packet during transmission. The total priority weight is calculated by weighting these factors. Furthermore, by adjusting the size of each coefficient (α, β, γ), it can flexibly respond to different network loads and task requirements, thereby improving the efficiency and accuracy of task scheduling.

[0069] For example, when the network load is high, the priority coefficient α of the task can be increased to ensure the execution of high-priority tasks and prevent low-priority tasks from occupying too many resources; for example, when the network delay is large, the urgency coefficient β of the task can be increased to ensure that urgent tasks are given priority and avoid critical tasks from being unable to be completed on time due to excessive delay; for example, when tasks with high resource requirements appear, the system can give priority to scheduling those tasks with low resource consumption by appropriately adjusting the resource requirement coefficient γ to avoid high-resource-consuming tasks occupying too much computing power or bandwidth, causing delays or resource competition for other tasks.

[0070] Through this dynamic scheduling mechanism, the task scheduling algorithm can effectively improve the operating efficiency and stability of the system in a large-scale distributed environment, ensure that key tasks can be executed in a timely manner, and at the same time reasonably allocate network resources to avoid system congestion and delays.

[0071] Furthermore, network status data is used to provide real-time network operation information, such as current network bandwidth utilization, latency, link quality, and node load. This information enables the network to respond to changes in the data transmission process, automatically selecting the optimal transmission path and avoiding data packet transmission in situations of network congestion or poor link quality, thereby improving the stability and reliability of data transmission.

[0072] Specifically, the transmission path of any Vimcall packet is determined by the path cost. Furthermore, the path cost is determined by a comprehensive evaluation of bandwidth, latency, and link quality: Among them, C S is the path cost of a link S, B is the real-time bandwidth of the network, D is the real-time delay of the network, L is the packet loss rate of link S, ranging from 0 to 1, F is the node load, which indicates the degree of 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 will sort the paths according to their cost and select 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] It is known that the path cost is not static and changes in network status will affect the path cost, so the path selection needs to be updated regularly or in real time.

[0076] Furthermore, if a particular path's cost increases during transmission due to network issues (such as decreased bandwidth or increased latency), the system recalculates the costs of all paths and selects the new optimal path for data transmission. This dynamic adjustment mechanism helps adapt to changing network conditions and ensures that the system always selects the optimal path.

[0077] Furthermore, error detection and recovery are key to ensuring data integrity and reliability. The network function layer monitors data packets for errors during transmission, such as packet loss, corruption, and delays. Once an error is detected, the system triggers an error recovery mechanism, typically involving packet retransmission, rerouting, or other recovery measures. This mechanism ensures that data reliably reaches its destination node even in the event of network problems, avoiding data loss and system interruption.

[0078] Furthermore, flow control data is used to control and regulate data flow to avoid network congestion. When certain nodes or links in the network are overloaded, flow control data dynamically adjusts the rate or priority of data transmission to prevent network congestion. Through this flow control, the system optimizes bandwidth usage, ensuring that data packets are allocated resources according to demand, and improving overall network throughput and responsiveness.

[0079] In the above embodiments, the description of each embodiment has its own focus. For parts that are not described or recorded in detail in a certain embodiment, reference can be made to the relevant description of other embodiments.

[0080] It should be noted that the above embodiments can be freely combined as needed. The above are only preferred embodiments of the present invention; it should be noted that those skilled in the art can make several improvements and modifications without departing from the principles of the present invention, and such 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, wherein the Codigger system comprises a communication network and a plurality of independent communication nodes connected to the communication network, characterized in that: When any two communication nodes communicate with each other, the following steps are included: The first communication node generates a 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 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; The first communication node parses and extracts feedback data from the second Vimcall.

2. The communication method applied to the Codigger system according to claim 1, characterized in that: Any communication node generates a Vimcall, including the following steps: The communication node calls the Vimcall function; The communication node generates a Vimcall based on the request data or feedback data through the Vimcall function. When the Vimcall function is called by the communication node to generate the Vimcall, the Vimcall function performs the following steps: Based on the request data or feedback data, an initial request is generated; the initial request is serialized to generate a standard request; and the standard request is encapsulated to generate a Vimcall data packet.

3. The communication method applied to the Codigger system according to claim 2, characterized in that: Any communication node parses Vimcall, including the following steps: The communication node calls the Vimcall function; 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: Extracting the standard request from the Vimcall data packet; Deserialize the standard request to obtain the request data or the feedback data.

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

5. The communication method applied to the Codigger system according to claim 4, characterized in that: Any communication node calls the Vimcall function to parse the Vimcall, further comprising the following steps: outputting feedback data parsed from the Vimcall through the Vimcall interface.

6. The communication method applied to the Codigger system according to claim 3, characterized in that: Any of the above Vimcall data packets includes at least the following three layers of data: Transport layer data, the transport layer data including at least routing data; Extension layer data, the extension layer data including at least one transmission task management data; Application layer data, where the application layer data includes request data or feedback data.

7. The communication method applied to the Codigger system according to claim 6, characterized in that: 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 according to the transport layer data, a routing node in the communication network is selected to send the Vimcall data packet to the corresponding communication node.

8. The communication method applied to the Codigger system according to claim 7, characterized in that: The routing nodes selected by any Vimcall data packet during transmission include at least one Mudem node and / or at least one RouterRouter node.

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

10. The communication method applied to the Codigger system according to claim 6, 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.

Images