Transmission configuration parameter hot-reloading method and device, electronic equipment and storage medium

Abstract

The embodiment of the application provides a transmission configuration parameter hot reloading method and device, electronic equipment and storage medium, which are applied to a SIP transmission management system. By using the method, the transmission object is split into a double-layer architecture which is independently referenced but independently managed through an internal state wrapper. The transmission configuration object reference can be atomically replaced without affecting the transmission runtime state object reference, so that the transmission object can update the parameters while keeping the running state unchanged, without restarting the SIP protocol stack process, ensuring that the system service runs unaffected, and improving the user experience. In addition, through multi-dimensional substantive change detection, transmission restart can be performed only when a substantive change is detected, avoiding unnecessary transmission restart caused by configuration jitter, and improving system running stability.

Description

Technical Field

[0001] This application relates to the field of computer technology, and in particular to a method, apparatus, electronic device, and storage medium for hot reloading of transmission configuration parameters. Background Technology

[0002] In modern communication systems, the core engine of an IPPBX (Internet Protocol Private Branch Exchange) carries all signaling traffic through the SIP (Session Initiation Protocol) transport layer. Transport layer instances are bound to network addresses and ports according to protocol type (UDP (User Datagram Protocol), TCP (Transmission Control Protocol), TLS (Transport Layer Security), and WebSocket (WebSocket Protocol)), forming the foundational infrastructure of the entire communication system.

[0003] In practical applications, users frequently encounter the need to change transport layer parameters during operation and maintenance, such as TLS security certificate expiration and replacement, changes in bound addresses due to network topology adjustments, and NAT (Network Address Translation) external signaling address domain name switching. Current technologies often use restarting the entire SIP protocol process to change transport layer parameters, but restarting can cause online terminals to lose registration, call interruptions, and other issues, thus affecting the user experience. Summary of the Invention

[0004] The purpose of this application is to provide a method, apparatus, electronic device, and storage medium for hot reloading of transmission configuration parameters to improve user experience. The specific technical solution is as follows: In a first aspect of this application, a method for hot reloading transmission configuration parameters is provided, applied to a SIP transmission management system, the method comprising: Upon receiving a request to reload the transmission configuration parameters, the transmission configuration parameters are parsed field by field. Each field processor obtains the temporary state object of the current thread and writes the field parsing results into the temporary state object. The temporary state object is moved from thread-local storage to an internal state wrapper, and the reference to the thread-local storage is cleared. The internal state wrapper contains: a unique identifier for retrieving the transport object from the hash container; a change detection flag for controlling alarms for non-reloadable transports; and independently managed transport configuration object references and transport runtime state object references. The transport configuration object reference stores declarative configuration information and supports atomic replacement, while the transport runtime state object reference stores runtime resources and has an independent lifecycle. If a first transport object with the same unique identifier as the current internal state wrapper instance is detected in the hash container, the current internal state wrapper instance is used as the second transport object, and the field-level change list between the transport configuration objects of the first transport object and the second transport object is obtained through the differential comparison interface. Based on the field-level change list, substantive change detection is performed on the following: protocol type; binding address; local network access control list obtained by depth-first traversal of the linked list and comparison of the linked list length; encryption method, number of cipher suites, protocol version, client verification, server verification and client certificate requirements in TLS security parameters; cipher suite array and external media address; changes in external media address caused by domain name resolution fluctuations are not considered substantive changes. If no substantial change is detected, the transport configuration object reference of the first transport object is atomically replaced with the transport configuration object reference of the second transport object, while keeping the runtime state of the first transport object unchanged.

[0005] In one possible implementation, after performing substantive change detection on the following based on the field-level change list: protocol type; binding address; local network access control list obtained by depth-first traversal of the linked list and comparison of the linked list length; encryption method, number of cipher suites, protocol version, client authentication, server authentication, and client certificate requirements in TLS security parameters; cipher suite array; and external media address, the method further includes: If so, then the transmission will be restarted when the overload permission flag of the transmitted object indicates that overload is allowed; When the reload permission flag indicates that reload is prohibited, determine whether the change detection flag has been set; If so, maintain the original runtime state of the transmitted object and suppress repeated alarms; If not, set the change detection flag, record the alarm log, and maintain the original runtime state of the transmitted object.

[0006] In one possible implementation, the method further includes: When a primary / backup switch is detected, and the new host detects a preset recovery flag file, wherein the preset recovery flag file does not include the files corresponding to device auto-configuration transmission and push call optimization transmission; Restart the transmission for each transmission object whose reload permission flag indicates that reload is allowed.

[0007] In one possible implementation, the transmission restart includes: For the UDP transport protocol, call the UDP transport pause interface and set the socket destruction flag; Restart UDP transmission after waiting 1000 milliseconds; If the restart fails, return to restart UDP transmission until the UDP transmission restart count reaches 3; For the TCP transport protocol, call the connection factory's destroy method; After waiting 100 milliseconds, a new connection factory is created via TCP transmission initiation interface; If the restart fails, return to restart TCP transmission until the TCP transmission restart count reaches 3; For the TLS transport protocol, the connection factory's destroy method is invoked; After waiting 100 milliseconds, a new connection factory is created via the TLS transport initiation interface, and the updated certificate file, key file, and preset trust list are loaded. If the restart fails, return to restarting the TLS transport until the TLS transport restart count reaches 3; For the WebSocket transport protocol, a restart is performed via an external HTTP framework; If the restart fails, return to restart the WebSocket transmission until the WebSocket transmission has been restarted 3 times.

[0008] In one possible implementation, the method further includes: If the restart is successful, acquire the write lock on the global state container; Remove the internal state wrapper before the restart and link in the internal state wrapper after the restart; Release the write lock on the global state container.

[0009] In one possible implementation, the method further includes: When the external signaling address of the transmission object is of type domain name, a daemon thread is created; the daemon thread is used to cyclically execute the following steps 1-2 according to a preset period: Step 1: Use the address format detection function to determine whether the string corresponding to the external signaling address consists of numbers and 3 dots; if not, perform domain name resolution on the external signaling address. Step 2: If the domain name obtained in the current cycle is different from the domain name obtained in the previous cycle, then update the external address field in the runtime state object and the external media address field of the transmission object according to the domain name obtained in the current cycle.

[0010] In one possible implementation, the method further includes: Detect whether the number of objects being transmitted has changed; If so, then set the preset period to 2 seconds; If not, the preset period is set in the range of 30S-3600S.

