Lightweight code reusable framework suitable for network protocol research and development

Abstract

The invention discloses a lightweight code reusable framework suitable for network protocol research and development, and relates to the technical field of communication networks, the reusable framework comprises an adapter framework adaptive to multiple platforms, a platform independent layer, a fault injection module, and a protocol layer based on a protocol instance tree and a protocol instance management tree; the method can be compatible with various simulation platforms and actual equipment platforms, supports wired and wireless network protocols, achieves the effects of one-time code writing and multi-platform universality, and supports rapid fault injection, thereby effectively solving the problem that existing network protocol codes are insufficient in flexibility and expansibility.

Description

Technical Field

[0001] The present invention relates to the field of communication network technology, and more specifically, to a lightweight code reusable framework suitable for network protocol research and development. Background Art

[0002] In order to better study the effects and characteristics of communication protocols, researchers and engineers usually need to invest a lot of time in simulation verification when a new communication protocol is formulated. For example, researchers have developed a variety of TSN protocol stacks and simulation models on different platforms to deepen their understanding of time-sensitive networks. For example, the inet and nesting model libraries on the OMNET++ platform, but these models are difficult to quickly deploy on other platforms, and code modifications are quite complicated for other researchers. In addition, the code has poor cross-platform reusability, requiring researchers to write different codes for different platforms, which reduces efficiency.

[0003] Although there are many types of simulators used in network protocols (OMNET++ / OPNET / NS3), the following problems still exist: ① Although the simulation code has advantages in verifying system functions in large-scale test scenarios, it cannot be directly applied to other simulation platforms and actual environments due to its strong binding with the simulation platform. ② After the actual code is implemented, when building large-scale test scenarios, it often faces challenges such as time and cost, making it difficult to verify its effectiveness in real applications. Summary of the invention

[0004] The purpose of the present invention is to provide a lightweight code reusable framework suitable for network protocol research and development. By separating protocol logic and platform functions, network protocol codes can be efficiently reused on different platforms, effectively avoiding repeated development of network protocol codes. At the same time, a fault injection layer is also provided for quickly building various failure scenarios.

[0005] The above technical objectives of the present invention are achieved through the following technical solutions:

[0006] In a first aspect, the present application provides a lightweight code reusable framework suitable for network protocol development, the reusable framework comprising an adapter framework, a platform-independent layer, a fault injection module and a protocol layer, wherein:

[0007] The adapter framework is used to perform: secondary encapsulation of network-related functions provided by the operating system or simulation platform, and support for the timing behavior of time-sensitive networks and other network protocols through the platform timer adaptation mechanism;

[0008] The platform-independent layer is used to perform: sending and receiving data packets and adding errors, maintaining the discrete time event list, and obtaining and modifying platform-independent time values;

[0009] The fault injection module is located in the platform-independent layer and is used to perform: decomposing each fault into basic faults and injecting the fault descriptors corresponding to the basic faults into the data packets sent by each port;

[0010] The protocol layer is used to execute: Based on the tree structure, the protocol layer creates a new protocol by specifying the protocol type in the configuration file and binding the parent protocol, and manages the communication interface.

[0011] Based on the above technical solution, the present invention can also be improved as follows.

[0012] Furthermore, the above network related functions are encapsulated twice, specifically:

[0013] The interface of the upper protocol layer is unified into standard receiving and sending functions and register reading and writing functions, and the platform adaptation mechanism that supports the sending and receiving of network data frames of different platforms is adopted for the lower platform.

[0014] Furthermore, the above platform timer adaptation mechanism supports the timing behavior of time-sensitive networks and other network protocols, specifically:

[0015] In the initialization phase, the platform-independent layer creates a list of discrete time events and calls the timer creation function, timer, and PILTimer object of the corresponding platform;

[0016] During operation, the protocol layer adds or cancels a timed event by adding or deleting a timed event descriptor to the event list of the platform-independent layer, and the timed event descriptor stores the address of the corresponding callback function. When the event is triggered, the corresponding function is called back to handle the corresponding event.

[0017] When the PILTimer object is triggered, the platform-independent layer selects the events whose trigger time is before the current platform system time in the discrete time event list, and runs the callback function in turn for processing;

[0018] The platform-independent layer searches the event list for events whose trigger time is less than the current platform system time, and for all events that meet the conditions, the platform-independent layer runs the callback functions in the event descriptors in turn to process the events.

[0019] Furthermore, the sending and receiving of the above data packets are specifically as follows:

[0020] The platform-independent layer creates a virtual network port and obtains a mapping table between the virtual network port and the platform port;

[0021] According to the mapping table, the protocol layer sends data downward, the platform port receives data, and the protocol layer reads and writes registers;

