Cross-domain communication simulation system supporting dynamic loading of multiple protocols and secondary development

Abstract

This invention discloses a cross-domain communication simulation system supporting dynamic loading and secondary development of multiple protocols, belonging to the field of communication protocol system simulation technology. It includes a core engine layer responsible for underlying scheduling and resource management; a protocol interface specification layer that unifies interfaces and data format specifications through pure virtual classes in programming languages; a protocol plugin layer providing pre-built protocol plugins and custom protocol plugins; a dynamic loading engine layer implementing hot loading and version management of plugins; a security verification layer ensuring plugin compatibility and stability through static and dynamic testing; and a secondary development and teaching layer providing development tools and teaching demonstration support. The protocol development and loading process connects each layer, forming a closed-loop management system covering the entire process from development, verification, configuration, loading to analysis. This invention achieves closed-loop management of the entire process from protocol development, verification and registration, simulation configuration to dynamic loading and teaching analysis, effectively supporting flexible simulation of cross-domain heterogeneous networks, rapid protocol iteration, and teaching research.

Description

Technical Field

[0001] This invention belongs to the field of communication protocol system simulation technology, specifically relating to a cross-domain communication simulation system that supports dynamic loading and secondary development of multiple protocols. Background Technology

[0002] In cross-domain communication systems, such as underwater acoustic communication and surface electromagnetic communication, the channel characteristics differ significantly. Underwater acoustic channels are limited by high latency, narrow bandwidth, and multipath effects, with communication rates typically not exceeding 10 kbps, and are easily affected by environmental noise. In contrast, surface electromagnetic communication (such as Wi-Fi and cellular networks) features high bandwidth and low latency, with communication rates generally exceeding 100 kbps. To adapt to these different channel characteristics, existing technologies typically design dedicated communication protocols for underwater and surface scenarios. For example, underwater communication often employs time division multiple access (TDMA)-based anti-interference protocols to cope with high latency and low data rate environments; surface communication often uses carrier sense multiple access / collision avoidance (CSMA / CA)-based flexible access protocols to improve channel utilization efficiency. However, existing cross-domain communication simulation systems have the following key shortcomings in protocol design, system integration, and educational applications:

[0003] High protocol coupling: The protocol logic of the existing simulation system is deeply coupled with the core simulation code, resulting in poor protocol scalability. When it is necessary to add or modify the communication protocol, developers must directly modify the underlying source code of the simulation engine, which not only increases the development cycle but also easily introduces system compatibility issues, seriously hindering the rapid iteration and verification of cross-domain communication protocols.

[0004] Insufficient cross-domain adaptability: Due to the lack of a unified protocol interface specification, underwater and surface communication protocols have significant differences in parameter format, time slot unit, routing metric, etc., making cross-domain collaborative simulation difficult to achieve and not directly compatible, and thus unable to be performed directly.

[0005] Lack of Development Tools: The secondary development interfaces of existing simulation platforms are complex, requiring developers to have in-depth knowledge of the underlying logic of the simulation engine (such as the ns3::Packet class of NS-3, event scheduling mechanisms, etc.), resulting in a high learning curve. Furthermore, existing platforms lack dedicated debugging and analysis tools for specific needs in cross-domain communication scenarios (such as multi-channel protocol conflict localization and cross-layer parameter adjustment). When verifying protocol performance, developers often need to manually write log parsing scripts, which is inefficient and prone to errors.

[0006] Teaching verification is difficult: the protocol operation process is not visible (such as routing table updates and conflict backoff mechanisms), making it difficult for students to understand the abstract logic; the performance evaluation of custom protocols requires manual log analysis, which is inefficient.

[0007] Difficulties in teaching and verification: In the process of teaching communication protocols, students find it difficult to intuitively understand the operating mechanisms of the protocols (such as routing table updates and conflict backoff processes) because existing simulation systems usually output results in the form of command lines or text logs, lacking dynamic visualization capabilities. In addition, the performance evaluation of student-defined protocols relies on manually analyzing large amounts of simulation data, making it impossible to quickly obtain intuitive comparison results, thus reducing teaching efficiency and learning effectiveness.

[0008] Therefore, there is an urgent need for a system with loosely coupled protocol design, standardized cross-domain interfaces, integrated development tools, and professional teaching functions to meet the needs of rapid iteration of cross-domain communication protocols and teaching demonstrations. Summary of the Invention

[0009] To address the shortcomings of existing technologies, this invention aims to propose a cross-domain communication simulation system that supports dynamic loading and secondary development of multiple protocols. This architecture encompasses six layers: a core engine, protocol interface specifications, protocol plugins, a dynamic loading engine, security verification, secondary development, and teaching, forming a closed-loop development and loading process. The core engine provides scheduling, channel models, and resource monitoring; the interface specifications unify protocol development standards; the plugin layer includes five pre-built protocols and custom plugins; dynamic loading enables hot loading of plugins and version dependency management; security verification ensures stability through static and dynamic mechanisms; and the secondary development and teaching layer provides tools and demonstration support. The process seamlessly connects each layer, achieving a closed loop for protocol development, verification, configuration, loading, and analysis. Overall, it supports dynamic loading and secondary development of multiple protocols, adapts to heterogeneous cross-domain networks, ensures stable and efficient simulation, and possesses both practical development and educational value.

[0010] The technical solution adopted in this invention:

[0011] A cross-domain communication simulation system supporting dynamic loading and secondary development of multiple protocols includes the following steps:

[0012] Core engine layer: By building a discrete event scheduler, constructing a cross-domain channel model, and deploying a resource monitoring module, it provides underlying services and resource management for simulation tasks;

[0013] Protocol Interface Specification Layer: Based on the underlying services provided by the core engine layer, cross-domain protocol interfaces are defined through pure virtual classes in programming languages. This layer unifies protocol parameters, message structures, data format specifications, and cross-domain adaptation rules to achieve standardization, compatibility, and adaptive communication across heterogeneous networks for protocol plugins.

[0014] Protocol Plug-in Layer: Following the interfaces and specifications defined in the protocol interface specification layer, pre-built protocol plug-ins and custom protocol plug-ins are constructed. The pre-built protocol plug-ins include 5 commonly used cross-domain protocol plug-ins. The custom protocol plug-ins are generated using a dedicated compilation tool based on the protocol interfaces and specifications to realize the pluggable encapsulation of protocols.

[0015] Dynamic loading engine layer: interacts with the protocol plugin layer, scans the directory and parses the protocol plugin type at startup, realizes uninterrupted hot loading / unloading through dynamic link library technology, supports multi-version protocol compatibility, automatically checks the dependencies of all protocol plugins and reports missing errors, and is used to manage the life cycle of protocol plugins.

[0016] Security Verification Layer: Verifies all protocol plugins in the protocol plugin layer. In cross-domain communication scenarios, it calculates protocol plugin performance metrics to ensure the compatibility and stability of the protocol plugins. The verification includes a static verification mechanism and a dynamic sandbox testing mechanism. The static verification mechanism checks interface compliance through abstract syntax tree analysis, and verifies message format and parameter range. The mechanism restricts resource usage and monitors for anomalies.

[0017] Secondary Development and Teaching Layer: Provides development and teaching support for the protocol plugin layer and protocol interface specification layer, including a development kit and a teaching demonstration module. The development kit assists in protocol development through a protocol template generator, a visual editor, and debugging tools. The teaching demonstration module demonstrates operations such as protocol state machine visualization, performance comparison analysis, and error case library demonstration.

