A network protocol service adaptive restart method, device, medium and program product

Abstract

The application discloses a network protocol service adaptive restart method and device, a medium and a program product, and belongs to the technical field of network management. A network event notification sent by a kernel is received through a Netlink socket; if the received network event notification is an IP address addition or change event, the current actual IP address of a target network interface is inquired through an ioctl system call, the current actual IP address is compared with an initial IP address bound when a network protocol service is started, and the restart of the network protocol service is triggered only when the two addresses are different; if the received network event notification is an IP address deletion event or a network interface deletion event, the restart of the network protocol service is directly triggered. The application solves the problem that the prior art does not design differentiated processing strategies for different types of network events, lacks a verification mechanism for IP address change events, and leads to inaccurate service restart trigger opportunity judgment.

Description

Technical Field

[0001] This invention relates to the field of network management technology, and in particular to a method, apparatus, medium, and program product for adaptive restarting of network protocol services. Background Technology

[0002] Network protocol services such as BACnet / IP need to bind to the IP address of a specific network interface during startup and send and receive broadcast messages through that address. In embedded Linux devices such as industrial IoT gateways, the IP address of the network interface changes frequently due to DHCP renewal, dial-up reconnection, link switching, etc., leading to service interruptions.

[0003] To address the aforementioned issues and the problem of service interruption caused by IP changes, solutions such as timed polling, external script triggering, and watchdog monitoring have been tried. Timed polling detects changes by periodically querying the interface IP, but the service continues to use invalid IPs within the query interval, creating blind spots. External scripts rely on network management programs to call back restart commands when the IP changes, but the timing of script triggering is limited by the implementation details of each program and cannot cover scenarios such as route switching and interface deletion. The watchdog solution triggers a forced restart by periodically probing service availability, but the probing period is usually long and abruptly interrupts existing connections.

[0004] Another technology introduces the Netlink mechanism to detect IP address changes by monitoring the kernel. However, these solutions lack differentiated processing strategies for different types of events. In real-world systems, the types of network events sent by the kernel via Netlink are diverse, including IP address additions or changes, IP address deletions, and network interface deletions. Among these, IP address addition or change events often generate invalid notifications. For example, successful DHCP renewals without a change in IP address, or changes in address tags, can all trigger this event, even though the corresponding IP address has not actually changed. Existing technologies lack verification mechanisms for different network event types, leading to inaccurate determination of service restart triggers. Summary of the Invention

[0005] The embodiments of the present invention provide a network protocol service adaptive restart method, apparatus, medium and program product, which aims to solve the problem that the prior art does not design differentiated processing strategies for different types of network events and lacks a verification mechanism for IP address change events, resulting in inaccurate judgment of service restart triggering opportunities.

[0006] To achieve the above objectives, in a first aspect, the present invention provides a network protocol service adaptive restart method, comprising the following steps: Receive network event notifications sent by the kernel via Netlink sockets; If the received network event notification is an IP address addition or change event (RTM_NEWADDR), the current actual IP address of the target network interface is queried through the ioctl system call. The current actual IP address is compared with the initial IP address bound when the network protocol service is started. The network protocol service is restarted only if the two are different. If the received network event notification is an IP address deletion event (RTM_DELADDR) or a network interface deletion event (RTM_DELLINK), the network protocol service will be restarted directly.

[0007] Furthermore, the target network interface is determined in the following way: If an explicit interface name is configured, that explicit interface will be used as the target network interface. If no explicit interface name is configured, the system enters automatic tracing mode and retrieves the current default route interface from the routing table as the target network interface.

[0008] Furthermore, if the received network event notification is a route addition event (RTM_NEWROUTE) or a route deletion event (RTM_DELROUTE), and the network protocol service is in automatic tracking mode, the tracked default route interface is dynamically updated according to the route event. When the default route interface is switched or deleted, the network protocol service is restarted.

[0009] Furthermore, when an explicit interface name is configured, it also includes: Check if the explicit interface has a PPPoE sub-interface. If it does, use the PPPoE interface as the target network interface.