[0022] For the direction of sending data, if the protocol layer calls the Send method of the platform-independent layer, the data to be sent is sent to the corresponding virtual network port, and according to the mapping rules of the mapping table, it is passed to the platform port and the platform data sending function is called; for the direction of receiving data, the platform-independent layer uses the multi-platform adapted data receiving mechanism to receive data frames, obtains the corresponding protocol through the corresponding virtual network port and data packet descriptor, and calls the receive function of the corresponding protocol; for the operation of registers, the ioctl method of the operating system is called, and if the underlying layer is simulation software, it will not be processed.

[0023] Furthermore, the tree-structured protocol layer creates a new protocol by specifying the protocol type in the configuration file and binding the parent protocol, and manages the communication interface, specifically:

[0024] The protocol completes the registration of the interface function and completes the initialization of the protocol instance tree and the data structure required by the current protocol;

[0025] Periodically report the current running status through the notify interface of the protocol instance management tree, or actively call the notify interface to report the current abnormal situation, and complete the configuration management of the protocol through the config interface when customizing the experimental scenario.

[0026] Furthermore, when data is sent and received based on the protocol layer, for the sending direction:

[0027] Based on the completed protocol framing, generate the corresponding data packet descriptor and call the send method of the protocol;

[0028] Based on the send method, the proxy data is sent to the parent protocol through the protocol tree;

[0029] For the receiving direction:

[0030] The bottom layer is based on the received data and finds the receive method registered by the sub-protocol through the protocol tree according to the protocol type of the data packet descriptor;

[0031] Call the sub-protocol registration receive method, and send the data to be sent to the corresponding sub-protocol through the protocol tree according to the protocol type of the data packet descriptor.

[0032] Furthermore, the above fault descriptor characterizes the port where the fault occurs, the type of protocol where the fault occurs, the time when the fault starts, the time when the fault ends, the type of fault and the value that needs to be modified.

[0033] Furthermore, the fault descriptor corresponding to the basic fault is injected into the data packet sent by each port, specifically:

[0034] Put the fault event after initialization into the descriptor queue maintained by the fault injection layer of each port of each device in the form of a fault descriptor;

[0035] By setting a timer, when a fault starts, the corresponding fault descriptor is taken out from the descriptor queue and put into the current fault queue, and when the fault ends, the corresponding fault descriptor is deleted from the current fault queue;

[0036] When the fault injection layer receives a data frame sent by the upper layer protocol, the fault injection layer traverses the current descriptor queue. If there is a fault descriptor of the current data frame protocol, the data frame is modified or delayed according to the fault descriptor.

[0037] In a second aspect, the present application provides an electronic device, comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor implements any one of the methods in the first aspect when executing the computer program.

[0038] In a third aspect, the present application provides a non-transitory computer-readable storage medium, which stores computer instructions, and the computer instructions enable a computer to execute any one of the methods in the first aspect.

[0039] Compared with the prior art, the present invention has at least the following beneficial effects:

[0040] In the present application, a method for supporting cross-platform reuse of network protocol codes is provided, aiming to solve the problems of low code reuse rate and difficulty in flexibly constructing experimental scenarios in the existing network protocol development process. A set of protocol codes can be directly used on different systems and platforms without complicated modification or modification. The advantages of network protocol codes written using this method are: 1. A unified protocol layer interface and good decoupling realize the separation of protocol code logic and platform functions, which can be quickly deployed on different platforms while maintaining consistency of protocol functions, thereby enhancing the portability and reusability of the code; 2. It includes a fault injection layer, which simplifies the fault configuration process by defining faults through software, and facilitates the rapid deployment of different fault combinations for simulation. BRIEF DESCRIPTION OF THE DRAWINGS

[0041] The drawings described herein are used to provide a further understanding of the embodiments of the present invention, constitute a part of this application, and do not constitute a limitation of the embodiments of the present invention. In the drawings:

[0042] Figure 1 A module block diagram of a reusable framework in an embodiment of the present invention;

[0043] Figure 2 is a flowchart of the implementation steps of the reusable framework in an embodiment of the present invention;

[0044] Figure 3 A flowchart of data transmission and reception in an embodiment of the present invention;

[0045] Figure 4 is a flowchart of the execution of a timing event in an embodiment of the present invention;

[0046] Figure 5 It is an operation flow chart of the protocol tree in an embodiment of the present invention;

[0047] Figure 6 A list of fault events in an embodiment of the present invention;

[0048] Figure 7 The figure is a schematic diagram of the process of inserting and deleting faults in an embodiment of the present invention. DETAILED DESCRIPTION