[0018] Protocol Development and Loading Process: Provides an integrated protocol development and loading process, connecting various layers; generates protocol plugins through compilation; then registers them to the protocol plugin library after verification by the security verification layer, and configures simulation scenarios and protocol parameters; dynamically loads protocol plugins to participate in simulation at startup; finally, the teaching demonstration module of the secondary development and teaching layer generates status diagrams, indicator curves, and comparison reports.

[0019] Preferably, the core engine layer is as follows:

[0020] The core engine layer includes a discrete event scheduler, a cross-domain channel model, and a resource monitoring module, as detailed below:

[0021] Discrete event scheduler: Employs a priority queue-based event management mechanism to manage simulation events. All simulation events are sorted and managed according to a predetermined timestamp, with a simulation time precision of 1 millisecond. Supports all protocol plugins registering events and callback functions to themselves. The scheduler controls the entire processing delay from event triggering to the start of execution of the corresponding callback function to not exceed 10 milliseconds.

[0022] Cross-domain channel model: Integrates and unifies the management of underwater acoustic propagation delay model and surface electromagnetic propagation loss model, as detailed below:

[0023] The underwater sound propagation time delay model is used to calculate the propagation time delay of underwater sound signals. Its calculation formula is as follows:

[0024] ,

[0025] In the formula, The propagation delay is measured in seconds. The distance is in meters; The speed of sound is expressed in meters per second. ; For temperature; Salinity;

[0026] The electromagnetic propagation loss model for water surface is used to calculate the path loss of electromagnetic signals on the water surface. The calculation formula is as follows:

[0027] ,

[0028] in, Path loss, in decibels; The signal frequency is expressed in Hertz (Hz). The distance is in meters;

[0029] The resource monitoring module includes a central processing unit (CPU), a memory monitoring unit, and a network input / output monitoring unit. It monitors resource consumption during the simulation process in real time and implements a protective rate-limiting mechanism. When the resource consumption of any protocol plugin exceeds a preset threshold, the rate-limiting mechanism is triggered, reducing the event scheduling priority of the corresponding protocol plugin or suspending some of its tasks. The CPU monitors CPU utilization at a sampling period of 100 milliseconds. The memory monitoring unit monitors memory usage at a monitoring precision of 1 megabyte. The network input / output monitoring unit monitors network I / O usage.

[0030] Preferably, the protocol interface specification layer is based on the underlying services provided by the core engine layer and provides interfaces and specifications for the protocol plugin layer, as follows:

[0031] The protocol interface specification layer includes defining abstract protocol interfaces, unified data format specifications, and establishing cross-domain adaptation rules, specifically including:

[0032] Define an abstract protocol interface: Define the protocol interface for the protocol plugins using pure virtual classes in the programming language. This forces all protocol plugins to implement the declared methods; otherwise, compilation will fail. The process of forcing all protocol plugins to implement the required methods is described in code as follows:

[0033] class CrossDomainProtocol { / / Define a class named CrossDomainProtocol

[0034] public:

[0035] / / Initialize protocol parameters (such as time slot length, routing period)

[0036] virtual void Initialize(const ProtocolParam& param) = 0;

[0037] / / Message encapsulation (add protocol header: type, length, checksum)

[0038] virtual Packet Encode(const Payload& data, const NodeType& src_type) = 0;

[0039] / / Message parsing (extracting the payload and verifying header validity)

[0040] virtual Payload Decode(const Packet& pkt, const NodeType& dest_type) = 0;

[0041] / / Routing decision (returns a list of next-hop nodes, supporting cross-domain relay selection)

[0042] virtual vector <nodeid>GetNextHops(const NodeId& dest, constChannelType& channel) = 0;

[0043] / / Performance statistics (returns metrics such as throughput and latency)

[0044] virtual ProtocolStats GetStatistics() const = 0;

[0045] };

[0046] Unified data format specification: The data format is uniformly set; the data includes protocol parameters, network packets, and statistical data. The protocol parameters are defined and stored in XML format; the network packets are transmitted as binary streams on the line, with a fixed 16-byte header followed by a variable-length payload; the statistical data are output in JSON format.

[0047] Establish cross-domain adaptation rules: adopt a protocol conversion mechanism to overcome the heterogeneity between underwater acoustic networks and surface electromagnetic networks.

[0048] Preferably, the protocol plugin layer includes pre-built protocol plugins and custom protocol plugins, conforming to the interfaces and specifications defined by the protocol interface specification layer, and providing loadable protocol plugins for the dynamic loading engine layer, specifically as follows: Pre-built protocol plugins: integrating five commonly used cross-domain protocol plugins, encapsulated into independent modules according to interface specifications, including underwater MAC protocol plugins, surface MAC protocol plugins, and cross-domain routing protocol plugins; the underwater MAC protocol plugins include TDMA protocol plugins and ALOHA protocol plugins; the surface MAC protocol plugins are CSMA / CA protocol plugins; the cross-domain routing protocol plugins include AODV protocol plugins and DSDV protocol plugins;

[0049] Custom protocol plugins: Based on interfaces and specifications, the protocol logic is implemented, compiled and packaged using dedicated compilation tools, and the required methods declared in the protocol interface specification layer are implemented to generate .plugin format protocol plugins that are easy to identify and load;

[0050] All protocol plugins include binary executable code, description files, and dependency libraries.

[0051] Preferably, the dynamic loading engine layer includes plugin discovery and parsing, hot loading / unloading, version and dependency management, and is responsible for the lifecycle management of all protocol plugins in the protocol plugin layer. It also works with the security verification layer to ensure the secure loading of all protocol plugins. Specifically, the plugin discovery and parsing is as follows: At startup, the specified protocol plugin directory is scanned, all protocol plugin files in the protocol plugin directory are identified, and the protocol type is identified by reading the description file in each protocol plugin. The time taken from the start of scanning to the completion of parsing all protocol plugins is controlled to be ≤500ms.

[0052] Hot loading / unloading: Dynamic link library technology is used to implement runtime loading using corresponding file formats on different platforms. During loading, the binary executable code of all protocol plugins is mapped into the memory space through the dlopen() function. During unloading, the memory resources occupied by all protocol plugins are released through dlclose(). The entire loading / unloading operation takes ≤100ms and does not interrupt the simulation.

[0053] Version and dependency management: Supports the coexistence of different versions of the same protocol, and controls compatibility through semantic version number naming; automatically checks the required dependencies in all protocol plugins, and immediately returns ERROR_DEPENDENCY_MISSING when the missing dependency is detected, and prevents the loading of the corresponding protocol plugin.

[0054] Preferably, the security verification layer includes a static verification mechanism and a dynamic sandbox testing mechanism. Before the dynamic loading engine layer performs the loading operation, all protocol plugins in the protocol plugin layer are verified, as follows:

[0055] 1) Static verification mechanism: The static verification mechanism includes interface compliance checks and format validation;

[0056] Interface compliance check: Analyze the binary executable code of any protocol plugin through the abstract syntax tree and verify whether it fully implements the required methods declared in the CrossDomainProtocol interface. If the required methods are found to be missing, mark the protocol plugin in the INVALID_INTERFACE state to prevent it from loading.

[0057] Format validation: Check whether the header of all network packets generated by all protocol plugins contains a checksum field, and verify whether the configuration parameter range of all protocol plugins conforms to the preset specifications; avoid protocol plugins using non-standard formats / parameters, which may lead to incompatibility between protocol plugins or simulation logic errors.

[0058] 2) Dynamic sandbox testing mechanism