[0011] A second aspect of this application provides a transmission configuration parameter hot reload device, applied to a SIP transmission management system, the device comprising: The temporary state object generation module is used to parse the transmission configuration parameters field by field when a transmission configuration parameter reload request is received. Each field processor obtains the temporary state object of the current thread and writes the field parsing results into the temporary state object. The temporary state object transfer module is used to transfer temporary state objects from thread-local storage to an internal state wrapper and clear the reference to thread-local storage. The internal state wrapper contains: a unique identifier for retrieving the transfer object from the hash container; a change detection flag for controlling alarms for non-reloadable transfers; and independently managed transfer configuration object references and transfer runtime state object references. The transfer configuration object reference stores declarative configuration information and supports atomic replacement, while the transfer runtime state object reference stores runtime resources and has an independent lifecycle. The field-level change list acquisition module is used to obtain the field-level change list between the transmission configuration objects of the first transmission object and the second transmission object if a first transmission object with the same unique identifier as the current internal state wrapper instance is detected in the hash container. The substantive change detection module is used to perform substantive change detection on the following based on the field-level change list: protocol type; binding address; local network access control list obtained by depth-first traversal of the linked list and comparison of the linked list length; encryption method, number of cipher suites, protocol version, client verification, server verification and client certificate requirements in TLS security parameters; cipher suite array and external media address; changes in external media address caused by domain name resolution fluctuations are not considered substantive changes; The configuration update module is used to atomically replace the transport configuration object reference of the first transport object with the transport configuration object reference of the second transport object if no substantial change is detected, while keeping the runtime state of the first transport object unchanged.

[0012] In one possible implementation, the device further includes: The transmission restart module is used to restart the transmission if the reload permission flag of the transmission object indicates that reload is allowed. The change detection flag determination module is used to determine whether the change detection flag has been set when the overload permission flag indicates that overload is prohibited. The alarm suppression module is used to maintain the original runtime state of the transmitted object and suppress repeated alarms if the alarm is detected. The alarm module is used to set the change detection flag if not, record the alarm log, and maintain the original runtime state of the transmitted object.

[0013] In one possible implementation, the device further includes: The primary / standby switchover restart module is used to restart the transmission of each transmission object that is allowed to be reloaded when a primary / standby switchover is detected and the new host detects a preset recovery flag file, wherein the preset recovery flag file does not include the files corresponding to the device automatic configuration transmission and push call optimization transmission.

[0014] In one possible implementation, the transmission restart module includes: The UDP transport protocol has a corresponding restart submodule, which is used to call the UDP transport pause interface and set the socket destruction flag for the UDP transport protocol; restart the UDP transport after waiting for 1000 milliseconds; if the restart fails, it returns to restart the UDP transport until the UDP transport restart count reaches 3. The TCP transport protocol's corresponding restart submodule is specifically used to call the connection factory's destruction method for the TCP transport protocol; after waiting for 100 milliseconds, it creates a new connection factory through the TCP transport startup interface; if the restart fails, it returns to restart TCP transport until the TCP transport restart count reaches 3; The TLS transport protocol corresponding restart submodule is specifically used to call the connection factory's destruction method for the TLS transport protocol; after waiting for 100 milliseconds, it creates a new connection factory through the TLS transport startup interface and loads the updated certificate file, key file, and preset trust list; if the restart fails, it returns to restart TLS transport until the TLS transport restart count reaches 3; The WebSocket transport protocol has a corresponding restart submodule, which is used to restart the WebSocket transport protocol via an external HTTP framework. If the restart fails, it will return to restart the WebSocket transport until the WebSocket transport has been restarted 3 times.

[0015] In one possible implementation, the device further includes: The internal state wrapper is re-linked into the module to acquire the global state container write lock if the restart is successful; the internal state wrapper before the restart is removed and the internal state wrapper after the restart is linked in; the global state container write lock is released.

[0016] In one possible implementation, the device further includes: The daemon thread creation module is used to create a daemon thread when the external signaling address of the transmission object is of type domain name. The daemon thread is used to execute the following steps 1-2 in a preset cycle: Step 1: Determine whether the string corresponding to the external signaling address consists of numbers and 3 dots using the address format detection function; if not, perform domain name resolution on the external signaling address; Step 2: If the domain name obtained in the current cycle is different from the domain name obtained in the previous cycle, update the external address field in the runtime state object and the external media address field of the transmission object according to the domain name obtained in the current cycle.

[0017] In one possible implementation, the device further includes: The preset period change module is used to detect whether the number of transmitted objects has changed; if so, the preset period is set to 2 seconds; if not, the preset period is set to the range of 30S-3600S.

[0018] In a third aspect of this application, an electronic device is provided, comprising: Memory, used to store computer programs; When a processor executes a program stored in memory, it implements the method described in the first aspect of the embodiments of this application.

[0019] In a fourth aspect of the present application, a computer-readable storage medium is provided, wherein a computer program is stored therein, and the computer program, when executed by a processor, implements the method described in the first aspect of the present application.

[0020] Compared with the prior art, the embodiments of this application have at least the following technical effects: This application provides a method, apparatus, electronic device, and storage medium for hot reloading of transmission configuration parameters, applied to a SIP transmission management system. The method includes: upon receiving a transmission configuration parameter reload request, parsing the transmission configuration parameters field by field; each field processor obtaining the temporary state object of the current thread and writing the field parsing result into the temporary state object; transferring the temporary state object from thread-local storage to an internal state wrapper and clearing the reference to the thread-local storage; the internal state wrapper includes: a unique identifier for retrieving the transmission object from a hash container; a change detection flag for controlling alarms related to non-reloadable transmission; and independently managed references to the transmission configuration object and the transmission runtime state object; the transmission configuration object reference stores declarative configuration information and supports atomic replacement, while the transmission runtime state object reference stores runtime resources and has an independent lifecycle; if a change detection flag is detected in the hash container... If a first transport object with the same unique identifier as the current internal state wrapper instance exists, this current internal state wrapper instance is used as the second transport object. A list of field-level changes between the transport configuration objects of the first and second transport objects is obtained through a differential comparison interface. Based on this list, substantive change detection is performed on the following: protocol type; binding address; local network access control list obtained through node-by-node depth traversal and list length comparison; encryption method, number of cipher suites, protocol version, client authentication, server authentication, and client certificate requirements in TLS security parameters; cipher suite array; and external media address. Changes in external media addresses caused by domain name resolution fluctuations are not considered substantive changes. If no substantive change is detected, the transport configuration object reference of the first transport object is atomically replaced with the transport configuration object reference of the second transport object, while maintaining the runtime state of the first transport object unchanged.