[0049] In order to make the purpose, technical solutions and advantages of the embodiments of the present invention clearer, the technical solutions in the embodiments of the present invention will be clearly and completely described below in conjunction with the drawings in the embodiments of the present invention. Obviously, the described embodiments are part of the embodiments of the present invention, not all of the embodiments. Generally, the components of the embodiments of the present invention described and shown in the drawings here can be arranged and designed in various different configurations.

[0050] Therefore, the following detailed description of the embodiments of the present invention provided in the accompanying drawings is not intended to limit the scope of the invention claimed for protection, but merely represents selected embodiments of the present invention. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without creative work are within the scope of protection of the present invention.

[0051] It should be noted that similar reference numerals and letters denote similar items in the following drawings, and therefore, once an item is defined in one drawing, further definition and explanation thereof is not required in subsequent drawings.

[0052] In the description of the embodiments of the present invention, "plurality" means at least 2.

[0053] Embodiment 1:

[0054] This embodiment provides a lightweight code reusable framework suitable for network protocol development. The reusable framework includes an adapter framework, a platform-independent layer, a fault injection module, and a protocol layer, wherein:

[0055] The adapter framework is used to perform: secondary encapsulation of network-related functions provided by the operating system or simulation platform, and support for the timing behavior of time-sensitive networks and other network protocols through the platform timer adaptation mechanism.

[0056] Optionally, the above network-related functions are encapsulated twice, specifically:

[0057] The interface of the upper protocol layer is unified into standard receiving and sending functions and register reading and writing functions, and the platform adaptation mechanism that supports the sending and receiving of network data frames of different platforms is adopted for the lower platform.

[0058] Specifically, the above platform timer adaptation mechanism supports the timing behavior of time-sensitive networks and other network protocols, specifically:

[0059] During the initialization phase, the platform-independent layer creates a list of discrete time events and calls the timer creation function, timer, and PILTimer object of the corresponding platform.

[0060] During runtime, the protocol layer adds or cancels a timed event by adding or deleting a timed event descriptor to the event list of the platform-independent layer. The timed event descriptor stores the address of the corresponding callback function. When the event is triggered, the corresponding function is called back to handle the corresponding event.

[0061] When the PILTimer object is triggered, the platform-independent layer filters out events whose trigger time is before the current platform system time in the discrete time event list, and runs the callback function in turn for processing.

[0062] The platform-independent layer searches the event list for events whose trigger time is less than the current platform system time, and for all events that meet the conditions, the platform-independent layer runs the callback functions in the event descriptors in turn to process the events.

[0063] Furthermore, the platform-independent layer is used to execute: receiving and sending data packets and adding errors, maintaining a discrete time event list, and obtaining and modifying platform-independent time values.

[0064] The sending and receiving of the above data packets are specifically as follows:

[0065] The platform-independent layer creates a virtual network port and obtains a mapping table for mapping between the virtual network port and the platform port.

[0066] According to the mapping table, the protocol layer sends data downward, the platform port receives data, and the protocol layer performs register read and write operations.

[0067] For the direction of sending data, if the protocol layer calls the Send method of the platform-independent layer, the data to be sent is sent to the corresponding virtual network port, and according to the mapping rules of the mapping table, it is passed to the platform port and the platform data sending function is called; for the direction of receiving data, the platform-independent layer uses the multi-platform adapted data receiving mechanism to receive data frames, obtains the corresponding protocol through the corresponding virtual network port and data packet descriptor, and calls the receive function of the corresponding protocol; for the operation of registers, the ioctl method of the operating system is called, and if the underlying layer is simulation software, it will not be processed.

[0068] Optionally, the fault injection module is located in the platform-independent layer, and is used to execute: decomposing each fault into basic faults, and injecting fault descriptors corresponding to the basic faults into data packets sent by each port.

[0069] The fault descriptor represents the port where the fault occurs, the type of protocol where the fault occurs, the time when the fault starts, the time when the fault ends, the type of fault, and the value that needs to be modified. Specifically, the fault descriptor corresponding to the basic fault is injected into the data packet sent by each port, specifically:

[0070] Put the fault event after initialization into the descriptor queue maintained by the fault injection layer of each port of each device in the form of a fault descriptor;

[0071] By setting a timer, when a fault starts, the corresponding fault descriptor is taken out from the descriptor queue and put into the current fault queue, and when the fault ends, the corresponding fault descriptor is deleted from the current fault queue;

[0072] When the fault injection layer receives a data frame sent by the upper layer protocol, the fault injection layer traverses the current descriptor queue. If there is a fault descriptor of the current data frame protocol, the data frame is modified or delayed according to the fault descriptor.