[0010] Furthermore, after the network protocol service starts but before the protocol stack is initialized, a blocking and waiting step is included, specifically: The interface address lookup function is called repeatedly to check whether the target network interface has obtained a valid IPv4 address; Protocol stack initialization will only continue once a valid IPv4 address has been detected for the target network interface.

[0011] Furthermore, triggering the restart of the network protocol service includes the following steps: First, try to rebind the socket of the network protocol service to the current actual IP address without restarting the process; A process-level restart is only performed if rebinding fails.

[0012] Furthermore, the network protocol service is the BACnet / IP protocol service.

[0013] Secondly, the present invention provides a network protocol service adaptive restart apparatus, including a memory and a processor, wherein the memory stores at least one program, and the at least one program is executed by the processor to implement the network protocol service adaptive restart method as described above.

[0014] Thirdly, the present invention provides a computer-readable storage medium storing at least one program, which is executed by a processor to implement the network protocol service adaptive restart method as described above.

[0015] Fourthly, the present invention provides a computer program product, including a computer program that, when executed by a processor, implements the steps of the network protocol service adaptive restart method as described above.

[0016] The above technical solution has the following technical effects: The network event notification sent by the kernel is received via Netlink sockets. If the received network event notification is an IP address addition or change event, the current actual IP address of the target network interface is queried via an ioctl system call. The current actual IP address is compared with the initial IP address bound when the network protocol service starts. The network protocol service is restarted only if the two are different. If the received network event notification is an IP address deletion event or a network interface deletion event, the network protocol service is restarted directly. This invention solves the problem that existing technologies do not design differentiated processing strategies for different types of network events and lack a verification mechanism for IP address change events, leading to inaccurate judgment of service restart triggering opportunities. Attached Figure Description

[0017] Figure 1 This is a schematic diagram illustrating the steps of a network protocol service adaptive restart method according to an embodiment of the present invention.

[0018] Figure 2 This is a flowchart illustrating a network protocol service adaptive restart method according to an embodiment of the present invention.

[0019] Figure 3 This is a complete timing diagram illustrating the application of the network protocol service adaptive restart method according to an embodiment of the present invention to the BACnet / IP protocol service.

[0020] Figure 4 This is a schematic diagram of the structure of a network protocol service adaptive restart device according to an embodiment of the present invention. Detailed Implementation

[0021] To further illustrate the various embodiments, the present invention provides accompanying drawings. These drawings are part of the disclosure of the present invention, primarily used to illustrate the embodiments and to explain the operating principles of the embodiments in conjunction with the relevant descriptions in the specification. With reference to these drawings, those skilled in the art should be able to understand other possible implementations and the advantages of the present invention. Components in the drawings are not drawn to scale, and similar component symbols are generally used to represent similar components.

[0022] The present invention will now be further described in conjunction with the accompanying drawings and specific embodiments.

[0023] Example 1: Figure 1 This diagram illustrates the steps of an adaptive restart method for network protocol services according to an embodiment of the present invention. This method is applicable to network protocol services running on embedded Linux systems, particularly those requiring binding to a fixed IP address to send and receive broadcast messages, such as the BACnet / IP protocol service. The method uses the Netlink mechanism to monitor kernel network events in real time and adopts differentiated processing strategies for different types of events, achieving a fast and accurate response to changes in network interface IP addresses.

[0024] The adaptive restart method for network protocol services provided in this embodiment includes the following steps: determining the target network interface and blocking during the startup phase, listening to and classifying events in the Netlink monitoring thread, and triggering differentiated responses based on event types. The following is a combination of... Figure 1 Each step is explained in detail.

[0025] When the network protocol service process starts, it first needs to determine the target network interface that the service needs to monitor. This embodiment provides two interface determination modes: explicit mode and automatic tracking mode.

[0026] Specifically, the system first checks whether the BACNET_IFACE environment variable is configured. If the environment variable is configured, it enters explicit mode and uses the interface name specified by the environment variable as the target network interface.

[0027] In explicit mode, the system further checks whether a PPPoE sub-interface exists for the specified interface. Specifically, the system traverses all network interfaces prefixed with "ppp" in the ` / sys / class / net` directory to determine if a PPPoE sub-interface associated with the specified interface exists. If it does, the PPPoE sub-interface is used as the target network interface.