[0021] By applying the method of this application embodiment, the transport object is split into a two-layer architecture with independent references but independent management through an internal state wrapper. Its transport configuration object references can be atomically replaced without affecting the transport runtime state object references. This allows the transport object to update parameters while maintaining its running state without restarting the SIP protocol stack process, ensuring uninterrupted system service operation and improving user experience. Furthermore, through multi-dimensional substantial change detection, transport restarts can be performed only when substantial changes are detected, avoiding frequent unnecessary transport restarts caused by configuration jitter and improving system stability.

[0022] Of course, implementing any method of the embodiments of this application does not necessarily require achieving all of the advantages described above at the same time. Attached Figure Description

[0023] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings.

[0024] Figure 1 A flowchart of a hot reload method for transmission configuration parameters provided in an embodiment of this application; Figure 2 A timing diagram of the hot reload method for transmission configuration parameters provided in the embodiments of this application; Figure 3 A flowchart illustrating the transmission configuration restart provided in this application embodiment; Figure 4 A schematic diagram of a transmission configuration parameter hot reload device provided in an embodiment of this application; Figure 5 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Detailed Implementation

[0025] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art based on this application are within the scope of protection of this application.

[0026] In modern communication systems, the core engine of an IPPBX (Internet Protocol Private Branch Exchange) carries all signaling traffic through the SIP (Session Initiation Protocol) transport layer. Transport layer instances are bound to network addresses and ports according to protocol type (UDP (User Datagram Protocol), TCP (Transmission Control Protocol), TLS (Transport Layer Security), and WebSocket), forming the foundational infrastructure of the entire communication system. Users frequently encounter requirements for changes to transport layer parameters during operation and maintenance, such as TLS security certificate expiration and replacement, address changes due to network topology adjustments, and NAT (Network Address Translation) external signaling address domain name switching. However, the applicant has found that the transport layer management mechanisms of traditional IPPBX systems generally suffer from the following technical bottlenecks: First, once the transfer object is activated, it cannot be reconfigured.

[0027] Traditional solutions register transport objects in a "disallow overload" mode within a declarative configuration management framework. After the transport layer instance is created and bound to a port, the configuration management framework explicitly rejects any subsequent configuration update requests. When operations and maintenance personnel change TLS certificates or adjust bound addresses, the entire SIP protocol stack process must be restarted, causing all online terminals to lose registration, active calls to be interrupted, and impacting user experience.

[0028] Second, the transmission configuration is tightly coupled with the runtime state.

[0029] Traditional solutions store transport configuration parameters (protocol type, binding address, TLS settings, local network access control list) and runtime state (underlying transport handle, connection factory instance, DNS (Domain Name System) refresher reference) in the same data object.

[0030] Third, it lacks differential detection capabilities for configuration changes.

[0031] Traditional solutions do not compare the differences between old and new parameters when configuring overloads, and execute a complete transmission destruction and reconstruction process for any configuration trigger. When external signaling addresses use domain names and DNS resolution results fluctuate periodically, changes in domain name to IP (Internet Protocol) resolution are misinterpreted as configuration changes, frequently triggering unnecessary transmission restarts and severely impacting system stability.

[0032] Fourth, staticize external signaling domain name resolution.

[0033] Traditional solutions only perform DNS resolution on external signaling addresses once during system startup, and changes to DNS records during operation remain undetected. In cloud deployments and dynamic IP environments, the public IP addresses upon which NAT traversal relies may change at any time, and static resolution can easily lead to signaling routing failures.

[0034] To address at least one of the aforementioned problems, a first aspect of this application provides a method for hot reloading of transmission configuration parameters, applied to a SIP transmission management system, such as... Figure 1 As shown, the method includes: Step S101: Upon receiving a request to reload the transmission configuration parameters, the transmission configuration parameters are parsed field by field. Each field processor obtains the temporary state object of the current thread and writes the field parsing results into the temporary state object.

[0035] The transport configuration parameter reload request can be triggered when transport layer parameters need to be changed. In one example, the TLS certificate and key files can be monitored in real time through the operating system's file system event listening mechanism (such as inotify). When a certificate file is detected to have been modified or replaced, the system automatically triggers the corresponding transport configuration parameter reload request, eliminating the need for manual execution of configuration reload commands by operations personnel. This further reduces the operational complexity of certificate rotation and is suitable for scenarios integrated with automated certificate management tools (such as ACME (Automated Certificate Management Environment) protocol clients), achieving a fully automated closed loop from TLS certificate application and deployment to activation.

[0036] Transmission configuration parameters can include protocol type, binding address, TLS settings, and local network access control lists. Protocol type refers to the network communication protocol used by the service, determining how data is encapsulated, transmitted, and parsed. For example, protocol types can include TCP, UDP, TLS, and HTTP (Hypertext Transfer Protocol). Binding address refers to the IP address of the network interface the service listens on, determining where the service "receives requests from." TLS settings enable encrypted communication, preventing data eavesdropping or tampering. In an example, TLS settings might include information such as certificate origin, cipher suite, and protocol version. Local network access control lists are rule sets deployed on servers or firewalls, used to precisely control which IPs, ports, and protocols can access the service.

[0037] During field parsing, the temporary state object of the current thread (the thread used to execute transport configuration parameter overload) can be obtained by searching or creating temporary state functions for each field handler, and the obtained field parsing results can be written into the temporary state object. In one example, different fields correspond to different field handlers. For example, the field handlers may include field handlers for fields such as protocol type, binding address, TLS certificate file, key file, CA list (Certificate Authority List), cipher suite, local network ACL (Access Control List), and TLS authentication policy.

[0038] Step S102: Transfer the temporary state object from thread-local storage to the internal state wrapper and clear the reference to the thread-local storage.

[0039] In this embodiment, the SIP transport management system pre-configures an internal state wrapper to split a traditional single transport object into a two-tiered architecture that references each other but is managed independently. In one possible implementation, the internal state wrapper includes: a unique identifier for retrieving the transport object from a hash container; a change detection flag for controlling alarms related to non-reloadable transport; and independently managed transport configuration object references and transport runtime state object references. The transport configuration object reference stores declarative configuration information and supports atomic replacement, while the transport runtime state object reference stores runtime resources and has an independent lifecycle.