[0073] Furthermore, the above-mentioned protocol layer is used to execute: based on the tree structure protocol layer, a new protocol is created by specifying the protocol type in the configuration file and binding the parent class protocol, and the communication interface is managed; the relevant operations of the protocol (send, receive, notify, config, driverWrite, driverRead standard interfaces) are defined and performed through standard interfaces, which facilitates the porting and expansion of the protocol.

[0074] The tree-structured protocol layer creates a new protocol by specifying the protocol type in the configuration file and binding the parent protocol, and manages the communication interface, specifically:

[0075] The protocol completes the registration of the interface function and completes the initialization of the protocol instance tree and the data structure required by the current protocol;

[0076] Periodically report the current running status through the notify interface of the protocol instance management tree, or actively call the notify interface to report the current abnormal situation, and complete the configuration management of the protocol through the config interface when customizing the experimental scenario.

[0077] Optionally, when data is sent and received based on the protocol layer, for the sending direction:

[0078] Based on the completed protocol framing, generate the corresponding data packet descriptor and call the send method of the protocol;

[0079] Based on the send method, the proxy data is sent to the parent protocol through the protocol tree;

[0080] For the receiving direction:

[0081] The bottom layer is based on the received data and finds the receive method registered by the sub-protocol through the protocol tree according to the protocol type of the data packet descriptor;

[0082] Call the sub-protocol registration receive method, and send the data to be sent to the corresponding sub-protocol through the protocol tree according to the protocol type of the data packet descriptor.

[0083] Embodiment 2:

[0084] The reusable framework provided in the embodiment of the present application is composed of the following parts: Figure 1 As shown, it includes: an adapter framework (MA: Multi-Adaptors) for adapting to multiple platforms, a code reusable framework platform-independent layer (PIL: PlatformIndependence Layer), a fault injection module (FIM: Faulty Injection Module), and a protocol layer based on a protocol instance tree (PIT: Protocol Instance Tree) and a protocol instance management tree (PIMT: Protocol InstanceManage Tree). The protocol entity is the code that actually implements the protocol behavior. The protocol layer maintains a PIT and manages it through standard interfaces and PIMT.

[0085] When implementing the framework, the implementation steps are as follows: Figure 2 As shown, the details are as follows: 1. Initialize MA, and use the platform adaptation mechanism to determine the mechanism for sending and receiving data frames according to the platform on which the code is compiled; 2. Initialize the timer system, and use the multi-platform timer adaptation mechanism to determine the advancement mechanism of the discrete event timer according to the platform on which the code is compiled; 3. The protocol layer maintains a protocol instance tree and a protocol instance management tree. The upper and lower layer protocols communicate through the unified interface of the protocol instance tree, and monitoring and management are completed through the unified interface of the protocol instance management tree; 4. The fault injection module is part of the platform-independent layer of the code reusable framework. All sent and received data packets will pass through this layer to implement the operation of injecting time error threshold errors into the data packets.

[0086] Among them, this lightweight code reusable framework suitable for network protocol development can be compatible with both operating systems and simulation platforms; in order to solve the compatibility problem, the network-related functions provided by the operating system or simulation platform are repackaged, and the interface of the upper protocol layer is unified into a standard receiving and sending function, as well as a register read and write function. For the lower platform, this framework uses a platform adaptation mechanism (PAM: Platform Adaptation Mechanism) to support the sending and receiving of network data frames on different platforms.

[0087] Specifically, for the operating system, its network data frame sending and receiving capabilities are used for customization; and for the simulation software, the data sending and receiving interface and the unformatted packet (UP) mechanism provided by it are combined for corresponding adaptation. PAM ensures the flexibility and scalability of the framework between different platforms. In addition, the framework also includes a multi-platform timer adaptation mechanism (MPTAM) to support the timing behavior of time-sensitive networks and other network protocols (such as periodic notifications, periodic monitoring, etc.). In the specific implementation, MPTAM can adapt according to the characteristics of the underlying platform to ensure rapid deployment on different platforms.

[0088] Optionally, in order to make the code adapt to the timer behavior of multiple platforms, the platform timer is encapsulated by the PILTimer class in this embodiment. PILTimer uses a discrete event list method, and the discrete event list is driven by the platform's system time to implement PILTimer. PILTimer uses a time event list strategy, and only one PILTimer object is needed globally, such as Figure 4 As shown, through Figure 4 Describe the execution process of the timed event. The specific execution process is as follows:

[0089] Step 1: In the initialization phase, PIL creates a list of discrete time events, calls the timer creation function of the corresponding platform to create a timer and then creates a PILTimer object;

[0090] Step 2: During runtime, the protocol layer adds or cancels a timed event by adding or deleting a timed event descriptor to the PIL event list. The timed event descriptor will save the address of the corresponding callback function, and when the event is triggered, the corresponding function can be directly called back to handle the corresponding event;