[0059] The dynamic sandbox testing mechanism includes resource isolation, anomaly monitoring, and performance benchmark testing;

[0060] Resource isolation: Allocate an independent process to each protocol plugin and limit the resource usage of the protocol plugin, including limiting CPU usage to ≤20%, memory usage to ≤512MB, and network I / O to ≤1Mbps;

[0061] Anomaly monitoring: Real-time monitoring of the operation of any protocol plugin. If any of the following anomalies occur, the corresponding protocol plugin will be automatically terminated and logged: The anomalies include crashes, deadlocks, and memory leaks during the operation of the protocol plugin.

[0062] Performance benchmarking: In a standard cross-domain communication scenario, performance metrics for all protocol plugins are calculated. These metrics include throughput, average latency, and packet loss rate, and the calculation formulas are as follows:

[0063] ,

[0064] ,

[0065] .

[0066] Preferably, the secondary development and teaching layer includes a development kit and a teaching demonstration module, utilizing all protocol plugins provided by the protocol plugin layer to provide development and teaching support, as detailed below:

[0067] 1) Development Kit:

[0068] The development kit includes a protocol template generator, a visual editor, and debugging tools;

[0069] Protocol Template Generator: Automatically generates code files that conform to the CrossDomainProtocol protocol interface standard skeleton based on the protocol type;

[0070] Visual editor: Build protocol logic by dragging and dropping protocol components, and automatically convert it into code that conforms to the protocol interface and specifications;

[0071] Debugging tools: Real-time printing of protocol running status, visual display of message flow path, and support for breakpoint debugging;

[0072] 2) Teaching Demonstration Module:

[0073] The teaching demonstration module includes protocol state machine visualization, performance comparison analysis, and an error case library;

[0074] Protocol state machine visualization: The logic of the GetNextHops() method is converted into a UML state diagram, and the current execution path is dynamically highlighted;

[0075] Performance Comparison Analysis: Multiple protocols are run in the same simulation scenario, generating indicator comparison curves and introducing a protocol compatibility index. And perform weighted calculations;

[0076] Error Case Library: Preset common protocol defects in communication protocols, supports the active injection of specific errors during simulation, observe the resulting fault phenomena and troubleshooting steps.

[0077] Preferably, the protocol development and loading process provides an integrated protocol development and loading process, connecting the core engine layer, protocol interface specification layer, protocol plugin layer, dynamic loading engine layer, security verification layer, and secondary development and teaching layer to form a complete closed-loop management. The closed-loop management is divided into five processes, including plugin development, verification and registration, simulation configuration, dynamic loading, and teaching analysis, as follows:

[0078] Plugin Development: Two parallel development paths are adopted, using a visual editor or a protocol template generator to write code; the visual editor allows users to build protocol logic by dragging and dropping pre-built protocol components, while the protocol template generator automatically generates a code file containing the CrossDomainProtocol interface skeleton, implements the protocol logic, and compiles to generate a .plugin protocol plugin file;

[0079] Verification and Registration: The security verification layer verifies all protocol plugins through static verification and dynamic sandbox testing mechanisms. After verification, all protocol plugins are registered in the protocol plugin library and a unique identity is generated to facilitate finding the protocol plugin in the future.

[0080] Simulation configuration: Select the corresponding protocol plugin according to the simulation scenario requirements; set the specific running parameters for the selected protocol plugin;

[0081] Dynamic loading: During simulation, the dynamic loading engine layer finds the corresponding protocol plugin based on the previously registered ProtocolID and loads it; the core engine layer calls the CrossDomainProtocol interface in the protocol plugin to allow the protocol plugin to participate in the simulation process.

[0082] Instructional Analysis: The instructional module generates the protocol's state diagram and performance index curves in real time; after simulation, it outputs a document containing... The report provides a comparison of performance data for different protocol plugins, facilitating analysis and learning.

[0083] Compared with existing technologies, this invention proposes a cross-domain communication simulation system that supports dynamic loading and secondary development of multiple protocols. The advantages of this method are:

[0084] (1) Improved protocol extension efficiency

[0085] By adopting a pluggable architecture and standardized interface design, the limitations of traditional communication simulation systems, which rely on core code modifications for protocol extensions, have been overcome. Custom protocols can be integrated simply by implementing the main core methods according to the abstract protocol interface specification, reducing the development cycle of new protocols from 72 hours to less than 4 hours. At the same time, due to the mandatory constraints and standardized format of the interfaces, the incidence of compatibility issues during the integration process has been reduced by more than 90%, significantly improving the efficiency of protocol iteration and version management.

[0086] (2) Enhanced cross-domain collaboration capabilities

[0087] In traditional simulation systems, underwater and surface communication protocols struggle to interact directly due to differences in channel models and data formats, resulting in a cross-domain collaborative simulation success rate of less than 30%. By defining unified cross-domain adaptation rules and data format specifications, seamless integration between heterogeneous protocols is achieved, enabling underwater acoustic communication protocols and surface electromagnetic protocols to exchange data and select relays according to rules within the same simulation scenario. Testing shows that in hybrid network scenarios with more than 100 nodes, the protocol interaction success rate remains stable at over 95%, effectively supporting the verification of cross-domain collaborative strategies and the performance evaluation of large-scale heterogeneous networks.

[0088] (3) The development threshold has been significantly reduced.

[0089] Targeting non-professional developers such as students and research beginners, this system provides a complete workflow support tool from protocol design to simulation verification. The visual editor allows users to build protocol logic by dragging and dropping pre-built components (such as time slot allocators and routing decision-makers) and automatically generates code that conforms to the interface specifications. The debugging tool can display the protocol status and message path in real time, supports breakpoint debugging and single-step execution, greatly reducing the difficulty of coding and troubleshooting. With detailed API documentation and sample code, the user's learning cycle is shortened from the original 2 weeks to 1 day, making communication protocol teaching and experiments no longer limited by programming ability, effectively expanding the system's user base and application scenarios.

[0090] (4) Enhanced intuitiveness in teaching

[0091] To enhance the teaching demonstration effect, the system integrates protocol state machine visualization and multi-protocol performance comparison functions. Methods in protocol logic, such as routing decisions and packet encapsulation, can be converted into UML state diagrams, and the execution path is dynamically highlighted during simulation, helping students intuitively understand protocol behavior. The performance comparison and analysis module can run multiple protocols in parallel under the same simulation scenario, drawing comparison curves for metrics such as throughput, latency, and packet loss rate in real time, and calculating the protocol adaptability index to quantitatively evaluate the protocol's performance under different channel conditions. Combined with typical defect scenarios preset in the error case library, students gain a deeper understanding of protocol design and debugging methods through an interactive "fault-troubleshooting" approach, improving comprehension efficiency by over 60%.

[0092] (5) System stability assurance

[0093] By introducing a security verification layer and resource isolation mechanism, system crashes and performance fluctuations caused by plugin anomalies are mitigated. In the static verification phase, syntax tree analysis ensures interface compliance and parameter legality. Dynamic sandbox testing runs plugins in independent processes, strictly limiting their CPU, memory, and network resource usage, and can capture anomalies in real time. The resource monitoring module samples system load at 100ms intervals and automatically triggers rate limiting when plugin resources exceed limits. These mechanisms reduce the system crash rate caused by plugins from 18% to below 1%, ensuring that simulation tasks maintain high reliability and stability even under complex protocol combinations and long-term operation conditions. Attached Figure Description

[0094] Figure 1 This is a schematic diagram of the cross-domain communication simulation system supporting dynamic loading and secondary development of multiple protocols proposed in this invention;