[0040] The hash container is a globally reference-counted hash container maintained by the system to store all internal state wrapper instances. In one example, the system maintains a globally reference-counted hash container with a prime number of buckets of 53. Transport configuration object references can be used to hold declarative configuration information such as protocol type, bound address, TLS parameters, and local network ACLs. When transport configuration parameters need to be changed, these parameters are often the ones that need to be changed. The declarative configuration information describes the final state expected by the system.

[0041] The transport runtime state object reference holds runtime resources such as the underlying transport handle (UDP) or connection factory instance (TCP / TLS), and external address DNS refresher, and has an independent lifecycle. In practical applications, the registration mode of the transport object has been switched from "disallowed overloading" to "allowed overloading" in the declarative configuration management space, enabling the transport object to participate in the overloading cycle of the configuration management framework.

[0042] To prevent thread-local memory leaks and data corruption, after transferring a temporary state object to an internal state wrapper, its reference in thread-local storage needs to be cleared. In one example, this is achieved by deleting the entry for the temporary state object in the thread-local mapping table.

[0043] By parsing field by field and clearing references to thread-local storage after the temporary state object is transferred, it can be ensured that the parsing process of each thread is completely isolated in a multi-threaded concurrent configuration loading scenario, thus avoiding cross-contamination of state.

[0044] Step S103: If a first transport object with the same unique identifier as the current internal state wrapper instance is detected in the hash container, the current internal state wrapper instance is used as the second transport object, and the field-level change list between the transport configuration objects of the first transport object and the second transport object is obtained through the differential comparison interface.

[0045] Before reloading the transmission configuration parameters, the internal state wrapper pre-splits each transmission object into a two-layer architecture that references each other but is managed independently, and stores them in a hash container. At this point, the transmission object in the hash container with the same unique identifier as the instance in the current internal state wrapper is called the first transmission object, and the temporary state object transferred from thread-local storage to the current internal state wrapper is called the second transmission object. That is, the first and second transmission objects are the transmission objects whose parameters have changed; the first transmission object is the transmission object before the change, and the second transmission object is the transmission object after the change. Through the differential comparison interface in the declarative configuration management framework, a list of field-level changes between the first and second transmission objects can be obtained, recording each field that has changed. In practical applications, if no transmission object with the same name is detected, it is marked as a new transmission object, and transmission is restarted directly without further substantive change detection.

[0046] Step S104: Based on the field-level change list, perform substantive change detection on the following: protocol type; binding address; local network access control list obtained by depth-first traversal of the linked list and comparison of the linked list length; encryption method, number of cipher suites, protocol version, client authentication, server authentication and client certificate requirements in TLS security parameters; cipher suite array and external media address.

[0047] When performing substantive change detection, changes can be considered as substantial changes to the transmitted object if: the protocol type; the bound address; the local network access control list obtained by depth-first traversal of the linked list and comparison of the list length; the encryption method, number of cipher suites, protocol version, client authentication, server authentication, and client certificate requirements in the TLS security parameters; the cipher suite array; or the external media address. Changes to the external media address caused by fluctuations in domain name resolution are not considered substantive changes. When performing detection based on a field-level change list, the corresponding fields of the above-mentioned multi-dimensional parameters can be directly obtained from the field-level change list for substantive change detection. In practical applications, if no transmitted object with the same name is detected, it is marked as a new transmitted object, and transmission is restarted directly without further substantive change detection.

[0048] In one possible implementation, when performing substantial change detection on the protocol type, it can be done by directly comparing enumerations to determine if the protocol type has changed. If so, the protocol type is considered to have undergone a substantial change. When performing substantial change detection on the binding address, it can be done by comparing the interface with the protocol stack address. If so, the binding address is considered to have changed. Here, the protocol stack address can be the address identifier used by each layer in the protocol stack.

[0049] To check for changes in the local network access control list (NAT), a depth-first traversal of the linked list can be performed, comparing the network address and subnet mask of each node and checking for unequal list lengths. If any changes are found, a substantial change is considered to have occurred. For TLS security parameter change detection, a six-field joint comparison can be performed, checking for changes in the encryption method, number of cipher suites, protocol version, client authentication, server authentication, and client certificate requirements. If any changes are found, a substantial change is considered to have occurred.

[0050] Among them, encryption method is the algorithm that protects the confidentiality of data, number of cipher suites is the total number of encryption combinations supported by the server and client through negotiation, protocol version is the protocol specification version followed for communication, client verification refers to the process by which the server verifies the identity of the client, server verification refers to the process by which the client verifies the identity of the server, and client certificate requirements refer to the requirements of the digital certificate provided by the client through identity verification.

[0051] For cipher suite arrays, changes can be determined by comparing memory blocks and verifying against the maximum length; if a change is found, it is considered a substantial change. For external media addresses, domain name resolution stability filters can be used to identify changes; if a change is found, it is considered a substantial change. An external media address refers to a Uniform Resource Locator (URL) for media resources that can be directly accessed by any client (such as a browser, mobile app, or smart device) on the public internet. It should be noted that if a change in the external media address is caused by domain name resolution, this change is not considered a substantial change.

[0052] Step S105: If no substantial change is detected, atomically replace the transport configuration object reference of the first transport object with the transport configuration object reference of the second transport object, and keep the runtime state of the first transport object unchanged.

[0053] By configuring transport objects into a two-tier architecture with independent references but independent management through an internal state wrapper, the transport configuration object references of the transport objects can be atomically replaced without affecting their transport runtime state object references. Therefore, hot reloading of transport configuration parameters can be achieved by atomically replacing the transport configuration object reference of the first transport object with the transport configuration object reference of the second transport object.

[0054] In one example, such as Figure 2The diagram shown is a timing diagram corresponding to the method in an embodiment of this application. First, during the system initialization phase, the type of the transport object is registered in the declarative configuration management framework, and its overloading is switched from prohibited to allowed, enabling it to participate in the overloading cycle. Then, a globally referenced counting hash container (prime number buckets = 53) is created in the scheduling layer of the configuration management framework. This container holds mutually referencing but independently managed two-layer architecture transport objects generated through internal state wrappers, which are maintained and managed during transport runtime.

[0055] When a configuration reload request is triggered, field-by-field parsing is initiated. A temporary state object is obtained through the thread-local storage interface in the configuration parsing engine. The parsed field values ​​are written into the temporary state object through each field processor. Then, the temporary state object is atomically transferred to the internal state wrapper, written into the global hash container, and the thread-local storage reference is cleared.