[0091] Step 3: When the PILTimer object is triggered, PIL starts to operate on the discrete time event list, finds all events whose trigger time is before the current platform system time, and runs the callback function in turn for processing;

[0092] Step 4: PIL searches the event list for events whose trigger time is less than the current platform system time;

[0093] Step 5: For all events that meet the conditions, PIL runs the callback functions in the event descriptors in turn to process the events.

[0094] Furthermore, the above-mentioned platform-independent layer (PIL: Platform Independence Layer) mainly completes: ① the sending and receiving of data packets and error correction; ② the platform-independent time interface (PITI: Platform Independence Timer Interface), including the maintenance of the discrete time event list and the acquisition and modification of the platform-independent time value.

[0095] Among them, PIL uses a multi-platform universal packet management mechanism to send and receive packets, manages packets in the protocol layer through packet descriptors, finds the corresponding protocol from the protocol tree and calls the protocol's send and receive functions according to the packet sending and receiving direction and protocol type in the descriptor, thereby completing the cross-layer transmission of packets between protocol layers.

[0096] Optionally, the above data transmission and reception process is as follows: Figure 3 As shown, specifically:

[0097] Step 1: First, PIL creates a virtual network port and completes the mapping between the virtual network port and the platform port. PIL maintains a mapping table between virtual network ports and platform ports. The upper layer protocol directly uses the virtual network port. For the operating system, the mapping table is actually the mapping relationship between the virtual network port and the operating system socketFd. For the simulation platform, the mapping table is actually the mapping relationship between the virtual network port and the simulation software port ID.

[0098] Step 2: After the mapping table is established, data-related operations begin, including the protocol layer sending data downward, the platform port receiving data, and the protocol layer performing register read and write operations.

[0099] Step 3: For the data sending direction, if the protocol layer calls the Send method of PIL, the data to be sent will be sent to the corresponding virtual network port, and then according to the mapping rules of the mapping table, it will be finally passed to the platform port and the platform data sending function will be called; for the data receiving direction, PIL adopts a multi-platform adapted data receiving mechanism to receive data frames, and finds the corresponding virtual network port through PIL and then finds the corresponding protocol through the data packet descriptor, and finally calls the receive function of the corresponding protocol; for register operations, the ioctl method of the operating system is directly called, and if the underlying layer is simulation software, no processing is done.

[0100] Optionally, a fault injection module is included in PIL, which decomposes the fault into basic faults and then injects faults into the data packets sent by each port in the form of fault descriptors. MA completes the adaptation between PITI and PIL. In order to facilitate upper-layer applications, the PILTimer class is designed and implemented in the PIL layer, which implements the scheduling of various time events registered by the upper layer and the acquisition and modification of clock values. The system time drives the discrete event list to implement PILTimer, and only one platform-related timer is required globally. The corresponding service function and callback function are executed according to the arrival time, and all expired events at the arrival time are traversed.

[0101] Furthermore, the above-mentioned fault injection module (FIM: Fault Injection Module); since in the protocol testing phase, it is usually necessary to construct various network faults to verify the completeness of the protocol. In order to facilitate users to quickly deploy faults in simulation scenarios, this embodiment proposes a fast fault injection (FFI: Fast Fault Injection) solution, covering functions such as fault generation, analysis and injection; the solution supports users to define the required fault information through configuration files, including the port where the fault occurs, protocol type, fault time, fault type, etc. The basic fault types supported include interruption, delay and modification of data transmission. Users can combine these basic types as needed to construct more complex fault scenarios. During the simulation process, the fault injection mechanism of each device will initialize the fault event list according to the configuration file, and manage these events in the chronological order of the fault occurrence, so as to facilitate the implementation of fault injection in the simulation.

[0102] Each device has a corresponding fault descriptor XML. The user uses the fault descriptor XML to describe the fault condition of each device. A fault descriptor includes: ① the port where the fault occurs; ② the protocol type where the fault occurs; ③ the time when the fault starts; ④ the time when the fault ends; ⑤ the fault type; ⑥ the value that needs to be modified. The fault injection protocol layer of each device reads the fault descriptor XML of its own device at the beginning of the simulation and initializes the fault event list. The fault event list stores the descriptors of each fault in the order of the fault start time. Figure 6 is a schematic diagram of a fault event list; Figure 7 The fault insertion and deletion process is described as follows:

[0103] Step 1: After initialization, the fault event is stored in a fault descriptor queue maintained by the fault injection layer of each port of each device in the form of a descriptor;

[0104] Step 2: By setting a timer, at the time when the fault starts, the corresponding fault descriptor is taken out from the fault descriptor queue and put into the current fault descriptor queue;

