A lightweight code reuse framework suitable for network protocol development

Abstract

The application 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 suitable for 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 reusable framework can not only be compatible with multiple simulation platforms and actual device platforms, but also support wired and wireless network protocols, realize the effect of one-time code writing and multi-platform generalization, and support rapid fault injection, so that the problem of the deficiency of the existing network protocol code in flexibility and expansibility is effectively solved.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of communication network, more particularly, it relates to a lightweight code reusable framework suitable for network protocol research and development. BACKGROUND

[0002] In order to better study the effect and characteristics of communication protocol, researchers and engineers need to invest a lot of time in simulation verification when a new communication protocol is formulated. For example, researchers have developed various TSN protocol stacks and simulation models on different platforms to deepen the understanding of time-sensitive networks. For example, the inet and nesting model library on the OMNET++ platform, but these models are difficult to quickly deploy on other platforms, and code modification is quite complex 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 currently 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, due to its strong binding with the simulation platform, it cannot be directly applied to other simulation platforms and actual environments. ② After the actual code is implemented, when building a large-scale test scenario, there are challenges such as time and cost, making it difficult to verify its effectiveness in real applications. SUMMARY

[0004] The purpose of the present application is to provide a lightweight code reusable framework suitable for network protocol research and development, which separates protocol logic and platform functions, enabling network protocol code to be efficiently reused on different platforms, effectively avoiding the repeated development of network protocol code. It also provides a fault injection layer for quickly building various failure scenarios.

[0005] The above technical purpose of the present application is achieved by the following technical scheme:

[0006] In a first aspect, the present application provides a lightweight code reusable framework suitable for network protocol research and development, which includes 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 the timing behavior of time-sensitive networks and other network protocols through a platform timer adaptation mechanism;

[0008] The platform-independent layer is used to perform: receiving and transmitting data packets and adding errors, maintaining a list of discrete time events, 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 a basic fault and injecting a fault descriptor corresponding to the basic fault into a data packet sent by each port;

[0010] The protocol layer is used to perform: based on the tree structure protocol layer, a new protocol is created by specifying a protocol type and binding a parent class protocol in a configuration file, and a communication interface is managed.

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

[0012] Further, the network-related functions are encapsulated twice, specifically:

[0013] The interface of the upper protocol layer is unified as a standard receiving and sending function and a register read and write function, and a platform adaptation mechanism supporting network data frame receiving and sending of different platforms is used for the lower platform.

[0014] Further, the platform timer adaptation mechanism is used to support the timing behavior of time-sensitive networks and other network protocols, specifically:

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

[0016] At runtime, the protocol layer adds or cancels a timing event by adding or deleting a timing event descriptor to the event list of the platform-independent layer, and the timing event descriptor saves the address of the corresponding callback function, which calls the corresponding function to process the corresponding event when the event triggers;

[0017] When the PILTimer object triggers, 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 functions in sequence for processing;

[0018] The platform-independent layer finds events in the event list whose trigger time is less than the current platform system time, and for all events that meet the condition, the platform-independent layer runs the callback functions in the event descriptor in sequence for event processing.

[0019] Further, the receiving and sending of the data packet are 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 performs register read and write operations;

[0022] For the sending data direction, 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 rule of the mapping table, it is delivered to the platform port and the function of sending data of the platform is called; for the receiving data direction, the platform-independent layer uses the multi-platform adaptive data receiving mechanism to receive data frames, obtains the corresponding protocol through the corresponding virtual network port and the data packet descriptor, and calls the receive function of the corresponding protocol; for the operation of the register, the ioctl method of the operating system is called, and if the bottom layer is simulation software, it is not processed.

[0023] Further, the above-mentioned protocol layer based on tree structure creates a new protocol by specifying the protocol type and binding the parent protocol in the configuration file, and manages the communication interface, specifically:

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

[0025] Periodically report the current running state 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 scene.

[0026] Further, when the above-mentioned protocol layer performs data transmission and reception, for the sending direction:

[0027] Based on the completed protocol framing, the corresponding data packet descriptor is generated, and the send method of the protocol is called;

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

[0029] For the receiving direction:

[0030] Based on the received data, the protocol type of the data packet descriptor is found through the protocol tree, and the receive method registered by the child protocol is found;