[0056] The differential comparison interface in the declarative management framework is called to obtain the list of field-level changes between the first and second transport objects with the same name; the six-dimensional state comparison function in the multi-dimensional change detection engine is used to detect changes in the above six dimensions to check whether there are any substantial changes. If not, the current runtime state is retained and the transport configuration object reference is atomically replaced.

[0057] By applying the method of this application's embodiments, the transport object is split into a two-layer architecture with independent references but independent management through an internal state wrapper. Its transport configuration object references can be atomically replaced without affecting the transport runtime state object references. This allows the transport object to update parameters while maintaining its running state without restarting the SIP protocol stack process, ensuring uninterrupted system service operation. Furthermore, through multi-dimensional substantial change detection, transport restarts can be performed only when substantial changes are detected, avoiding frequent unnecessary transport restarts caused by configuration jitter and improving system stability.

[0058] In one possible implementation, if a substantial change is detected in step S104, the transmission is restarted when the reload permission flag of the transmission object indicates that reload is allowed. When the overload permission flag indicates that overload is prohibited, check whether the change detection flag has been set. If so, maintain the original runtime state of the transmitted object and suppress repeated alarms; If not, set the change detection flag, record the alarm log, and maintain the original runtime state of the transmitted object.

[0059] In this embodiment, the registration mode of the transmission object can be pre-switched from "disable reloading" to "allow reloading" in the declarative configuration management framework according to business needs. In practical applications, whether the transmission object can be reloaded can be indicated by setting a reload permission flag. For example, a binary value can be used to indicate whether the transmission object can be reloaded. For instance, "0" indicates that the transmission object is prohibited from being reloaded, and "1" indicates that the transmission object can be reloaded.

[0060] When the reload permission flag indicates that reload is prohibited, the system transmission restart will fail, and feedback needs to be sent to the operations and maintenance personnel. At this time, it is also necessary to check whether the change detection flag has been set. If so, it means that the system has already issued an alarm, and there is no need to repeat the alarm. The change detection flag is used to indicate whether the system has issued an alarm. Whether the change detection flag is set can be understood as whether the change detection flag indicates that the system has issued an alarm notification.

[0061] If not, it means the system did not issue an alarm previously. In this case, an alarm log can be recorded to provide an alert, and the change detection flag can be set to indicate that an alarm has been issued. When system transmission restart fails, the original runtime state of the transmitted object must be maintained to ensure the normal operation of the system.

[0062] By applying the method of the embodiments of this application and setting a change detection flag when transmission restart fails, the system can avoid issuing multiple repeated alarms.

[0063] In one possible implementation, when applied to a high-availability deployment scenario, the system of this application embodiment is provided with a primary and backup dual machine, and the system integrates a primary and backup status detection interface: when the backup node detects that it is in a standby state, it skips the transmission port binding operation, thereby preventing port conflicts between the primary and backup dual machines.

[0064] When a primary / backup switch is detected, and the new host detects a preset recovery flag file, wherein the preset recovery flag file does not include the files corresponding to device auto-configuration transmission and push call optimization transmission; Restart the transmission for each transmission object whose reload permission flag indicates that reload is allowed.

[0065] The preset recovery flag file is a high-availability recovery flag file pre-determined based on business requirements. In one example, the status file used in the distributed system to identify the recovery status and trigger the automatic recovery process is used as the high-availability recovery flag file. The device auto-configuration transmission file is used to remotely configure network devices, such as enabling automatic server connection, configuration download, network login, and port mapping. The push call optimization transmission file is used to optimize call audio parameters.

[0066] By applying the method of this application embodiment, and restarting the transmission of each transmission object that is allowed to be reloaded by the reload permission flag bit during the master-slave switch, it can be ensured that the transport layer is correctly bound to the network address of the new host, and adaptive management without manual intervention can be achieved.

[0067] In one possible implementation, when a transmission restart is performed, a gradient restart or a multiple restart strategy can be used based on the protocol type. For example: For the UDP transport protocol, call the UDP transport pause interface and set the socket destruction flag; Restart UDP transmission after waiting 1000 milliseconds; If the restart fails, return to restart UDP transmission until the UDP transmission restart count reaches 3.

[0068] Among them, UDP transmission supports IPv4 (Internet Protocol version 4) and IPv6 (Internet Protocol version 6).

[0069] For the TCP transport protocol, call the connection factory's destroy method; After waiting 100 milliseconds, a new connection factory is created via TCP transmission initiation interface; If the restart fails, return to restart TCP transmission until the TCP transmission restart count reaches 3.

[0070] For the TLS transport protocol, the connection factory's destroy method is invoked; After waiting 100 milliseconds, a new connection factory is created via the TLS transport initiation interface, and the updated certificate file, key file, and preset trust list are loaded. If the restart fails, return to restarting the TLS transport until the TLS transport restart count reaches 3.

[0071] For the WebSocket transport protocol, a restart is performed via an external HTTP framework; If the restart fails, return to restart the WebSocket transmission until the WebSocket transmission has been restarted 3 times.

[0072] In large-scale deployment scenarios with multiple transport instances of the same type, this application embodiment can configure a canary reload priority weight for each transport instance. When performing a hot reload, the system sorts the instances according to their priority weights and performs the restart operation serially, one instance at a time. After each instance restarts successfully, a brief health check is performed (such as sending a SIP OPTIONS probe) to confirm that the new transport instance is working properly before processing the next instance. This strategy avoids the momentary service unavailability window caused by simultaneously restarting all transport instances, enabling a gradual canary release of transport layer configuration updates in large communication clusters, further improving service continuity during configuration changes.

[0073] In one possible implementation, it can be achieved by... Figure 3 The steps shown are for restarting transmission. First, a primary / standby status check is performed to determine if the current node is a standby node. If so, the transmission port binding operation is skipped to prevent port conflicts between the primary and standby nodes. If not, it is determined whether a high availability recovery flag file has been detected. If so, all transmission objects marked as reloadable for transmission, except for those automatically configured for transmission and push call optimization transmission files, are restarted. If no high availability recovery flag file is detected, the transmission objects are restarted.