[0028] In explicit mode, the user-specified explicit interface might be a physical interface like eth0. However, in a PPPoE dial-up scenario, the actual exit point carrying network traffic is a virtual interface like ppp0 generated after a successful dial-up connection. If the physical interface is directly used as the target network interface, the IP address lookup in this embodiment will obtain the IP address of the physical interface instead of the PPPoE dial-up address, causing event listening and secondary verification to operate on the wrong interface. Therefore, this embodiment further defines the priority detection logic for PPPoE sub-interfaces: it checks whether a PPPoE sub-interface exists on the explicit interface. If it does, the PPPoE interface is used as the target network interface; if not, the user-specified explicit interface itself is used as the target network interface. Through this design, this embodiment can automatically identify and use the virtual interface that actually carries traffic in a PPPoE dial-up scenario, while falling back to the user-specified physical interface in non-PPPoE scenarios, ensuring the versatility of the solution in different deployment environments.

[0029] If the BACNET_IFACE environment variable is not configured, the system enters automatic tracing mode. In this mode, the system queries the Netlink routing table for the current default route interface and uses that default route interface as the target network interface. Automatic tracing mode is suitable for scenarios that require dynamic adaptation to changes in network topology, such as when gateway devices need to automatically switch between wired and cellular networks. This method enables the correct identification of interfaces to be monitored in different deployment scenarios, providing a clear execution target for subsequent event classification, IP address lookup, and secondary verification, ensuring the correct startup and operation of the entire differentiated processing flow.

[0030] After service startup but before protocol stack initialization, the target network interface may not yet have obtained a valid IPv4 address. If the protocol stack is initialized and IP address bound directly at this time, the initial IP address obtained may be invalid or empty, causing subsequent secondary verification to lose its comparison benchmark. Regardless of the event received, comparing the current actual IP with the invalid initial IP will not yield a correct judgment. Therefore, after determining the target network interface, the service process does not immediately initialize the protocol stack but enters a blocking and waiting phase. The purpose of blocking and waiting is to prevent the service from attempting to bind before the target network interface has obtained a valid IP address, which could lead to immediate failure after startup.

[0031] Specifically, the system repeatedly executes the ioctl system call, using the SIOCGIFADDR command to query whether the target network interface has obtained a valid IPv4 address. Each query operation sends the SIOCGIFADDR command to the kernel to obtain the IPv4 address currently bound to the specified network interface. If the returned address is a valid address (not 0.0.0.0 and not empty), the interface is considered ready; if the returned address is invalid or the query fails, it waits 2 seconds and then queries again. The system continues to execute the above loop until it detects that the target network interface has obtained a valid IPv4 address, or receives a process exit signal.

[0032] Once a valid IPv4 address is detected for the target network interface, the service process proceeds with protocol stack initialization. Protocol stack initialization includes creating a UDP socket, binding the socket to the IP address of the target network interface, calculating the broadcast address, and starting packet sending and receiving threads. At this point, the service enters normal operation.

[0033] Through the aforementioned blocking and waiting mechanism, this embodiment ensures that the service only starts the protocol stack when the network interface is truly available, fundamentally avoiding the problem of failure upon startup.

[0034] After the service protocol stack is initialized, the system creates a dedicated Netlink monitoring thread. This thread is responsible for continuously listening for network event notifications sent by the kernel through Netlink sockets and classifying and processing the notifications upon receipt.

[0035] Specifically, the system first creates a socket of type NETLINK_ROUTE, which is specifically used to receive notification messages related to the kernel routing subsystem. After creating the socket, the system sets the socket options using the setsockopt function and subscribes to the event groups to be listened to. In this embodiment, the system subscribes to the IPv4 address change event group (RTMGRP_IPV4_IFADDR) and the network interface status event group (RTMGRP_LINK) to receive events such as IP address additions, changes, deletions, and network interface deletions.

[0036] After the monitoring thread is created, it enters an infinite loop. Within the loop, the thread calls the `select` function to block and wait until data is available to read on the Netlink socket. When the `select` function returns and the socket is readable, the thread calls the `recv` function to read the message sent by the kernel from the socket. The read message follows the Netlink protocol format, containing an `nlmsghdr` header followed by a message payload.