[0095] Figure 2 This is a flowchart illustrating the protocol development and loading process in a specific embodiment of the present invention. Detailed Implementation

[0096] The technical solutions of the embodiments of this application will be further described clearly and completely below with reference to the accompanying drawings. It should be noted that the described embodiments are only some embodiments of this application, and not all embodiments. All other embodiments obtained by those skilled in the art based on the embodiments of this application without creative effort are within the scope of protection of this application.

[0097] To make the inventive objectives, technical solutions, and advantages of this application clearer, the embodiments of this application will be further described in detail below with reference to the accompanying drawings: In order to better understand the above-mentioned objectives, features, and advantages of this invention, the advantages of this invention will be further illustrated below by comparing the embodiments with the accompanying drawings and specific implementation methods.

[0098] This invention proposes a cross-domain communication simulation system that supports dynamic loading of multiple protocols and secondary development, such as... Figure 1 The steps of this method are described in detail below:

[0099] Core engine layer: By building a discrete event scheduler, constructing a cross-domain channel model, and deploying a resource monitoring module, it provides underlying services and resource management for simulation tasks;

[0100] Protocol Interface Specification Layer: Based on the underlying services provided by the core engine layer, the cross-domain protocol interface is defined through pure virtual classes in the C++ programming language. It unifies protocol parameters, message structure, data format specifications, and formulates cross-domain adaptation rules to achieve standardization, compatibility, and adaptive communication of protocol plugins in heterogeneous networks.

[0101] Protocol Plug-in Layer: Following the interfaces and specifications defined in the protocol interface specification layer, pre-built protocol plug-ins and custom protocol plug-ins are constructed. The pre-built protocol plug-ins include 5 commonly used cross-domain protocol plug-ins. The custom protocol plug-ins are generated using a dedicated compilation tool based on the protocol interfaces and specifications to realize the pluggable encapsulation of protocols.

[0102] Dynamic loading engine layer: interacts with the protocol plugin layer, scans the directory and parses the protocol plugin type at startup, realizes uninterrupted hot loading / unloading through dynamic link library technology, supports multi-version protocol compatibility, automatically checks the dependencies of all protocol plugins and reports missing errors, and is used to manage the life cycle of protocol plugins.

[0103] Security Verification Layer: Verifies all protocol plugins in the protocol plugin layer. In cross-domain communication scenarios, it calculates protocol plugin performance metrics to ensure the compatibility and stability of the protocol plugins. The verification includes a static verification mechanism and a dynamic sandbox testing mechanism. The static verification mechanism checks interface compliance through abstract syntax tree analysis, and verifies message format and parameter range. The dynamic sandbox testing mechanism restricts resource usage and monitors for anomalies.

[0104] Secondary Development and Teaching Layer: Provides development and teaching support for the protocol plugin layer and protocol interface specification layer, including a development kit and a teaching demonstration module. The development kit assists in protocol development through a protocol template generator, a visual editor, and debugging tools. The teaching demonstration module demonstrates operations such as protocol state machine visualization, performance comparison analysis, and error case library demonstration.

[0105] Protocol Development and Loading Process: Provides an integrated protocol development and loading process, connecting various layers; adopts two protocol plugin development paths: visual editing or template code; compiles and generates protocol plugins, which are then verified by the security verification layer and registered to the protocol plugin library; configures simulation scenarios and protocol parameters; dynamically loads protocol plugins to participate in simulation at startup; and finally, the teaching demonstration module of the secondary development and teaching layer generates status diagrams, indicator curves, and comparison reports.

[0106] Specifically, the core engine layer includes:

[0107] The core engine layer serves as the runtime foundation for the communication simulation system, providing unified scheduling, computation, and resource management services—in other words, providing underlying support. This includes a discrete event scheduler, a cross-domain channel model, and a resource monitoring module, as detailed below:

[0108] Discrete event scheduler: Employs a priority queue-based event management mechanism to manage simulation events. All simulation events (such as data packet transmission and timer triggering) are sorted and managed according to a predetermined timestamp, with a simulation time precision of 1 millisecond (1ms). It supports all protocol plugins registering events and callback functions to themselves. The scheduler controls the entire processing delay from event triggering to the start of execution of the corresponding callback function to not exceed 10 milliseconds (10ms), ensuring the real-time performance and efficiency of simulation.

[0109] Cross-domain channel model: Integrates and unifies the management of underwater acoustic propagation delay model and surface electromagnetic propagation loss model, respectively realizing the calculation of propagation characteristics of underwater acoustic channel and surface electromagnetic channel; as detailed below:

[0110] The underwater sound propagation time delay model is used to calculate the propagation time delay of underwater sound signals. Its calculation formula is as follows:

[0111] ,

[0112] In the formula, The propagation delay is measured in seconds. ); For distance, the unit is meters (m). ); Speed ​​of sound, measured in meters per second (m / s) ),in ; Temperature, in degrees Celsius (°C); Salinity, unit: ;

[0113] The electromagnetic propagation loss model for water surface is used to calculate the path loss of electromagnetic signals on the water surface. The calculation formula is as follows:

[0114] ,

[0115] in, Path loss, in decibels (dB). ); The signal frequency is expressed in Hertz (Hz). For distance, the unit is meters (m);

[0116] The resource monitoring module includes a central processing unit (CPU), a memory monitoring unit, and a network input / output (IO) monitoring unit. It monitors resource consumption during the simulation process in real time and implements a protective rate-limiting mechanism. When the resource consumption of any protocol plugin exceeds a preset threshold (e.g., CPU utilization consistently exceeds 20%), the resource monitoring module triggers the rate-limiting mechanism, reducing the event scheduling priority of the protocol plugin or suspending some of its tasks to ensure the stable operation of the entire simulation. The CPU monitors its utilization rate with a sampling period of 100 milliseconds (100ms). The memory monitoring unit monitors memory usage with a monitoring precision of 1 megabyte (1MB). The IO monitoring unit monitors network IO usage.

[0117] Specifically, the protocol interface specification layer is based on the underlying services provided by the core engine layer and provides interfaces and specifications for the protocol plugin layer, as follows:

[0118] The purpose of the protocol interface specification layer is to provide a unified standard programming language and data format for the development, loading, and interaction of all protocol plugins. This includes defining abstract protocol interfaces, unified data format specifications, and establishing cross-domain adaptation rules. Specifically, it includes:

[0119] Define the abstract protocol interface (API): Define the protocol interface for the protocol plugins using pure virtual classes in the C++ programming language. This mandates that all protocol plugins implement the declared methods (mandatory implementation of initialization, message encapsulation / parsing, routing decisions, and performance statistics methods). Otherwise, compilation will fail. The process of forcing all protocol plugins to implement the required methods is described in code as follows:

[0120] class CrossDomainProtocol { / / Define a class named CrossDomainProtocol

[0121] public:

[0122] / / Initialize protocol parameters (such as time slot length, routing period)

[0123] virtual void Initialize(const ProtocolParam& param) = 0;

[0124] / / Message encapsulation (add protocol header: type, length, checksum)

[0125] virtual Packet Encode(const Payload& data, const NodeType& src_type) = 0;

[0126] / / Message parsing (extracting the payload and verifying header validity)

[0127] virtual Payload Decode(const Packet& pkt, const NodeType& dest_type) = 0;

[0128] / / Routing decision (returns a list of next-hop nodes, supporting cross-domain relay selection)

[0129] virtual vector <nodeid>GetNextHops(const NodeId& dest, constChannelType& channel) = 0;

[0130] / / Performance statistics (returns metrics such as throughput and latency)

[0131] virtual ProtocolStats GetStatistics() const = 0;

[0132] };