[0074] During the transmission restart process, the transmission protocol type is first determined. If it is UDP, the UDP transmission pause interface is called and the socket destruction flag is set; after waiting 1000 milliseconds, UDP transmission is restarted. If it is TCP, the connection factory's destruction method is called; after waiting 100 milliseconds, a new connection factory is created through the TCP transmission start interface. If it is TLS, the connection factory's destruction method is called; after waiting 100 milliseconds, a new connection factory is created through the TLS transmission start interface and the updated certificate file, key file, and preset trust list are loaded. If it is WebSocket, the restart is performed through an external HTTP framework.

[0075] If the above restart fails, a three-retry loop is performed to attempt to bind the transmission port. If the binding fails, the process is delayed and then retried until the number of retries reaches three. An error log is recorded and the original transmission state is maintained. If the binding is successful, the process is determined to be successful. The global state container write lock is acquired, the old internal state wrapper is removed, the new internal state wrapper is linked in, and finally the global state container write lock is released, thus achieving successful hot reloading of the transmission object.

[0076] By applying the method of this application embodiment, by setting different restart strategies for different protocol types, and by repeatedly restarting when restart fails until the number of restarts reaches 3, the success rate of system transmission restart can be improved, and binding failure caused by port release delay can be avoided.

[0077] In one possible implementation, if the restart is successful, an atomic switch operation of removing the old state and chaining in the new state can be performed under the write lock protection of the global state container, thereby updating the state data and ensuring consistency during concurrent access. In one example: If the restart is successful, acquire the write lock on the global state container; Remove the internal state wrapper before the restart and link in the internal state wrapper after the restart; Release the write lock on the global state container.

[0078] By applying the method of this application embodiment, and performing an atomic switching operation of removing the old state and linking in the new state under the protection of the write lock of the global state container, the consistency of concurrent access can be ensured.

[0079] In one possible implementation, the embodiments of this application may further include the following steps: When the external signaling address of the transmission object is of type domain name, a daemon thread is created; the daemon thread is used to cyclically execute the following steps 1-2 according to a preset period: Step 1: Use the address format detection function to determine whether the string corresponding to the external signaling address consists of numbers and 3 dots; if not, perform domain name resolution on the external signaling address. Step 2: If the domain name obtained in the current cycle is different from the domain name obtained in the previous cycle, then update the external address field in the runtime state object and the external media address field of the transmission object according to the domain name obtained in the current cycle.

[0080] The external signaling address, in real-time communication protocols, describes the publicly accessible IP address and port combination exchanged between communicating parties through a signaling process in a NAT or firewall environment. The daemon thread is a separate daemon thread used to continuously perform domain name resolution refresh. It distinguishes between IP addresses and domain names using an address format detection function. If the string consists only of numbers and three dots, it is considered an IP address; otherwise, it is considered a domain name corresponding to its external signaling address. When maintenance personnel modify the external signaling domain name configuration, the system detects the domain name change, immediately terminates the old resolution thread, and starts a new thread, achieving immediate effect of the domain name switch.

[0081] The preset period is a pre-configurable period; in one example, the preset period is configured to be 120 seconds. In another example, the preset period can be a value within the range of 30 seconds to 3600 seconds.

[0082] In one possible implementation, the daemon thread incorporates logic for detecting the stability of the transfer object technology, namely: Detect whether the number of objects being transmitted has changed; If so, then set the preset period to 2 seconds; If not, the preset period is set in the range of 30S-3600S.

[0083] When the number of objects being transmitted changes, it indicates that the system startup loading is not complete. At this time, the daemon thread can automatically shorten the polling interval to 2 seconds to speed up the first parsing. After the count stabilizes, it will return to the normal cycle, i.e. the preset cycle.

[0084] By applying the method of this application embodiment, by setting a daemon thread and configuring a preset period, continuous refresh of domain name resolution can be achieved, enabling the system to automatically detect and update DNS record changes during operation, track changes in public network addresses in a timely manner, and ensure end-to-end reachability of SIP signaling.

[0085] A second aspect of this application provides a transmission configuration parameter hot reload device, applied to a SIP transmission management system, the device comprising: Figure 4 The structure shown is as follows: The temporary state object generation module 401 is used to parse the transmission configuration parameters field by field when a transmission configuration parameter reload request is received. Each field processor obtains the temporary state object of the current thread and writes the field parsing results into the temporary state object.

[0086] The temporary state object transfer module 402 is used to transfer temporary state objects from thread-local storage to an internal state wrapper and clear the reference to thread-local storage. The internal state wrapper includes: a unique identifier for retrieving the transfer object from the hash container; a change detection flag for controlling alarms for non-reloadable transfers; and independently managed transfer configuration object references and transfer runtime state object references. The transfer configuration object reference stores declarative configuration information and supports atomic replacement, while the transfer runtime state object reference stores runtime resources and has an independent lifecycle.

[0087] The field-level change list acquisition module 403 is used to, if a first transmission object with the same unique identifier as the current internal state wrapper instance is detected in the hash container, use the current internal state wrapper instance as the second transmission object, and obtain the field-level change list between the transmission configuration objects of the first transmission object and the second transmission object through the differential comparison interface.

[0088] The substantive change detection module 404 is used to perform substantive change detection on the following based on the field-level change list: protocol type; binding address; local network access control list obtained by depth-first traversal of the linked list and comparison of the linked list length; encryption method, number of cipher suites, protocol version, client verification, server verification and client certificate requirements in TLS security parameters; cipher suite array and external media address; changes in external media address caused by domain name resolution fluctuations are not considered substantive changes.

[0089] The configuration update module 405 is used to atomically replace the transport configuration object reference of the first transport object with the transport configuration object reference of the second transport object if no substantial change is detected, while keeping the runtime state of the first transport object unchanged.

[0090] In one possible implementation, the device further includes: The transmission restart module is used to restart the transmission if the reload permission flag of the transmission object indicates that reload is allowed. The change detection flag determination module is used to determine whether the change detection flag has been set when the overload permission flag indicates that overload is prohibited. The alarm suppression module is used to maintain the original runtime state of the transmitted object and suppress repeated alarms if the alarm is detected. The alarm module is used to set the change detection flag if not, record the alarm log, and maintain the original runtime state of the transmitted object.

[0091] In one possible implementation, the device further includes: The primary / standby switchover restart module is used to restart the transmission of each transmission object that is allowed to be reloaded when a primary / standby switchover is detected and the new host detects a preset recovery flag file, wherein the preset recovery flag file does not include the files corresponding to the device automatic configuration transmission and push call optimization transmission.