[0031] The receive method registered by the child protocol is called, and according to the protocol type of the data packet descriptor, the data to be sent is sent to the corresponding child protocol through the protocol tree.

[0032] Further, the above-mentioned fault descriptor represents 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.

[0033] Further, the above-mentioned 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, the corresponding fault descriptor is taken out from the descriptor queue and put into the current fault queue when the fault starts, and the corresponding fault descriptor is deleted from the current fault queue when the fault ends;

[0036] When the fault injection layer receives a data frame sent by the upper layer protocol, it traverses the current descriptor queue. If there is a fault descriptor for the current data frame protocol, it modifies or delays the data frame 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 this application, a method for supporting cross-platform reuse of network protocol codes is provided, which aims 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 complex 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 and maintain 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 according to an embodiment of the present invention;

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

[0044] Figure 3 Flow chart for data transceiving in the embodiment of the present application;

[0045] Figure 4 Flow chart for execution of timing event in the embodiment of the present application;

[0046] Figure 5 Flow chart for operation of protocol tree in the embodiment of the present application;

[0047] Figure 6 Fault event list in the embodiment of the present application;

[0048] Figure 7 Flow chart for insertion and deletion of fault in the embodiment of the present application. DETAILED DESCRIPTION

[0049] In order to make the objects, technical solutions and advantages of the embodiments of the present application clearer, the technical solutions in the embodiments of the present application will be described clearly and completely below with reference to the drawings in the embodiments of the present application. Obviously, the described embodiments are some but not all of the embodiments of the present application. The components of the embodiments of the present application described and shown in the drawings herein can be arranged and designed in various different configurations.

[0050] Therefore, the following detailed description of the embodiments of the present application provided in the drawings is not intended to limit the scope of the claimed present application, but only represents selected embodiments of the present application. All other embodiments obtained by those of ordinary skill in the art based on the embodiments in the present application without creative labor are within the scope of protection of the present application.

[0051] It should be noted that: similar reference numerals and letters represent similar items in the following drawings, and therefore, once an item is defined in one drawing, it does not need to be further defined and explained in subsequent drawings.

[0052] In the description of the embodiments of the present application, "a plurality of" represents at least 2.

[0053] Embodiment 1:

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

[0055] The adapter framework is used for performing secondary encapsulation on network-related functions provided by an operating system or a simulation platform, and supporting timing behaviors of time-sensitive networks and other network protocols through a platform timer adaptation mechanism.

[0056] Optionally, the network-related functions are secondarily encapsulated, and specifically:

[0057] The interface to the upper protocol layer is unified as a standard transceiving function and a register read-write function, and a platform adaptation mechanism supporting network data frame transceiving of different platforms is adopted for the lower platform.

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

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

[0060] At runtime, the protocol layer adds or cancels a timing event by adding or deleting a timing event descriptor to the event list of the platform-independent layer, and the timing event descriptor saves the address of the corresponding callback function, which calls the corresponding function to handle the corresponding event when the event triggers.

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

[0062] The platform-independent layer finds events in the event list whose trigger time is less than the current platform system time, and for all events that meet the condition, the platform-independent layer runs the callback functions in the event descriptor in sequence for event processing.

[0063] Further, the platform-independent layer is used to perform: packet transceiving and error adding, maintenance of the discrete time event list, and obtaining and modifying of the platform-independent time value.

[0064] The packet transceiving specifically includes:

[0065] The platform-independent layer creates a virtual network port and obtains a mapping table 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-write operations.

[0067] For the data sending direction, 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 rule of the mapping table, it is delivered to the platform port and the platform data sending function is called; for the data receiving direction, the platform-independent layer receives data frames using a multi-platform adapted data receiving mechanism, 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 register operation, the ioctl method of the operating system is called, and if the underlying layer is simulation software, it is not processed.

[0068] Optionally, the fault injection module is located in the platform-independent layer and is configured to perform: decomposing each fault into a basic fault, and injecting a fault descriptor corresponding to the basic fault into a data packet sent by each port.

[0069] The fault descriptor represents the port where the fault occurs, the type of protocol that has failed, 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, which includes:

[0070] The fault event after completion of initialization is put 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, the corresponding fault descriptor is taken out of the descriptor queue and put into the current fault queue at the start time of the fault, and the corresponding fault descriptor is deleted from the current fault queue at the end time of the fault;

[0072] When the fault injection layer receives a data frame issued 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] Further, the protocol layer is configured to perform: 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 related operations of the (send, receive, notify, config, driverWrite, driverRead standard interface) protocol are performed through the standard interface, which facilitates the porting and extension of the protocol.

[0074] The tree structure protocol layer is configured to perform: 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, which includes:

[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 state 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 scene.

[0077] Optionally, when the protocol layer is used for data transmission and reception, for the sending direction:

[0078] Based on the completed protocol framing, the corresponding data packet descriptor is generated, and the send method of the protocol is called;

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

[0080] For the receiving direction:

[0081] Based on the received data, the protocol type of the data packet descriptor is found through the protocol tree, and the receive method of the child protocol is registered;

[0082] The receive method of the child protocol is called, and the data to be sent is sent to the corresponding child protocol through the protocol tree according to the protocol type of the data packet descriptor.

[0083] Embodiment 2:

[0084] The reusable framework provided by the embodiments of the application is composed of the following parts, as shown in Figure 1 The adapter framework (MA: Multi-Adaptors) suitable for multiple platforms, the code-reusable framework platform-independent layer (PIL: Platform Independence Layer), the fault injection module (FIM: Faulty Injection Module), and the protocol layer based on the protocol instance tree (PIT: Protocol Instance Tree) and the protocol instance management tree (PIMT: Protocol Instance Manage Tree). The protocol entity is the code for actually implementing the protocol behavior, and the protocol layer maintains a PIT and is managed through a standard interface and a PIMT.

[0085] In the implementation, the implementation steps of the reusable framework are as shown in Figure 2 The details are as follows: 1. Initialize the MA, and determine the mechanism of receiving and sending data frames according to the platform of code compilation by using a platform adaptation mechanism; 2. Initialize the timer system, and determine the advancing mechanism of the discrete event timer according to the platform of code compilation by using a multi-platform timer adaptation mechanism; 3. The protocol layer maintains a protocol instance tree and a protocol instance management tree, and the upper and lower layer protocols communicate through the unified interface of the protocol instance tree and complete monitoring and management through the unified interface of the protocol instance management tree; 4. The fault injection module is part of the code-reusable framework platform-independent layer, and all received and sent data packets pass through this layer to implement the operation of injecting time error threshold errors to the data packets.

[0086] The lightweight code reusable framework applicable to the development of network protocols can be compatible with both an operating system and an emulation platform; in order to solve the compatibility problem, network-related functions provided by the operating system or the emulation platform are encapsulated again, the interfaces of the upper protocol layer are unified into standard receiving and sending functions, and register reading and writing functions. For the lower platform, the platform adaptation mechanism (PAM) is adopted to support the network data frame receiving and sending of different platforms.

[0087] Specifically, for the operating system, the network data frame receiving and sending capability thereof is utilized for customization; and for the emulation software, the data receiving and sending interface and the unformatted packet (UP) mechanism provided thereby are combined for corresponding adaptation. The PAM ensures the flexibility and scalability of the framework among different platforms. In addition, the framework further includes a multi-platform timer adaptation mechanism (MPTAM) to support the timing behavior (such as periodic announcement, periodic monitoring, etc.) of time-sensitive networks and other network protocols. In the specific implementation, the MPTAM can be adapted according to the characteristics of the underlying platform to ensure that it can be quickly deployed in different platforms.

[0088] Optionally, in order to adapt the code to the timer behavior of multiple platforms, the platform timer is encapsulated by the PILTimer class in the embodiment. The PILTimer is driven by the system time of the platform to implement the PILTimer by using a discrete event list. The PILTimer adopts a time event list strategy, and only one PILTimer object is needed globally, as shown in Figure 4 The flow of executing the timing event is described as follows: Figure 4

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

[0090] Step 2: In the runtime, the protocol layer adds or cancels the timing event by adding or deleting the timing event descriptor to the event list of the PIL. The timing event descriptor saves the address of the callback function, and when the event is triggered, the corresponding function can be directly called back to process the corresponding event;

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

[0092] Step 4: PIL finds events in the event list 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 function in the event descriptor in turn to process the event.

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

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

[0096] Optionally, the above-mentioned data sending and receiving process is as shown in Figure 3 , and specifically comprises:

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

[0098] Step 2: After the mapping table is established, data-related operations are performed, including protocol layer sending data, platform port receiving data, and protocol layer performing register read-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 rule of the mapping table, the data will be finally transmitted to the platform port and the platform data sending function is called; for the data receiving direction, PIL uses a multi-platform adaptive 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 the register operation, the ioctl method of the operating system is directly called, and if the underlying is simulation software, no processing is performed.

[0100] Optionally, a fault injection module is included in the PIL, which injects faults into the data packets sent by each port by decomposing the faults into basic faults and then injecting the faults into the data packets using the form of fault descriptors. The MA completes the adaptation between the PITI and the PIL, and in order to facilitate the upper application, a 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 the clock value. The system time drives the discrete event list to implement the PILTimer, and only one platform-related timer is needed globally. The corresponding service function and callback function are executed according to the arrival time, and all expired events are traversed.

[0101] Further, the above-mentioned fault injection module (FIM: Fault Injection Module); since in the protocol test stage, various network faults usually need to be constructed to verify the completeness of the protocol. In order to facilitate users to quickly deploy faults in the simulation scene, the embodiment proposes a fast fault injection (FFI: Fast Fault Injection) scheme, which covers functions such as fault generation, analysis and injection; the scheme supports users to define the required fault information through a configuration file, including the port where the fault occurs, the protocol type, the fault time, the fault type and the like. The supported basic fault types include interruption, delay and modification of data transmission and the like. Users can combine these basic types according to needs to construct more complex fault scenarios. In 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 according to the time sequence of fault occurrence, so as to facilitate the implementation of fault injection in simulation.

[0102] Wherein, each device has a corresponding fault descriptor XML, and the user describes the fault condition of each device through the fault descriptor XML. 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; and ⑥ 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 simulation, and initializes the fault event list, wherein the fault event list stores the descriptors of each fault in the order of fault start time, Figure 6 is a schematic diagram of the fault event list; Figure 7 is a fault insertion and deletion process, which is specifically described as follows:

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

[0104] Step 2: At the beginning of the fault, the corresponding fault descriptor is taken out from the fault descriptor queue and put into the current fault descriptor queue by setting a timer;

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

[0106] Step 4: When the fault injection layer receives the data frame issued by the upper layer protocol, the fault injection layer 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] Further, the above-mentioned protocol layer based on the protocol instance tree (PIT) and the protocol instance management tree (PIMT) is designed and implemented as a tree structure protocol layer which is easy to extend; the PIT creates a new protocol by specifying the protocol type and binding the parent class protocol in the configuration file, and the PIMT implements the management interface, including the registration, notification and configuration methods, and the related functions for data transmission and reception.