[0133] Unified Data Format Specification: To ensure that different protocol plugins, as well as between protocol plugins and the core engine layer, correctly understand the information transmitted between them, the data format is strictly unified. The data includes protocol parameters, network packets, and statistical data. The protocol parameters are defined and stored in XML format. The network packets are transmitted as binary streams on the line, with a fixed 16-byte header followed by a variable-length payload. The fixed header allows the parser to quickly locate and read key information. The statistical data is output in JSON format to ensure cross-protocol plugin compatibility.

[0134] Establish cross-domain adaptation rules: Addressing the heterogeneity between underwater acoustic networks and surface electromagnetic networks, a protocol conversion mechanism is employed. (For example, when a message needs to traverse from one domain (e.g., surface network) to another (e.g., underwater network), long messages are fragmented, with the fragment size determined by a formula.) The minimum value is calculated and obtained, where MTU The maximum transmission unit is set, and the default fragmentation is set to... ).

[0135] Specifically, the protocol plugin layer implements the interface standards defined by the protocol interface specification layer and provides loadable protocol plugin entities for the dynamic loading engine layer, including:

[0136] The protocol plugin layer includes pre-built protocol plugins and custom protocol plugins, conforming to the interfaces and specifications defined by the protocol interface specification layer, and providing loadable protocol plugins for the dynamic loading engine layer, specifically including:

[0137] Pre-built protocol plugins: Integrating five commonly used cross-domain protocol plugins, encapsulated as independent modules according to interface specifications, including an underwater MAC protocol plugin, a surface MAC protocol plugin, and a cross-domain routing protocol plugin; the underwater MAC protocol plugins include a TDMA protocol plugin (Time Division Multiple Access protocol plugin, used to divide time into fixed periodic subframes and allocate dedicated communication time slots for each network node, with time slot lengths flexibly configurable within the range of 50ms to 500ms) and an ALOHA protocol plugin (Random Access protocol plugin, which can directly transmit data when needed); the surface MAC protocol plugins include a CSMA / CA protocol plugin (Carrier Sense Multiple Access / Collision Avoidance protocol plugin, which listens for channel idleness before transmission; if idle, it waits for a random backoff time before transmission, and the backoff window size is calculated using the following formula: , (This refers to the number of retries). The cross-domain routing protocol plugins include the AODV protocol plugin (Self-Organizing On-Demand Distance Vector Routing Protocol, an on-demand routing protocol that establishes routes only when communication is needed, with a route timeout between 30 and 120 seconds) and the DSDV protocol plugin (Destination Sequence Distance Vector Routing Protocol, also known as a table-driven routing protocol, where each node maintains a routing table to all destination nodes and maintains network topology consistency through periodic updates).

[0138] Custom protocol plugins: Based on interfaces and specifications, the protocol logic is implemented, and the plugins are compiled and packaged using dedicated compilation tools (i.e., programming languages, supporting C++ / Python) to implement the required methods declared in the protocol interface specification layer, generating .plugin format protocol plugins that are easy to identify and load;

[0139] All protocol plugins include binary executable code, description files (a metadata file in XML or JSON format that declares the protocol type (such as MAC, routing), supported channels (such as underwater acoustic, electromagnetic, or both) and parameter ranges (such as transmit power range) and dependency libraries (such as encryption algorithms and special routing algorithms).

[0140] Specifically, the dynamic loading engine layer includes plugin discovery and resolution, hot loading / unloading, version and dependency management, and is responsible for the lifecycle management of all protocol plugins in the protocol plugin layer. It also works with the security verification layer to ensure the secure loading of all protocol plugins, as detailed below:

[0141] Plugin discovery and parsing: At startup, scan the specified protocol plugin directory (directory path is / plugins), identify all protocol plugin files in the protocol plugin directory (such as files with the .plugin suffix), and identify the protocol type by reading the description file in each protocol plugin (such as identifying the protocol type of the protocol plugin by parsing the type field type="underwater-mac" in the description file), and control the time from the start of scanning to the completion of parsing all protocol plugins to ≤500ms.

[0142] Hot loading / unloading: Dynamic link library technology is used to implement runtime loading using the corresponding file format on different platforms (.so files on Linux platform; .dll files on Windows platform). During loading, the binary executable code of all protocol plugins is mapped into the memory space through the dlopen() function. During unloading, the memory resources occupied by all protocol plugins are released through dlclose(). The entire loading / unloading operation takes ≤100ms and does not interrupt the simulation.

[0143] Version and Dependency Management: Supports the coexistence of different versions of the same protocol (e.g., TDMA_v1.0, TDMA_v2.0), and controls compatibility through semantic version number naming (major version number.minor version number.patch). Automatically checks the dependencies of all protocol plugins (e.g., an AODV routing protocol plugin may depend on an IPv4 protocol plugin). When the required dependency is detected to be missing, it immediately returns ERROR_DEPENDENCY_MISSING and prevents the loading of the corresponding protocol plugin.

[0144] Specifically, the security verification layer includes two core mechanisms: a static verification mechanism and a dynamic sandbox testing mechanism. Before the dynamic loading engine layer performs the loading operation, it verifies all protocol plugins in the protocol plugin layer to ensure the compatibility and stability of the protocol plugins, as detailed below:

[0145] 1) Static verification mechanism

[0146] The static verification mechanism includes interface compliance checks and format validation;

[0147] Interface compliance check: The binary executable code of any protocol plugin is analyzed using an Abstract Syntax Tree (AST) to verify whether it fully implements the required methods declared in the CrossDomainProtocol interface (the required methods declared in the CrossDomainProtocol class defined in the protocol interface specification layer). If any required methods are found to be missing, the protocol plugin is marked as INVALID_INTERFACE (interface invalid state) to prevent it from loading; this ensures that all protocol plugins can be called normally and that simulation crashes will not occur due to missing functionality.

[0148] Format verification: Check whether the header of all network packets generated by all protocol plugins contains a checksum field (CRC16, which is a commonly used verification algorithm to verify whether the packet has been tampered with), and verify whether the configuration parameter range of all protocol plugins conforms to the preset specifications (such as time slot length ≤ 500ms); avoid protocol plugins using non-standard formats / parameters, which may lead to incompatibility between protocol plugins or simulation logic errors.

[0149] 2) Dynamic sandbox testing mechanism

[0150] The dynamic sandbox testing mechanism includes resource isolation, anomaly monitoring, and performance benchmark testing;

[0151] Resource isolation: Allocate an independent process for each protocol plugin (PID naming format is proto_ <name> _ <pid>It also limits the resource usage of protocol plugins, including limiting CPU usage to ≤20% (to prevent protocol plugins from excessively consuming computing resources), limiting memory to ≤512MB (to avoid memory exhaustion leading to system crashes), and limiting network IO to ≤1Mbps (to control network data transmission speed).

[0152] Anomaly Monitoring: Real-time monitoring of the operation of any protocol plugin. If any of the following anomalies occur, the corresponding protocol plugin will be automatically terminated and logged: The anomalies include crashes during the operation of the protocol plugin (such as triggering the SIGSEGV signal, usually a memory access error), deadlocks (monitoring thread blocking status, any thread blocked for ≥10 seconds will be judged as a deadlock), and memory leaks (real-time tracking of memory allocation, when the leakage rate is ≥1MB / minute, long-term operation will fill up the memory, immediately triggering an alarm and recording detailed allocation stacks).

[0153] Performance benchmarking: In a standard cross-domain communication scenario (10-node cross-domain communication, lasting 10 minutes), performance metrics for all protocol plugins were calculated. These metrics included throughput (the total amount of valid data successfully transmitted per unit time), average latency (the average transmission delay per packet), and packet loss rate (the ratio of "unsuccessfully transmitted packets" to "total number of sent packets"). The calculation formulas are as follows:

[0154] ,

[0155] ,

[0156] .

[0157] Specifically, the secondary development and teaching layer includes a development kit and a teaching demonstration module. It provides development and teaching support by utilizing all protocol plugins provided by the protocol plugin layer, as detailed below:

[0158] 1) Development Kit:

[0159] The development kit includes a protocol template generator, a visual editor, and debugging tools;

[0160] Protocol template generator: Automatically generates code files (such as CustomMAC.cpp) that conform to the CrossDomainProtocol protocol interface standard skeleton based on the protocol type (such as MAC / routing protocol).

[0161] Visual editor: Build protocol logic by dragging and dropping protocol components (such as "time slot allocator" and "collision detector") and automatically convert it into code that conforms to the protocol interface and specifications;

[0162] Debugging tools: Real-time printing of protocol running status (such as TDMA time slot allocation table), visual display of message flow path (such as NodeA→buoy B→NodeC), and support for breakpoint debugging function (can pause / step execution);

[0163] 2) Teaching Demonstration Module:

[0164] The teaching demonstration module includes protocol state machine visualization, performance comparison analysis, and an error case library;

[0165] Protocol state machine visualization: Convert the logic of methods such as GetNextHops() into a UML state diagram (nodes represent states, arrows represent conditional jumps), and dynamically highlight the current execution path;

[0166] Performance Comparison Analysis: Multiple protocols are run in the same simulation scenario, generating indicator comparison curves (based on Matplotlib), and a protocol compatibility index is introduced. And perform a weighted calculation (where the weights are set to...) );

[0167] Error Case Library: Preset common protocol defects in communication protocols (such as routing loops and time slot conflicts), supports actively injecting specific errors (such as network congestion) during simulation, observe the resulting fault phenomena and troubleshooting steps.

[0168] Specifically, the protocol development and loading process provides an integrated process that connects the core engine layer, protocol interface specification layer, protocol plugin layer, dynamic loading engine layer, security verification layer, and secondary development and teaching layer to form a complete closed-loop management system. This closed-loop management process consists of five steps: plugin development, verification and registration, simulation configuration, dynamic loading, and teaching analysis, as detailed below:

[0169] Plugin Development: Two parallel development paths are adopted, using a visual editor or protocol templates to write code; the visual editor allows users to build protocol logic by dragging and dropping pre-built protocol components, while the protocol template generator automatically generates code files (such as CustomProtocol.cpp) containing the CrossDomainProtocol interface skeleton, implements the protocol logic, and compiles to generate .plugin protocol plugin files;

[0170] Verification and Registration: The security verification layer verifies all protocol plugins through static verification mechanisms (such as checking for syntax errors and malicious logic in the code) and dynamic sandbox testing mechanisms (such as running the plugin in a simulated environment to see if there are any crashes or exceptions). After verification, all protocol plugins are registered in the protocol plugin library, and a unique identity identifier (called ProtocolID) is generated to facilitate finding the protocol plugin in the future.

[0171] Simulation configuration: Select the corresponding protocol plugin according to the simulation scenario requirements (e.g., use the TDMA_v2.0 protocol for underwater nodes and the CSMA / CA protocol for surface nodes); set specific operating parameters for the selected protocol plugin (e.g., set the time slot length to 100ms for the TDMA protocol).

[0172] Dynamic loading: During simulation, the dynamic loading engine layer finds the corresponding protocol plugin based on the previously registered ProtocolID and loads it; the core engine layer calls the CrossDomainProtocol interface in the protocol plugin to allow the protocol plugin to participate in the simulation process (such as processing messages and executing protocol logic).

[0173] Instructional Analysis: The teaching module generates a real-time state diagram of the protocol (demonstrating the protocol logic flow) and performance indicator curves (such as changes in throughput and latency); after simulation, it outputs a document containing... The report provides a comparison of the performance of different protocols (such as a comparison of metrics between TDMA and CSMA / CA) to facilitate analysis and learning.

[0174] like Figure 2 As shown in the figure, the specific experiments of the present invention are described in detail below with reference to the technical solution and accompanying drawings:

[0175] This example describes a cross-domain communication simulation system that supports dynamic loading of multiple protocols and secondary development. The core deployment is based on the Linux kernel (Ubuntu 22.04 LTS), and the core engine is developed using the C++17 standard (with the GCC 11.2 compiler). The dynamic loading function relies on the libdl dynamic link library of the Linux system, and the teaching visualization module integrates Python 3.9 (Matplotlib 3.7 plotting library and NetworkX 3.1 topology visualization library). The specific implementation steps and technical details are explained in detail from four dimensions: architecture deployment, the entire secondary development process, simulation operation and teaching analysis, and system maintenance and troubleshooting.

[0176] (a) Architecture Deployment

[0177] The architecture deployment consists of three core steps: core engine compilation, pre-installed plugin installation, and system startup, ensuring the completion of the basic operating environment for the simulation system. The specific process is as follows:

[0178] 1) Compile the core engine

[0179] The core engine is the underlying support of the architecture, containing core components such as a discrete event scheduler, a cross-domain channel model, and a resource monitoring module. It needs to be compiled and built using the CMake tool. Specific steps are as follows:

[0180] Prepare the compilation environment and configure compilation parameters: Ensure that GCC 11.2, CMake (version ≥ 3.22), libdl-dev and other dependent libraries are installed on the Ubuntu 22.04 system, and complete the environment configuration;

[0181] To perform compilation: Open a terminal in the project root directory and execute the compilation command `cmake -DCMAKE_BUILD_TYPE=Release && make -j4`. Here, `-DCMAKE_BUILD_TYPE=Release` indicates compiling for a release version (optimizing runtime performance), and `-j4` enables parallel compilation using four threads, reducing compilation time. After compilation, the core engine shared library file `libcde_core.so` will be generated in the `build` folder of the project directory. This file is a core runtime dependency of the architecture.

[0182] 2) Install the pre-installed protocol plugin

[0183] Create a standardized plugin storage directory ` / opt / cde / plugins`. Copy the `.plugin` format files of the five pre-built commonly used cross-domain protocol plugins (TDMA, ALOHA, CSMA / CA, AODV, DSDV) and their XML description files to the ` / opt / cde / plugins` directory. Taking the TDMA_v2.0 plugin as an example, its description file `tdma_v2.0.xml` follows a preset format and includes core information such as protocol ID, name, version, type, configurable parameters (slot length, frame size), and dependencies. The specific code process is described below:

[0184] <protocol>

[0185] <id> MAC002< / id>

[0186] <name> TDMA< / name>

[0187] <version> 2.0< / version>

[0188] <type> underwater-mac< / type>

[0189] <params>

[0190] <param name="slot_length" min="50" max="500" unit="ms" default="100">

[0191] <param name="frame_size" min="5" max="20" unit="slots" default="10">

[0192] < / params>

[0193] <dependencies> []< / dependencies>

[0194] < / protocol>

[0195] 3) Start the simulation system

[0196] After completing the core engine compilation and plugin installation, start the simulation system and verify its basic functions. Specific steps are as follows:

[0197] Execute the startup command: Enter the core engine's running directory and execute . / cde_simulator --scenecross_domain_10node.json, where the --scene parameter specifies the path to the simulation scene configuration file;

[0198] Startup status verification: Parse the plugin description file and load the pre-built plugins. You can execute the `top` command to view the independent process corresponding to the plugin. The process name follows the `proto_` directive. <name> _ <pid>Naming format (e.g., proto_TDMA_12345);

[0199] (II) Examples of Secondary Development

[0200] Taking the development of a cross-domain routing protocol based on buoy relay as an example, this paper details the development, verification, and loading process of a custom protocol plugin, as well as the demonstration operation of the teaching module. The specific steps are as follows:

[0201] 1) Custom Protocol Plugin Development: Develop a "Cross-Domain Routing Protocol Based on Buoy Relay", prioritizing surface buoys as relay nodes for underwater-to-surface communication; use the dedicated compilation tool cde_compiler provided by the architecture, execute the compilation command cde_compiler custom_router.cpp -o custom_router.plugin, the compiler automatically checks the code syntax, links dependent libraries, and finally generates a custom plugin file in .plugin format that conforms to the specifications;

[0202] 2) Plugin security verification and loading:

[0203] Static verification: The interface compliance check (verifying whether the five pure virtual functions of CrossDomainProtocol are fully implemented) is passed, the packet header is checked to see if it contains a CRC16 checksum field, and the routing parameter range is in compliance with the specifications. After the verification is passed, the dynamic testing phase begins.

[0204] Dynamic testing: In a dynamic sandbox environment test, running for 10 minutes in a 10-node cross-domain scenario, the performance metrics were as follows: , , It can capture abnormalities such as crashes, deadlocks, and memory leaks during plugin operation in real time, and calculate performance indicators when the plugin does not exhibit abnormal behavior.

[0205] Loading result: After both static and dynamic verifications pass, the dynamic loading engine assigns a unique ProtocolID=ROUTE005 to the custom plugin and registers the plugin information to the routing protocol list;

[0206] 3) Teaching demonstration:

[0207] During simulation, the teaching module automatically converts the method logic of the custom plugin into a UML state diagram. Nodes represent states such as "target node judgment", "buoy node filtering" and "next hop node determination", and arrows represent conditional jumps. During simulation, the current execution path is dynamically highlighted (such as "underwater Node1 → buoy node filtering → buoy B → next hop node determination"), which intuitively displays the core logic of the protocol.

[0208] Performance Comparison: Compared to the AODV protocol, the custom protocol improves cross-domain throughput by 15% ( ), calculate the fit index , .

[0209] This architecture provides an integrated solution for the development, verification, and teaching of cross-domain communication protocols through standardized, pluggable, and visual design. It can be widely used in university communication courses, research institute protocol research, and other scenarios.

[0210] Although preferred embodiments of this application have been described, those skilled in the art, upon learning the basic inventive concept, can make other changes and modifications to these embodiments. Therefore, the appended claims are intended to be interpreted as including the preferred embodiments as well as all changes and modifications falling within the scope of this application.

[0211] Obviously, those skilled in the art can make various modifications and variations to this application without departing from the spirit and scope of this application. Therefore, if such modifications and variations fall within the scope of the claims of this application and their equivalents, this application also intends to include such modifications and variations.< / pid> < / name> < / pid> < / name> < / nodeid> < / nodeid>

Claims

1. A cross-domain communication simulation system supporting dynamic loading and secondary development of multiple protocols, characterized in that, include: Core engine layer: By building a discrete event scheduler, constructing a cross-domain channel model, and deploying a resource monitoring module, it provides underlying services and resource management for simulation tasks; Protocol Interface Specification Layer: Based on the underlying services provided by the core engine layer, cross-domain protocol interfaces are defined through pure virtual classes in programming languages. This layer unifies protocol parameters, message structures, data format specifications, and cross-domain adaptation rules to achieve standardization, compatibility, and adaptive communication across heterogeneous networks for protocol plugins. Protocol Plug-in Layer: Following the interfaces and specifications defined in the protocol interface specification layer, pre-built protocol plug-ins and custom protocol plug-ins are constructed. The pre-built protocol plug-ins include 5 commonly used cross-domain protocol plug-ins. The custom protocol plug-ins are generated using a dedicated compilation tool based on the protocol interfaces and specifications to realize the pluggable encapsulation of protocols. Dynamic loading engine layer: interacts with the protocol plugin layer, scans the directory and parses the protocol plugin type at startup, realizes uninterrupted hot loading / unloading through dynamic link library technology, supports multi-version compatibility of protocols, automatically checks the dependencies of all protocol plugins and reports missing errors, and is used to manage the life cycle of protocol plugins. The specific interaction process between the dynamic loading engine layer and the protocol plugin layer is as follows: At startup, the system scans the specified protocol plugin directory, identifies all protocol plugin files in the directory, and identifies the protocol type by reading the description file in each protocol plugin. The system controls the time from startup scanning to completion of parsing all protocol plugins to be ≤500ms. Dynamic link library technology is used to implement runtime loading using corresponding file formats on different platforms. During loading, the binary executable code of all protocol plugins is mapped into the memory space through the dlopen() function. During unloading, the memory resources occupied by all protocol plugins are released through dlclose(). The entire loading / unloading operation takes ≤100ms and does not interrupt the simulation. Security verification layer: Verifies all protocol plugins in the protocol plugin layer. In cross-domain communication scenarios, it calculates the performance indicators of the protocol plugins to ensure their compatibility and stability. The verification includes a static verification mechanism and a dynamic sandbox testing mechanism. The static verification mechanism checks the interface compliance through abstract syntax tree analysis, and verifies the message format and parameter range. The dynamic sandbox testing mechanism restricts resource usage and monitors for abnormal issues. Secondary Development and Teaching Layer: Provides development and teaching support for the protocol plugin layer and protocol interface specification layer, including a development kit and a teaching demonstration module. The development kit assists in protocol development through a protocol template generator, a visual editor, and debugging tools. The teaching demonstration module demonstrates operations such as protocol state machine visualization, performance comparison analysis, and error case library demonstration. The specific technical solution for the secondary development and teaching layer is as follows: 1) Development Kit: The development kit includes a protocol template generator, a visual editor, and debugging tools; Protocol Template Generator: Automatically generates code files that conform to the CrossDomainProtocol protocol interface standard skeleton based on the protocol type; Visual editor: Build protocol logic by dragging and dropping protocol components, and automatically convert it into code that conforms to the protocol interface and specifications; Debugging tools: Real-time printing of protocol running status, visual display of message flow path, and support for breakpoint debugging; 2) Teaching Demonstration Module: The teaching demonstration module includes protocol state machine visualization, performance comparison analysis, and an error case library; Protocol state machine visualization: The logic of the GetNextHops() method is converted into a UML state diagram, and the current execution path is dynamically highlighted; Performance Comparison Analysis: Multiple protocols are run in the same simulation scenario, generating indicator comparison curves and introducing a protocol compatibility index. And perform weighted calculations; Error Case Library: Preset common protocol defects in communication protocols, supports actively injecting specific errors during simulation, observe the resulting fault phenomena and troubleshooting steps; Protocol development and loading process: Provides an integrated protocol development and loading process, connecting all layers; Two protocol plugin development paths are adopted: visual editing or template code. The protocol plugin is compiled and generated, then verified by the security verification layer and registered to the protocol plugin library; then the simulation scenario and protocol parameters are configured. The protocol plugin is dynamically loaded at startup to participate in the simulation; finally, the teaching demonstration module of the secondary development and teaching layer generates the state diagram, index curve and comparison report.