[0037] Figure 2 This is a flowchart illustrating a network protocol service adaptive restart method according to an embodiment of the present invention. Figure 2 As shown, after the monitoring thread reads the Netlink message, it first parses the `nlmsg_type` field in the `nlmsghdr` structure. This field indicates the event type corresponding to the current message. Depending on the value of `nlmsg_type`, the system adopts different processing strategies, as follows: (1) Handling of IP address addition or change events (RTM_NEWADDR) When `nlmsg_type` is `RTM_NEWADDR`, it indicates that the kernel has detected a possible change in the IP address of a network interface. It's important to note that in Linux systems, the triggering scenarios for the `RTM_NEWADDR` event include, but are not limited to: a user actively adding a new IP address to the interface, a DHCP client successfully obtaining an IP address, a successful DHCP renewal, completion of IPv6 Duplicate Address Detection (DAD), and changes in address flags. In these scenarios, there are many cases where the IP address has not actually changed but the `RTM_NEWADDR` event is still triggered; these are known as false notifications.

[0038] To accurately determine whether the IP address has actually changed, this embodiment uses a two-factor authentication mechanism for the RTM_NEWADDR event instead of directly triggering a service restart.

[0039] The specific implementation of the two-factor authentication mechanism is as follows: First, the monitoring thread parses the changed network interface name from the Netlink message and determines whether the interface name matches the target network interface. If they do not match, the event is ignored, and the thread continues to wait for the next event; if they match, the thread proceeds to the secondary verification process.

[0040] In the secondary verification process, the system actively queries the kernel for the current real-time IP address of the target network interface using the SIOCGIFADDR command via the ioctl system call. This query bypasses Netlink's notification mechanism and directly reads the network interface status data stored in the kernel, thus obtaining the most accurate current IP address information.

[0041] The system compares the current actual IP address obtained from the query with the initial IP address bound when the service started. The comparison can be performed byte-by-byte by memcmp, or the IP address represented in dotted decimal can be converted to a 32-bit integer before comparison.

[0042] If the current actual IP address is the same as the initial IP address, then the RTM_NEWADDR event is determined to be a false notification, the system does not trigger any action, and the monitoring thread continues to wait for the next event.

[0043] If the current actual IP address is different from the initial IP address, it is determined that the IP address has indeed changed, and the system triggers a restart of the network protocol service.

[0044] (2) Handling of IP address deletion event (RTM_DELADDR) When nlmsg_type is RTM_DELADDR, it indicates that the kernel has detected that an IP address bound to a network interface has been deleted. For network protocol services, the deletion of its bound IP address means that the service will be unable to continue normal communication, and therefore the service needs to be restored immediately.

[0045] Unlike the RTM_NEWADDR event, the RTM_DELADDR event does not have the problem of false notifications; that is, the deletion of an IP address is a deterministic and irreversible state change. Therefore, this embodiment adopts a direct processing strategy for the RTM_DELADDR event.

[0046] Specifically, the monitoring thread parses the name of the network interface where the deletion event occurred and determines whether it is the target network interface. If so, the system directly triggers a restart of the network protocol service without requiring secondary verification.

[0047] (3) Handling of network interface deletion event (RTM_DELLINK) When nlmsg_type is RTM_DELLINK, it indicates that the kernel has detected that a network interface has been deleted. Interface deletion means that the target network interface bound to the service no longer exists, and the service must be restarted to select a new available interface.

[0048] Similar to the RTM_DELADDR event, the RTM_DELLINK event is also deterministic and requires no secondary verification. The monitoring thread parses the interface name where the deletion event occurred and determines whether it is the target network interface. If so, the system directly triggers a restart of the network protocol service.

[0049] (4) Handling of route addition events (RTM_NEWROUTE) and route deletion events (RTM_DELROUTE) When nlmsg_type is RTM_NEWROUTE or RTM_DELROUTE, and the system is currently in automatic tracing mode, this embodiment processes routing events. Specifically, the system first parses the routing table change information from the Netlink message to determine whether the default route has changed. If a switch of the default route interface or the deletion of the default route is detected, the currently tracing default route interface is updated to the new interface or invalidated, and the updated interface is used as the target network interface. Simultaneously, a restart of the network protocol service is triggered.