[0108] In the initialization phase, the PIT completes the registration of the interface function. In the running phase, the protocol instance in the PIT uses the universal packet management mechanism of multiple platforms to perform the data packet transmission and reception operation. Through the packet descriptor, the protocol layer can find the corresponding protocol from the PIT according to the transmission direction and the protocol type of the data packet and call the transmission function, so as to realize the cross-layer transmission of the data packet between the protocol layers. The PIMT realizes the monitoring and management of the protocol through the configuration and notification methods.

[0109] Optionally, the protocol tree operation process is as shown in Figure 5 , and specifically as follows:

[0110] Step 1: In the initialization phase, the protocol completes the registration of the interface function, and the initialization of the data structure required by the PIT and the current protocol is completed;

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

[0112] Transmission direction:

[0113] Step 3: After the protocol framing is completed, the corresponding 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 underlying layer receives the data, the receive method of the child protocol is found through the protocol tree according to the protocol type of the data packet descriptor.

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

[0118] The following further illustrates the reusable framework in the embodiment by examples:

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

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

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

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

[0123] Step 4: The run function of ieee8021ASD0 is called for initialization and reset, and the main state machine of the protocol is started.

[0124] Step 5: When the AS protocol layer ieee8021ASD0 needs to send a packet out 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 packet enters the send function of the PIL, the plantformTx function of the PIL is called, and then the function calls the relevant packet sending operation of OPNET, and the packet is sent out from the corresponding transmitter through the stream index number.