2. The cross-domain communication simulation system supporting dynamic loading and secondary development of multiple protocols according to claim 1, characterized in that, The core engine layer is as follows: The core engine layer includes a discrete event scheduler, a cross-domain channel model, and a resource monitoring module, as detailed below: Discrete event scheduler: Employs a priority queue-based event management mechanism to manage simulation events. All simulation events are sorted and managed according to a predetermined timestamp, with a simulation time precision of 1 millisecond. It supports all protocol plugins registering events and callback functions to themselves, and the scheduler controls the entire processing delay from event triggering to the start of execution of the corresponding callback function to not exceed 10 milliseconds; Cross-domain channel model: Integrates and unifies the management of underwater acoustic propagation delay model and surface electromagnetic propagation loss model, as detailed below: The underwater sound propagation time delay model is used to calculate the propagation time delay of underwater sound signals. Its calculation formula is as follows: , In the formula, The propagation delay is measured in seconds. The distance is in meters; The speed of sound is expressed in meters per second. ; For temperature; Salinity; The electromagnetic propagation loss model for water surface is used to calculate the path loss of electromagnetic signals on the water surface. The calculation formula is as follows: ， in, Path loss, in decibels; The signal frequency is expressed in Hertz (Hz). The distance is in meters; The resource monitoring module includes a central processing unit (CPU), a memory monitoring unit, and a network input / output monitoring unit. It monitors resource consumption during the simulation process in real time and implements a protective rate-limiting mechanism. When the resource consumption of any protocol plugin exceeds a preset threshold, the rate-limiting mechanism is triggered, reducing the event scheduling priority of the corresponding protocol plugin or suspending some of its tasks. The CPU monitors CPU utilization at a sampling period of 100 milliseconds. The memory monitoring unit monitors memory usage at a monitoring precision of 1 megabyte. The network input / output monitoring unit monitors network I / O usage.

3. The cross-domain communication simulation system supporting dynamic loading and secondary development of multiple protocols according to claim 1, characterized in that, The protocol interface specification layer is based on the underlying services provided by the core engine layer and provides interfaces and specifications for the protocol plugin layer, as detailed below: The protocol interface specification layer includes defining abstract protocol interfaces, unified data format specifications, and establishing cross-domain adaptation rules, specifically including: Define an abstract protocol interface: Define the protocol interface of the protocol plugin through a pure virtual class in the programming language, which forces all protocol plugins to implement the declared methods, otherwise they will fail to compile; Unified data format specification: The data format is uniformly set; the data includes protocol parameters, network packets, and statistical data. The protocol parameters are defined and stored in XML format; the network packets are transmitted as binary streams on the line, with a fixed 16-byte header followed by a variable-length payload; the statistical data are output in JSON format. Establish cross-domain adaptation rules: adopt a protocol conversion mechanism to overcome the heterogeneity between underwater acoustic networks and surface electromagnetic networks.

4. The cross-domain communication simulation system supporting dynamic loading and secondary development of multiple protocols according to claim 1, characterized in that, The protocol plugin layer includes pre-built protocol plugins and custom protocol plugins, which follow the interfaces and specifications defined by the protocol interface specification layer, and provide loadable protocol plugins for the dynamic loading engine layer, as follows: Pre-built protocol plugins: integrate 5 commonly used cross-domain protocol plugins, which are encapsulated into independent modules according to the interface specifications, including underwater MAC protocol plugin, surface MAC protocol plugin and cross-domain routing protocol plugin. The underwater MAC protocol plugin includes a TDMA protocol plugin and an ALOHA protocol plugin; The surface MAC protocol plugin is a CSMA / CA protocol plugin; The cross-domain routing protocol plugins include the AODV protocol plugin and the DSDV protocol plugin; Custom protocol plugins: Based on interfaces and specifications, the protocol logic is implemented, compiled and packaged using dedicated compilation tools, and the required methods declared in the protocol interface specification layer are implemented to generate .plugin format protocol plugins that are easy to identify and load; All protocol plugins include binary executable code, description files, and dependency libraries.

5. The cross-domain communication simulation system supporting dynamic loading and secondary development of multiple protocols according to claim 1, characterized in that, The security verification layer includes a static verification mechanism and a dynamic sandbox testing mechanism. Before the dynamic loading engine layer performs the loading operation, all protocol plugins in the protocol plugin layer are verified, as follows: 1) Static verification mechanism: The static verification mechanism includes interface compliance checks and format validation; Interface compliance check: Analyze the binary executable code of any protocol plugin through the abstract syntax tree and verify whether it fully implements the required methods declared in the CrossDomainProtocol interface. If the required methods are found to be missing, mark the protocol plugin in the INVALID_INTERFACE state to prevent it from loading. Format validation: Check whether the header of all network packets generated by all protocol plugins contains a checksum field, and verify whether the configuration parameter range of all protocol plugins conforms to the preset specifications; avoid protocol plugins using non-standard formats / parameters, which may lead to incompatibility between protocol plugins or simulation logic errors. 2) Dynamic sandbox testing mechanism The dynamic sandbox testing mechanism includes resource isolation, anomaly monitoring, and performance benchmark testing; Resource isolation: Allocate an independent process to each protocol plugin and limit the resource usage of the protocol plugin, including limiting CPU usage to ≤20%, memory usage to ≤512MB, and network I / O to ≤1Mbps; Anomaly monitoring: Real-time monitoring of the operation of any protocol plugin. If any of the following anomalies occur, the corresponding protocol plugin will be automatically terminated and logged: The anomalies include crashes, deadlocks, and memory leaks during the operation of the protocol plugin. Performance benchmarking: In a standard cross-domain communication scenario, performance metrics for all protocol plugins are calculated. These metrics include throughput, average latency, and packet loss rate, and the calculation formulas are as follows: ， , 。 6. The cross-domain communication simulation system supporting dynamic loading and secondary development of multiple protocols according to claim 1, characterized in that, The protocol development and loading process provides an integrated workflow, connecting the core engine layer, protocol interface specification layer, protocol plugin layer, dynamic loading engine layer, security verification layer, and secondary development and teaching layer to form a complete closed-loop management system. This closed-loop management consists of five processes: plugin development, verification and registration, simulation configuration, dynamic loading, and teaching analysis, as detailed below: Plugin Development: Two parallel development paths are adopted, using a visual editor or a protocol template generator to write code; the visual editor allows users to build protocol logic by dragging and dropping pre-built protocol components, while the protocol template generator automatically generates a code file containing the CrossDomainProtocol interface skeleton, implements the protocol logic, and compiles to generate a .plugin protocol plugin file; Verification and Registration: The security verification layer verifies all protocol plugins through static verification and dynamic sandbox testing mechanisms. After verification, all protocol plugins are registered in the protocol plugin library and a unique identity is generated to facilitate finding the protocol plugin in the future. Simulation configuration: Select the corresponding protocol plugin according to the simulation scenario requirements; set the specific running parameters for the selected protocol plugin; Dynamic loading: During simulation, the dynamic loading engine layer finds the corresponding protocol plugin based on the previously registered ProtocolID and loads it; the core engine layer calls the CrossDomainProtocol interface in the protocol plugin to allow the protocol plugin to participate in the simulation process. Instructional Analysis: The instructional module generates the protocol's state diagram and performance index curves in real time; after simulation, it outputs a document containing... The report provides a comparison of performance data for different protocol plugins, facilitating analysis and learning.

Images