[0092] In one possible implementation, the transmission restart module includes: The UDP transport protocol has a corresponding restart submodule, which is used to call the UDP transport pause interface and set the socket destruction flag for the UDP transport protocol; restart the UDP transport after waiting for 1000 milliseconds; if the restart fails, it returns to restart the UDP transport until the UDP transport restart count reaches 3. The TCP transport protocol's corresponding restart submodule is specifically used to call the connection factory's destruction method for the TCP transport protocol; after waiting for 100 milliseconds, it creates a new connection factory through the TCP transport startup interface; if the restart fails, it returns to restart TCP transport until the TCP transport restart count reaches 3; The TLS transport protocol corresponding restart submodule is specifically used to call the connection factory's destruction method for the TLS transport protocol; after waiting for 100 milliseconds, it creates a new connection factory through the TLS transport startup interface and loads the updated certificate file, key file, and preset trust list; if the restart fails, it returns to restart TLS transport until the TLS transport restart count reaches 3; The WebSocket transport protocol has a corresponding restart submodule, which is used to restart the WebSocket transport protocol via an external HTTP framework. If the restart fails, it will return to restart the WebSocket transport until the WebSocket transport has been restarted 3 times.

[0093] In one possible implementation, the device further includes: The internal state wrapper is re-linked into the module to acquire the global state container write lock if the restart is successful; the internal state wrapper before the restart is removed and the internal state wrapper after the restart is linked in; the global state container write lock is released.

[0094] In one possible implementation, the device further includes: The daemon thread creation module is used to create a daemon thread when the external signaling address of the transmission object is of type domain name. The daemon thread is used to execute the following steps 1-2 in a preset cycle: Step 1: Determine whether the string corresponding to the external signaling address consists of numbers and 3 dots using the address format detection function; if not, perform domain name resolution on the external signaling address; Step 2: If the domain name obtained in the current cycle is different from the domain name obtained in the previous cycle, update the external address field in the runtime state object and the external media address field of the transmission object according to the domain name obtained in the current cycle.

[0095] In one possible implementation, the device further includes: The preset period change module is used to detect whether the number of transmitted objects has changed; if so, the preset period is set to 2 seconds; if not, the preset period is set to the range of 30S-3600S.

[0096] The apparatus employing embodiments of this application splits the transmission object into a two-layer architecture with independent references but independent management through an internal state wrapper. Its transmission configuration object references can be atomically replaced without affecting the transmission runtime state object references. This allows the transmission object to update parameters while maintaining its running state without restarting the SIP protocol stack process, ensuring uninterrupted system service operation and improving user experience. Furthermore, through multi-dimensional substantial change detection, transmission restarts can be performed only when substantial changes are detected, avoiding frequent unnecessary transmission restarts caused by configuration jitter and improving system stability.

[0097] In another aspect of the embodiments of this application, an electronic device is also provided, see [link to relevant documentation]. Figure 5 ,include: Memory 501 is used to store computer programs; Processor 502, when executing a program stored in memory, implements: Upon receiving a request to reload the transmission configuration parameters, the transmission configuration parameters are parsed field by field. Each field processor obtains the temporary state object of the current thread and writes the field parsing results into the temporary state object. The temporary state object is moved from thread-local storage to an internal state wrapper, and the reference to the thread-local storage is cleared. The internal state wrapper contains: a unique identifier for retrieving the transport object from the hash container; a change detection flag for controlling alarms for non-reloadable transports; and independently managed transport configuration object references and transport runtime state object references. The transport configuration object reference stores declarative configuration information and supports atomic replacement, while the transport runtime state object reference stores runtime resources and has an independent lifecycle. If a first transport object with the same unique identifier as the current internal state wrapper instance is detected in the hash container, the current internal state wrapper instance is used as the second transport object, and the field-level change list between the transport configuration objects of the first transport object and the second transport object is obtained through the differential comparison interface. Based on the field-level change list, substantive change detection is performed on the following: protocol type; binding address; local network access control list obtained by depth-first traversal of the linked list and comparison of the linked list length; encryption method, number of cipher suites, protocol version, client verification, server verification and client certificate requirements in TLS security parameters; cipher suite array and external media address; changes in external media address caused by domain name resolution fluctuations are not considered substantive changes. If no substantial change is detected, the transport configuration object reference of the first transport object is atomically replaced with the transport configuration object reference of the second transport object, while keeping the runtime state of the first transport object unchanged.

[0098] The communication bus mentioned in the above electronic devices can be a Peripheral Component Interconnect (PCI) bus or an Extended Industry Standard Architecture (EISA) bus, etc. This communication bus can be divided into address bus, data bus, control bus, etc. For ease of illustration, only one thick line is used to represent it in the diagram, but this does not mean that there is only one bus or one type of bus.

[0099] The communication interface is used for communication between the aforementioned electronic devices and other devices.

[0100] The memory may include random access memory (RAM) or non-volatile memory (NVM), such as at least one disk storage device. Optionally, the memory may also be at least one storage device located remotely from the aforementioned processor.

[0101] The processors mentioned above can be general-purpose processors, including central processing units (CPUs), network processors (NPs), etc.; they can also be 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, or discrete hardware components.

[0102] In another embodiment provided in this application, a computer-readable storage medium is also provided, which stores a computer program that, when executed by a processor, implements any of the methods described in the first aspect of the embodiments of this application.

[0103] In another embodiment provided in this application, a computer program product containing instructions is also provided, which, when run on a computer, causes the computer to implement any of the methods described in the first aspect of the embodiments of this application.

[0104] In the above embodiments, implementation can be achieved entirely or partially through software, hardware, firmware, or any combination thereof. When implemented using software, it can be implemented entirely or partially in the form of a computer program product. The computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, all or part of the processes or functions described in the embodiments of this application are generated. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions can be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, the computer instructions can be transmitted from one website, computer, server, or data center to another website, computer, server, or data center via wired (e.g., coaxial cable, fiber optic, digital subscriber line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) means. The computer-readable storage medium can be any available medium that a computer can access or a data storage device such as a server or data center that integrates one or more available media. The available medium can be a magnetic medium (e.g., floppy disk, hard disk, magnetic tape), an optical medium (e.g., DVD), or a solid-state drive (SSD), etc.

[0105] It should be noted that, in this document, relational terms such as "first" and "second" are used only to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.

[0106] The various embodiments in this specification are described in a related manner. Similar or identical parts between embodiments can be referred to mutually. Each embodiment focuses on describing the differences from other embodiments. Related parts can be found in the descriptions of the system embodiments.