[0105] Step 3: At the same time, by setting a timer, when the fault ends, the corresponding descriptor is deleted from the current fault descriptor queue;

[0106] Step 4: When the fault injection layer receives the data frame sent by the upper layer protocol, it will traverse the current fault descriptor queue. If there is a fault descriptor of the current data frame protocol, the data frame will be modified or delayed according to the descriptor.

[0107] Furthermore, the above-mentioned protocol layer implemented based on the protocol instance tree (PIT: Protocol Instance Tree) and the protocol instance management tree (PIMT: Protocol Instance Management Tree): this embodiment designs and implements a tree-structured protocol layer that is easy to expand; PIT creates a new protocol by specifying the protocol type in the configuration file and binding the parent class protocol, and PIMT implements the management interface, including registration, notification and configuration methods, as well as related functions for data sending and receiving.

[0108] Among them, PIT completes the registration of interface functions in the initialization phase. In the running phase, the protocol instance in PIT uses the universal data packet management mechanism for multiple platforms to perform data packet sending and receiving operations. Through the data packet descriptor, the protocol layer can find the corresponding protocol from PIT and call its sending and receiving function according to the sending and receiving direction and protocol type of the data packet, thereby realizing the cross-layer transmission of data packets between protocol layers. PIMT monitors and manages the protocol through configuration and notification methods.

[0109] Optionally, the protocol tree operation process is as follows Figure 5 As shown, the details are as follows:

[0110] Step 1: Initialization phase, the protocol completes the registration of interface functions, completes the initialization of PIT and data structures required by the current protocol;

[0111] Step 2: The protocol can periodically report the current running status through the notify() interface of PIMT, or actively call the notify() interface to report the current abnormal situation. When customizing the experimental scenario, the configuration management of the protocol can also be completed through the config() interface;

[0112] Sending direction:

[0113] Step 3: After the protocol framing is completed, the corresponding data packet descriptor is generated, and then the send method of the protocol is called;

[0114] Step 4: In the send method, the data is sent to the parent protocol through the protocol tree;

[0115] Receiving direction:

[0116] Step 3: After the bottom layer receives the data, it finds the receive method registered by the sub-protocol through the protocol tree according to the protocol type of the data packet descriptor;

[0117] Step 4: After calling the sub-protocol registration receive method, the data to be sent will be sent to the corresponding sub-protocol through the protocol tree according to the protocol type of the data packet descriptor.

[0118] The following is a further description of the reusable framework in this embodiment through examples:

[0119] Implementation Example 1: Taking the development of standard IEEE802.1AS protocol code as an example, the process of running the network protocol code developed based on the present invention on the OPNET simulation platform is described.

[0120] Step 1: When using the framework on OPNET, add the macro definition #define OPNET in main.h. Each node device has only one process model inside, and in the initialization state inside the process model, a PIL class object pilAPI and a PILTimer class object pilTimerCtrlPtr are instantiated.

[0121] Step 2: Instantiate an AS class object ieee8021ASD0 in the initialization state. Call the AS class constructor, and the parameters that need to be passed in are the parent class protocol object pointer (in this example, the pilAPI pointer instantiated in the previous step), the PILTimer class object pointer, the PIL class object pointer, the domain ID, the device ID, the priority, the number of device ports, and the clock offset.

[0122] Step 3: Register the AS protocol in pilAPI, with the parameters being the function table of ieee8021ASD0 and the protocol type field (the protocol type field of AS is 0x88F7).

[0123] Step 4: Call the run function of ieee8021ASD0 to initialize and reset, and start running the main state machine of the protocol.

[0124] Step 5: When the AS protocol layer ieee8021ASD0 needs to send a data packet to the outside of the device, it can call the send function bound in the function table of its parent protocol class object (the pilAPI pointer passed in the constructor). When the data packet is passed to the send function of PIL, the plantformTx function of PIL will continue to be called, and then the function will call the relevant packet sending operation of OPNET to transmit the data packet from the corresponding transmitter through the stream index number.

[0125] Step 6: When the process model of the node receives the data packet, it triggers the plantformRx function of PIL, parses the data packet descriptor from the Unformatted Packet of OPNET, and passes the received data packet to the receive function of PIL. The receive function of PIL finds that the upper layer of PIL is the AS layer, so it calls the receive function of the AS layer and passes the data packet to the AS layer.

[0126] Step 7: When the AS layer needs to set a timer for an event, if no timer is registered for the event, it needs to use the RegistTimer function to register a new timer (specify the TimerID). Then use the SetTimerEvent function to set the trigger time for the timer.

[0127] Step 8: When the timer of the AS layer is triggered, the GetTimerEvent function of the AS layer will be called back for execution. Specific operations can be performed within the function according to the TimerID of the timer.