[0050] In automatic tracking mode, the service needs to dynamically detect changes in the default route interface. Otherwise, when the default route is switched or deleted, the service will still be bound to the original interface, causing subsequent event listening and secondary verification to apply to the wrong interface. When the default route interface is switched or deleted, the interface that the service was originally bound to may no longer have network egress capabilities. By triggering a restart, the service will re-execute the default route interface determination process and re-execute the secondary verification logic for IP address addition or change events, thereby ensuring that the service can quickly resume working on the correct network interface.

[0051] When any of the above events triggers a service restart, this embodiment provides a gradual restart mechanism to minimize the interruption of existing connections.

[0052] Specifically, when a service restart is deemed necessary, there are several ways to implement this action, each with varying impacts on service continuity. Directly performing a process-level restart would terminate the current process and restart it, causing all existing connections to be interrupted and resulting in a prolonged service recovery time. Therefore, the system first attempts to rebind the network protocol service socket to a new IP address without restarting the process. The rebinding process includes: closing the existing socket, creating a new socket, binding the new socket to the current actual IP address of the target network interface, recalculating the broadcast address, and restarting the packet sending and receiving threads.

[0053] If the above rebinding operation is successful, the service can resume operation without restarting the process. Although the established connection will be interrupted, the service itself will remain running and can quickly establish a new connection.

[0054] If the rebinding operation fails, the system will perform a process-level restart. A process-level restart includes: terminating the current process, restarting the service process, re-executing the interface determination and blocking wait process, and re-initializing the protocol stack.

[0055] After a service restart is triggered, the system can record information such as the reason for the restart, the timestamp of the restart, and the bound IP address after the restart. This information can be output through the system log, making it easier for operations and maintenance personnel to monitor network status and service operation.

[0056] Based on the above embodiments, this embodiment also provides an implementation method for multi-interface parallel monitoring, which is applicable to scenarios where gateway devices run multiple network protocol service instances simultaneously and are bound to different network interfaces respectively.

[0057] In this implementation, the system monitors multiple network interfaces simultaneously. For each network interface, the system independently executes the monitoring and processing flow of the aforementioned network protocol service adaptive restart method. When the IP address of any interface changes, the system only triggers the restart of the protocol service instance bound to that interface; service instances on other interfaces are unaffected.

[0058] Parallel monitoring of multiple interfaces can be implemented by creating an independent monitoring thread for each target network interface. Each monitoring thread is responsible for listening to network events of the corresponding interface and triggering the restart of the corresponding service instance when necessary. This approach ensures isolation between multiple service instances, preventing changes to one interface from affecting the stability of services running on other interfaces.

[0059] This embodiment specifically applies the above method to the BACnet / IP protocol service. The BACnet / IP protocol needs to bind to the IP address of a specific network interface upon startup and uses this address to send and receive broadcast messages such as Who-Is / I-Am, requiring a high degree of continuity and correctness of the IP address. When the IP address changes and the service fails to rebind in time, other BACnet clients will be unable to discover the service, leading to communication interruption. Applying the method of this embodiment to the BACnet / IP protocol can quickly trigger rebinding or restart when the IP address of the protocol service actually changes, while filtering false notifications generated by scenarios such as DHCP renewal, avoiding frequent invalid restarts, and ensuring stable service operation. It should be noted that the core mechanisms of this embodiment, such as Netlink event listening, event classification and differentiated processing, secondary ioctl verification, startup blocking wait, gradual restart, and routing event processing, do not depend on any specific attributes of the BACnet / IP protocol and are equally applicable to other protocol services that require binding to network interfaces, such as Modbus TCP and OPC UA. The use of BACnet / IP as an example here is only to demonstrate a typical application scenario of the present invention and does not constitute a limitation on the scope of protection.