[0107] The above description is merely a preferred embodiment of this application and is not intended to limit the scope of protection of this application. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application are included within the scope of protection of this application.

Claims

1. A method for hot reloading transmission configuration parameters, characterized in that, Applied to SIP transport management systems, the methods include: Upon receiving a request to reload the transmission configuration parameters, the transmission configuration parameters are parsed field by field. Each field processor obtains the temporary state object of the current thread and writes the field parsing results into the temporary state object. The temporary state object is moved from thread-local storage to an internal state wrapper, and the reference to the thread-local storage is cleared. The internal state wrapper contains: a unique identifier for retrieving the transport object from the hash container; a change detection flag for controlling alarms for non-reloadable transports; and independently managed transport configuration object references and transport runtime state object references. The transport configuration object reference stores declarative configuration information and supports atomic replacement, while the transport runtime state object reference stores runtime resources and has an independent lifecycle. If a first transport object with the same unique identifier as the current internal state wrapper instance is detected in the hash container, the current internal state wrapper instance is used as the second transport object, and the field-level change list between the transport configuration objects of the first transport object and the second transport object is obtained through the differential comparison interface. Based on the field-level change list, substantive change detection is performed on the following: protocol type; binding address; local network access control list obtained by depth-first traversal of the linked list and comparison of the linked list length; encryption method, number of cipher suites, protocol version, client verification, server verification and client certificate requirements in TLS security parameters; cipher suite array and external media address; changes in external media address caused by domain name resolution fluctuations are not considered substantive changes. If no substantial change is detected, the transport configuration object reference of the first transport object is atomically replaced with the transport configuration object reference of the second transport object, while keeping the runtime state of the first transport object unchanged.

2. The method according to claim 1, characterized in that, The changes are based on the field-level change list, including: protocol type; binding address; local network access control list obtained by depth-first traversal of the linked list and comparison of the linked list length; and encryption method, number of cipher suites, protocol version, client verification, server verification, and client certificate requirements in the TLS security parameters. After performing substantial change detection on the cipher suite array and external media address, the method further includes: If so, then the transmission will be restarted when the overload permission flag of the transmitted object indicates that overload is allowed; When the reload permission flag indicates that reload is prohibited, determine whether the change detection flag has been set; If so, maintain the original runtime state of the transmitted object and suppress repeated alarms; If not, set the change detection flag, record the alarm log, and maintain the original runtime state of the transmitted object.

3. The method according to claim 1, characterized in that, The method further includes: When a primary / backup switch is detected, and the new host detects a preset recovery flag file, wherein the preset recovery flag file does not include the files corresponding to device auto-configuration transmission and push call optimization transmission; Restart the transmission for each transmission object whose reload permission flag indicates that reload is allowed.

4. The method according to claim 2 or 3, characterized in that, The process of restarting transmission includes: For the UDP transport protocol, call the UDP transport pause interface and set the socket destruction flag; Restart UDP transmission after waiting 1000 milliseconds; If the restart fails, return to restart UDP transmission until the UDP transmission restart count reaches 3; For the TCP transport protocol, call the connection factory's destroy method; After waiting 100 milliseconds, a new connection factory is created via TCP transmission initiation interface; If the restart fails, return to restart TCP transmission until the TCP transmission restart count reaches 3; For the TLS transport protocol, the connection factory's destroy method is invoked; After waiting 100 milliseconds, a new connection factory is created via the TLS transport initiation interface, and the updated certificate file, key file, and preset trust list are loaded. If the restart fails, return to restarting the TLS transport until the TLS transport restart count reaches 3; For the WebSocket transport protocol, a restart is performed via an external HTTP framework; If the restart fails, return to restart the WebSocket transmission until the WebSocket transmission has been restarted 3 times.

5. The method according to claim 4, characterized in that, The method further includes: If the restart is successful, acquire the write lock on the global state container; Remove the internal state wrapper before the restart and link in the internal state wrapper after the restart; Release the write lock on the global state container.

6. The method according to claim 1, characterized in that, The method further includes: When the external signaling address of the transmission object is of type domain name, a daemon thread is created; the daemon thread is used to cyclically execute the following steps 1-2 according to a preset period: Step 1: Use the address format detection function to determine whether the string corresponding to the external signaling address consists of numbers and 3 dots; if not, perform domain name resolution on the external signaling address. Step 2: If the domain name obtained in the current cycle is different from the domain name obtained in the previous cycle, then update the external address field in the runtime state object and the external media address field of the transmission object according to the domain name obtained in the current cycle.

7. The method according to claim 6, characterized in that, The method further includes: Detect whether the number of objects being transmitted has changed; If so, then set the preset period to 2 seconds; If not, the preset period is set in the range of 30S-3600S.

8. A device for hot reload of transmission configuration parameters, characterized in that, The device, used in a SIP transmission management system, includes: The temporary state object generation module is used to parse the transmission configuration parameters field by field when a transmission configuration parameter reload request is received. Each field processor obtains the temporary state object of the current thread and writes the field parsing results into the temporary state object. The temporary state object transfer module is used to transfer temporary state objects from thread-local storage to an internal state wrapper and clear the reference to thread-local storage. The internal state wrapper contains: a unique identifier for retrieving the transfer object from the hash container; a change detection flag for controlling alarms for non-reloadable transfers; and independently managed transfer configuration object references and transfer runtime state object references. The transfer configuration object reference stores declarative configuration information and supports atomic replacement, while the transfer runtime state object reference stores runtime resources and has an independent lifecycle. The field-level change list acquisition module is used to obtain the field-level change list between the transmission configuration objects of the first transmission object and the second transmission object if a first transmission object with the same unique identifier as the current internal state wrapper instance is detected in the hash container. The substantive change detection module is used to perform substantive change detection on the following based on the field-level change list: protocol type; binding address; local network access control list obtained by depth-first traversal of the linked list and comparison of the linked list length; encryption method, number of cipher suites, protocol version, client verification, server verification and client certificate requirements in TLS security parameters; cipher suite array and external media address; changes in external media address caused by domain name resolution fluctuations are not considered substantive changes; The configuration update module is used to atomically replace the transport configuration object reference of the first transport object with the transport configuration object reference of the second transport object if no substantial change is detected, while keeping the runtime state of the first transport object unchanged.

9. An electronic device, characterized in that, include: Memory, used to store computer programs; A processor, when executing a program stored in memory, implements the method of claim 8.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium contains a computer program that, when executed by a processor, implements the method of claim 8.

Images