[0128] Implementation Example 2: Taking the development of standard IEEE802.1AS protocol code as an example, the process of running the network protocol code developed based on the present invention on the Linux operating system is described.

[0129] Step 1: When using the framework in the Linux operating system, add the macro definition #defineLINUXOS in main.h. Then write a main function file that initializes the protocol tree and registers the callback function, compile and run.

[0130] Step 2: Instantiate an AS class object ieee8021ASD0 in the initialization function. Call the AS class constructor, and the parameters that need to be passed in are the parent class protocol object pointer (in this example, the pilAPI pointer instantiated in the previous step), the PILTimer class object pointer, the PIL class object pointer, the domain ID, the device ID, the priority, the number of device ports, and the clock offset.

[0131] Step 3: Register the AS protocol in pilAPI, with the parameters being the function table of ieee8021ASD0 and the protocol type field (the protocol type field of AS is 0x88F7).

[0132] Step 4: Call the run function of ieee8021ASD0 to initialize and reset, and start running the main state machine of the protocol.

[0133] Step 5: When the AS protocol layer ieee8021ASD0 needs to send a data packet to the outside of the device, it can call the send function bound in the function table of its parent protocol class object (the pilAPI pointer passed in the constructor). When the data packet is passed to the send function of PIL, it will continue to call the plantformTx function of PIL and use mechanisms such as socket to send the data packet from the corresponding network port.

[0134] Step 6: When the device receives the data packet, it triggers the plantformRx function of PIL, performs corresponding operations according to the platform, and passes the received data packet to the receive function of PIL. The receive function of PIL finds that the upper layer of PIL is the AS layer, so it calls the receive function of the AS layer and passes the data packet to the AS layer.

[0135] Step 7: When the AS layer needs to set a timer for an event, if no timer is registered for the event, it needs to use the RegistTimer function to register a new timer (specify the TimerID). Then use the SetTimerEvent function to set the trigger time for the timer.

[0136] Step 8: When the timer of the AS layer is triggered, the GetTimerEvent function of the AS layer will be called back for execution. Specific operations can be performed within the function according to the TimerID of the timer.

[0137] Implementation Example 3: Taking the verification of the standard IEEE802.1AS protocol code as an example, the process of quickly injecting faults into the network protocol code developed based on the present invention is explained.

[0138] Step 1: Before running the protocol code, use the self-developed fault injection configuration software to generate the fault descriptor XML that you want to inject, including information such as fault type, fault start time, fault end time, and fault offset value.

[0139] Step 2: Instantiate a fault layer in the initialization function (or state) and insert it between the AS layer and PIL, that is, first instantiate PIL, then instantiate the fault layer with PIL as the parent class protocol, and finally instantiate the AS layer with the fault layer as the parent class protocol.

[0140] Step 3: Run the protocol. When a data packet is sent from the AS layer, it will first pass through the fault layer. The fault layer will inject faults into the data packet according to the current fault descriptor list, and then send the data packet to the PIL.

[0141] Embodiment 3:

[0142] The present application provides an electronic device according to an embodiment, including a memory, a processor, and a computer program stored in the memory and executable on the processor. When the processor executes the computer program, the method of any one of Embodiment 1 or Embodiment 2 is implemented.

[0143] Embodiment 4:

[0144] An embodiment of the present application provides a non-transitory computer-readable storage medium, which stores computer instructions, and the computer instructions enable a computer to execute any method in Example 1.

[0145] The specific implementation methods described above further illustrate the objectives, technical solutions and beneficial effects of the present invention in detail. It should be understood that the above description is only a specific implementation method of the present invention and is not intended to limit the scope of protection of the present invention. Any modifications, equivalent substitutions, improvements, etc. made within the spirit and principles of the present invention should be included in the scope of protection of the present invention.

Claims

1. A lightweight code reusable framework suitable for network protocol development, characterized by: The reusable framework includes an adapter framework, a platform-independent layer, a fault injection module, and a protocol layer, where: The adapter framework is used to perform: secondary encapsulation of network-related functions provided by the operating system or simulation platform, and support for timing behaviors of time-sensitive networks and other network protocols through a platform timer adaptation mechanism; The platform-independent layer is used to perform: receiving and sending data packets and adding errors, maintaining a discrete time event list, and obtaining and modifying platform-independent time values; The fault injection module is located in the platform-independent layer and is used to perform: decomposing each fault into basic faults, and injecting the fault descriptors corresponding to the basic faults into the data packets sent by each port; The protocol layer is used to execute: based on the tree structure protocol layer, a new protocol is created by specifying the protocol type in the configuration file and binding the parent protocol, and the communication interface is managed.