[0060] Figure 3 This is a complete timing diagram illustrating the application of a network protocol service adaptive restart method according to an embodiment of the present invention to the BACnet / IP protocol service. Figure 3 As shown in the diagram, this timeline illustrates the interaction between the protocol service main process, daemon process, Netlink monitoring thread, and BACnet protocol stack, as well as the complete processing flow in two typical scenarios. Specifically, it includes: After the protocol service main process starts, it first enters a blocking wait phase, polling every 2 seconds to check if the target network interface has obtained a valid IPv4 address. Once the interface IP is ready, the `dlenv_init()` function is called to bind the socket to the interface's IP address, completing the protocol stack initialization. Subsequently, the main process starts a Netlink monitoring thread, passing the target network interface name, initial IP address, and operating mode (explicit mode or automatic tracing mode) to the thread. After this, the service enters normal operation, and the BACnet protocol stack normally sends and receives broadcast messages such as Who-Is / I-Am.

[0061] When a PPPoE disconnection and reconnection causes a genuine change in the IP address, the kernel sends an RTM_NEWADDR event. Upon receiving this event, the Netlink monitoring thread does not directly trigger a restart. Instead, it verifies the current IP address via an ioctl system call and finds that the IP is different from the initial IP. At this point, the monitoring thread calls the `trigger_exit()` function, triggering the protocol service main process to exit. After receiving the exit signal, the main process performs cleanup operations, including releasing resources, closing sockets, etc., and sets a 3-second timeout to ensure cleanup is complete. The main process then exits (exit code 0). After detecting the exit of the protocol service main process, the daemon process restarts the process. The new process re-executes the startup phase, detects the target interface, and binds to the new IP address. At this point, the service resumes operation.

[0062] When the system is in auto-tracing mode and the default routing interface switches from eth0 to ppp0, the kernel sends an RTM_NEWROUTE event. Upon receiving this event, the Netlink monitoring thread determines that the default routing interface has changed. Unlike scenario one, the routing event does not require secondary verification; the monitoring thread directly calls `trigger_exit()`, triggering the protocol service main process to exit. After the main process performs cleanup and exits, the daemon process restarts. Once the new process starts, because it is in auto-tracing mode, it will re-query the current default routing interface and bind to the IP address of that interface. Through this process, the service can automatically switch to the correct network interface to work following the default route change.

[0063] Figure 3 This invention demonstrates the design philosophy of employing differentiated processing strategies for different types of events: For IP address addition or change events (RTM_NEWADDR), a two-factor authentication mechanism is used, triggering exit and restart only when the IP address actually changes; for route addition events (RTM_NEWROUTE), no authentication is required when switching routes via the default interface, directly triggering exit and restart. Both scenarios ultimately achieve service recovery through exit and daemon restart, ensuring service continuity and reliability.

[0064] Example 2: Figure 4 This is a schematic diagram of the network protocol service adaptive restart device in one embodiment of the present invention, as shown below. Figure 4 As shown, the device includes a processor 401, a memory 402, a bus 403, and a computer program stored in the memory 402 and executable on the processor 401. The processor 401 includes one or more processing cores. The memory 402 is connected to the processor 401 via the bus 403. The memory 402 is used to store program instructions. When the processor executes the computer program, it implements the steps in the above-described method embodiment of Embodiment 1 of the present invention.

[0065] Furthermore, as an executable solution, the network protocol service adaptive restart device can be a computer unit, which can be a computing device such as a desktop computer, laptop, handheld computer, or cloud server. The computer unit may include, but is not limited to, a processor and memory. Those skilled in the art will understand that the above-described computer unit structure is merely an example and does not constitute a limitation on the computer unit. It may include more or fewer components, or combine certain components, or use different components. For example, the computer unit may also include input / output devices, network access devices, buses, etc., and this embodiment of the invention does not limit this.

[0066] Furthermore, as an executable solution, the processor can be a Central Processing Unit (CPU), or other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. The general-purpose processor can be a microprocessor or any conventional processor, etc. The processor is the control center of the computer unit, connecting various parts of the entire computer unit via various interfaces and lines.

[0067] The memory can be used to store the computer programs and / or modules. The processor implements various functions of the computer unit by running or executing the computer programs and / or modules stored in the memory and by calling data stored in the memory. The memory may mainly include a program storage area and a data storage area. The program storage area may store the operating system and at least one application program required for a function; the data storage area may store data created based on the use of the mobile phone, etc. In addition, the memory may include high-speed random access memory and may also include non-volatile memory, such as hard disk, RAM, plug-in hard disk, SmartMediaCard (SMC), Secure Digital (SD) card, FlashCard, at least one disk storage device, flash memory device, or other volatile solid-state storage device.