[0125] Step 6: When the process model of the node receives a packet, the plantformRx function of the PIL is triggered, and the packet descriptor is parsed from the Unformatted Packet of OPNET, and the received packet is passed to the receive function of the PIL. The receive function of the PIL finds that the upper layer of the PIL is the AS layer, and thus the receive function of the AS layer is called to pass the packet to the AS layer.

[0126] Step 7: When the AS layer needs to set a timer for an event, if a timer has not been registered for the event, a new timer (TimerID is specified) needs to be registered using the RegistTimer function. Then the SetTimerEvent function is used to set the trigger time for the timer.

[0127] Step 8: When the timer of the AS layer triggers, the GetTimerEvent function of the AS layer is called back to execute, and specific operations can be performed according to the TimerID of the timer in the function.

[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 application in the Linux operating system is illustrated.

[0129] Step 1: When the framework is used in the Linux operating system, the macro definition #define LINUXOS is added in main.h. Then a main function file for initializing the protocol tree and registering the callback function is written and compiled and run.

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

[0131] Step 3: Register the AS protocol in pilAPI, with 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 for initialization 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 out of the device, it can call the send function bound in the function table of the parent protocol class object (pilAPI pointer passed in the constructor) of the protocol. After the data packet is passed into the send function of PIL, the plantformTx function of PIL is called to send the data packet from the corresponding network port using socket mechanism.

[0134] Step 6: When the device receives a data packet, it triggers the plantformRx function of PIL, which performs corresponding operations according to the platform and then 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 to pass 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 has been registered for the event, a new timer (specifying TimerID) needs to be registered using the RegistTimer function. Then use the SetTimerEvent function to set the trigger time for the timer.

[0136] Step 8: When the timer of the AS layer triggers, the GetTimerEvent function of the AS layer is called back to execute, and specific operations can be performed according to the TimerID of the timer in the function.

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

[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 fault type, fault start time, fault end time, and fault offset value, etc.

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

[0140] Step 3: 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 embodiments of the present application provide an electronic device, including a memory, a processor, and a computer program stored in the memory and executable on the processor, and the processor implements the method in any one of the embodiments 1 or 2 when executing the computer program.

[0143] Embodiment 4

[0144] The embodiments of the present application provide a non-transitory computer readable storage medium, which stores computer instructions, and the computer instructions make the computer execute the method in any one of the embodiments 1.

[0145] The above detailed description of the specific implementation of the present application, the purpose, technical solutions and beneficial effects have been further described in detail, it should be understood that the above description is only a specific implementation of the present application, and is not used to limit the protection scope of the present application, any modification, equivalent replacement, improvement, etc. within the spirit and principles of the present application should be included in the protection scope of the present application.

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 timing behaviors of time-sensitive networks and other network protocols through the 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 fault descriptors corresponding to the basic faults into 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 managing the communication interface.

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 sending and receiving 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 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 an event is triggered, the corresponding function is called back to handle the corresponding event. 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; 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 function in the event descriptor in turn to process the event.

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 is 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 data sending direction, 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 data receiving direction, 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 register operations, the ioctl method of the operating system is called, and if the underlying layer is simulation software, it is not processed.

5. A lightweight code reusable framework suitable for network protocol development according to claim 1, characterized in that: Based on the tree-structured protocol layer, a new protocol is created by specifying the protocol type in the configuration file and binding the parent protocol. 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 protocol's send method; 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 the protocol type of the packet descriptor, and finds the receive method registered by the sub-protocol through the protocol tree; 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: Inject the fault descriptor corresponding to the basic fault 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, the corresponding fault descriptor is taken out from the descriptor queue and put into the current fault queue when the fault starts, and the corresponding fault descriptor is deleted from the current fault queue when the fault ends; When the fault injection layer receives a data frame sent by the upper layer protocol, it traverses the current descriptor queue. If there is a fault descriptor for the current data frame protocol, it modifies or delays the data frame 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 to 8.

Images