2. A lightweight code reusable framework suitable for network protocol development according to claim 1, characterized in that: Network related functions are encapsulated twice, specifically: The interface of the upper protocol layer is unified into standard receiving and sending functions and register reading and writing functions, and the platform adaptation mechanism that supports the sending and receiving of network data frames of different platforms is adopted for the lower platform.

3. A lightweight code reusable framework suitable for network protocol development according to claim 1, characterized in that: The platform timer adaptation mechanism supports the timing behavior of time-sensitive networks and other network protocols, specifically: In the initialization phase, the platform-independent layer creates a list of discrete time events and calls the timer creation function, timer, and PILTimer object of the corresponding platform; During operation, the protocol layer adds or cancels a timed event by adding or deleting a timed event descriptor to the event list of the platform-independent layer, and the timed event descriptor stores the address of the corresponding callback function. When the event is triggered, the corresponding function is called back to handle the corresponding event. When the PILTimer object is triggered, the platform-independent layer selects the events whose trigger time is before the current platform system time in the discrete time event list, and runs the callback function in turn for processing; The platform-independent layer searches the event list for events whose trigger time is less than the current platform system time, and for all events that meet the conditions, the platform-independent layer runs the callback functions in the event descriptors in turn to process the events.

4. A lightweight code reusable framework suitable for network protocol development according to claim 1, characterized in that: The sending and receiving of data packets are as follows: The platform-independent layer creates a virtual network port and obtains a mapping table between the virtual network port and the platform port; According to the mapping table, the protocol layer sends data downward, the platform port receives data, and the protocol layer reads and writes registers; For the direction of sending data, if the protocol layer calls the Send method of the platform-independent layer, the data to be sent is sent to the corresponding virtual network port, and according to the mapping rules of the mapping table, it is passed to the platform port and the platform data sending function is called; for the direction of receiving data, the platform-independent layer uses the multi-platform adapted data receiving mechanism to receive data frames, obtains the corresponding protocol through the corresponding virtual network port and data packet descriptor, and calls the receive function of the corresponding protocol; for the operation of registers, the ioctl method of the operating system is called, and if the underlying layer is simulation software, it will not be processed.

5. A lightweight code reusable framework suitable for network protocol development according to claim 1, characterized in that: Based on the tree structure protocol layer, a new protocol is created by specifying the protocol type in the configuration file and binding the parent protocol, and the communication interface is managed as follows: The protocol completes the registration of the interface function and completes the initialization of the protocol instance tree and the data structure required by the current protocol; Periodically report the current running status through the notify interface of the protocol instance management tree, or actively call the notify interface to report the current abnormal situation, and complete the configuration management of the protocol through the config interface when customizing the experimental scenario.

6. A lightweight code reusable framework suitable for network protocol development according to claim 5, characterized in that: When sending and receiving data based on the protocol layer, for the sending direction: Based on the completed protocol framing, generate the corresponding data packet descriptor and call the send method of the protocol; Based on the send method, the proxy data is sent to the parent protocol through the protocol tree; For the receiving direction: The bottom layer is based on the received data and finds the receive method registered by the sub-protocol through the protocol tree according to the protocol type of the data packet descriptor; Call the sub-protocol registration receive method, and send the data to be sent to the corresponding sub-protocol through the protocol tree according to the protocol type of the data packet descriptor.

7. A lightweight code reusable framework suitable for network protocol development according to claim 1, characterized in that: The fault descriptor characterizes the port where the fault occurs, the protocol type where the fault occurs, the time when the fault starts, the time when the fault ends, the fault type, and the value that needs to be modified.

8. A lightweight code reusable framework suitable for network protocol development according to claim 7, characterized in that: The fault descriptor corresponding to the basic fault is injected into the data packet sent by each port, specifically: Put the fault event after initialization into the descriptor queue maintained by the fault injection layer of each port of each device in the form of a fault descriptor; By setting a timer, when a fault starts, the corresponding fault descriptor is taken out from the descriptor queue and put into the current fault queue, and when the fault ends, the corresponding fault descriptor is deleted from the current fault queue; When the fault injection layer receives a data frame sent by the upper layer protocol, the fault injection layer traverses the current descriptor queue. If there is a fault descriptor of the current data frame protocol, the data frame is modified or delayed according to the fault descriptor.

9. An electronic device, characterized in that: The method comprises a memory, a processor and a computer program stored in the memory and executable on the processor, wherein the method according to any one of claims 1 to 8 is implemented when the processor executes the computer program.

10. A non-transitory computer-readable storage medium, characterized in that: The non-transitory computer-readable storage medium stores computer instructions, which enable a computer to execute the method of any one of claims 1-8.

Images