[0068] Example 3: The present invention also provides a computer-readable storage medium storing a computer program, which, when executed by a processor, implements the steps of the methods described in the embodiments of the present invention.

[0069] If the modules / units integrated in the computer unit are implemented as software functional units and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, all or part of the processes in the methods of the above embodiments can also be implemented by a computer program instructing related hardware. The computer program can be stored in a computer-readable storage medium, and when executed by a processor, it can implement the steps of the various method embodiments described above. The computer program includes computer program code, which can be in the form of source code, object code, executable files, or certain intermediate forms. The computer-readable medium can include: any entity or device capable of carrying the computer program code, recording media, USB flash drives, portable hard drives, magnetic disks, optical disks, computer memory, read-only memory (ROM), random access memory (RAM), and software distribution media, etc. It should be noted that the content contained in the computer-readable medium can be appropriately increased or decreased according to the requirements of legislation and patent practice in the jurisdiction.

[0070] Example 4: The present invention also provides a computer program product, including a computer program that, when executed by a processor, implements the steps of the network protocol service adaptive restart method as described above.

[0071] Although the invention has been specifically shown and described in conjunction with preferred embodiments, those skilled in the art should understand that various changes in form and detail may be made to the invention without departing from the spirit and scope of the invention as defined in the appended claims, all of which shall be within the scope of protection of the invention.

Claims

1. A method for adaptive restarting of network protocol services, characterized in that, Includes the following steps: Receive network event notifications sent by the kernel via Netlink sockets; If the received network event notification is an IP address addition or change event, the current actual IP address of the target network interface is queried through the ioctl system call. The current actual IP address is compared with the initial IP address bound when the network protocol service is started. The network protocol service is restarted only if the two are different. If the received network event notification is an IP address deletion event or a network interface deletion event, the network protocol service will be restarted directly.

2. The network protocol service adaptive restart method according to claim 1, characterized in that, The target network interface is determined in the following way: If an explicit interface name is configured, that explicit interface will be used as the target network interface. If no explicit interface name is configured, the system enters automatic tracing mode and retrieves the current default route interface from the routing table as the target network interface.

3. The network protocol service adaptive restart method according to claim 2, characterized in that, If the received network event notification is a route addition event or a route deletion event, and the network protocol service is in automatic tracking mode, the tracked default route interface is dynamically updated according to the route event. When the default route interface is switched or deleted, the network protocol service is restarted.

4. The network protocol service adaptive restart method according to claim 2, characterized in that, When an explicit interface name is configured, it also includes: Check if the explicit interface has a PPPoE sub-interface. If it does, use the PPPoE interface as the target network interface.

5. The network protocol service adaptive restart method according to claim 1, characterized in that, After the network protocol service starts but before the protocol stack is initialized, there is also a blocking and waiting step, which includes: The interface address lookup function is called repeatedly to check whether the target network interface has obtained a valid IPv4 address; Protocol stack initialization will only continue once a valid IPv4 address has been detected for the target network interface.

6. The network protocol service adaptive restart method according to claim 1, characterized in that, The process of triggering the restart of the network protocol service includes the following steps: First, try to rebind the socket of the network protocol service to the current actual IP address without restarting the process; A process-level restart is only performed if rebinding fails.

7. The network protocol service adaptive restart method according to claim 1, characterized in that, The network protocol service is the BACnet / IP protocol service.

8. A network protocol service adaptive restart device, characterized in that, The device includes a memory and a processor, wherein the memory stores at least one program, which is executed by the processor to implement the network protocol service adaptive restart method as described in any one of claims 1-7.

9. A computer-readable storage medium, characterized in that, The storage medium stores at least one program, which is executed by a processor to implement the network protocol service adaptive restart method as described in any one of claims 1-7.

10. A computer program product, comprising a computer program, characterized in that, When the computer program is executed by the processor, it implements the steps of the network protocol service adaptive restart method as described in any one of claims 1-7.

Images