A secure gateway signaling communication method, system, device and storage medium
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- WUHAN CITMS TECH CO LTD
- Filing Date
- 2026-05-21
- Publication Date
- 2026-06-19
Smart Images
Figure CN122247939A_ABST
Abstract
Description
Technical Field
[0001] This invention relates to the fields of network communication and video security technology, and in particular to a security gateway signaling communication method, system, device and storage medium. Background Technology
[0002] The "Technical Requirements for Information Security of Public Security Video Surveillance Networks" sets forth stringent signaling interaction requirements for secure access, key negotiation, device directory synchronization, and streaming media control of video surveillance networks. As the core hub between the platform and front-end devices / lower-level platforms, the security gateway must continuously handle various signaling types, including heartbeat keep-alive, real-time control, batch directory synchronization, log reporting, and encrypted key exchange.
[0003] In existing technologies, gateway backends often use a single fixed-size thread pool or an indiscriminate queue to process all signaling packets read from Netty channels. This architecture has the following drawbacks: 1. Priority inversion: Low-priority logs or batch synchronization signaling may block high-priority real-time control or key negotiation signaling, resulting in service response delays or even timeouts.
[0004] 2. Lack of adaptive flow control: Sudden signaling surges can easily cause the thread pool queue to fill up, triggering RejectedExecutionException or memory overflow. The traditional approach is to directly disconnect the Transmission Control Protocol (TCP) connection, which undermines network stability.
[0005] 3. Poor routing scalability: Traditional switch-case massive distribution logic has high coupling, and adding new signaling types requires modification of the core routing code, violating the open / closed principle.
[0006] Therefore, how to improve the stability and real-time performance of gateways under high concurrency, weak network and abnormal scenarios has become an urgent problem to be solved.
[0007] The above content is only used to help understand the technical solution of the present invention and does not represent an admission that the above content is prior art. Summary of the Invention
[0008] The main objective of this invention is to provide a secure gateway signaling communication method, system, device, and storage medium, aiming to solve the technical problem of how to improve the stability and real-time performance of gateways under high concurrency, weak network, and abnormal scenarios.
[0009] To achieve the above objectives, the present invention provides a secure gateway signaling communication method, the secure gateway signaling communication method comprising: Receive signaling messages from the Netty channel, parse the instruction code in the signaling message header, and map the instruction code to a preset signaling priority level; According to the preset signaling priority level, the RunnableTask task corresponding to the signaling message is submitted to the matching thread pool; When the RunnableTask is executed in the matching thread pool, the signaling message is routed to the corresponding business executor to complete the protocol interaction through the pre-registered message processor mapping table.
[0010] Optionally, the step of parsing the instruction code in the signaling message header and mapping the instruction code to a preset signaling priority level includes: The PriorityExecutorManager.getPriority() method is called to parse the signaling message header and obtain the instruction code characteristics; Based on the instruction code features, a preset signaling priority level is matched using a preset level mapping table, where there is a one-to-one correspondence between the instruction code features and the preset signaling priority level.
[0011] Optionally, submitting the RunnableTask corresponding to the signaling message to the matching thread pool according to the signaling priority level includes: The queue length corresponding to the matching thread pool is obtained based on the signaling priority level; Determine whether the queue length meets the queue adjustment conditions corresponding to the matched thread pool; If not, the RunnableTask corresponding to the signaling message is submitted to the matching thread pool.
[0012] Optionally, after determining whether the queue length meets the queue adjustment conditions corresponding to the matched thread pool, the method further includes: If so, then the matched thread pool will be subjected to queue flow control processing through a differentiated backpressure flow control strategy.
[0013] Optionally, the step of performing queue flow control processing on the matched thread pool using a differentiated backpressure flow control strategy includes: When the thread pool is a high-priority thread pool or a normal thread pool, TCP layer backpressure is triggered, and the queue length is polled based on the exponential backoff check mechanism until the queue length is less than the preset low watermark threshold, then the overload is relieved and data reading is resumed.
[0014] Optionally, the step of performing queue flow control processing on the matched thread pool using a differentiated backpressure flow control strategy further includes: When the thread pool is a low-priority thread pool, determine the maximum capacity of the low-priority thread pool; The packet loss rate is calculated using a dynamic linear probability packet loss formula based on the maximum capacity and the queue length. Based on the packet loss rate, queue flow control is performed on the matched thread pool.
[0015] Optionally, the dynamic linear probability packet loss formula is:
[0016] In the formula, For packet loss rate, The length of the queue. Maximum capacity.
[0017] Furthermore, to achieve the above objectives, the present invention also proposes a secure gateway signaling communication system, the secure gateway signaling communication system comprising: The mapping module is used to receive signaling messages from the Netty channel, parse the instruction codes in the signaling message header, and map the instruction codes to a preset signaling priority level. The matching module is used to submit the RunnableTask corresponding to the signaling message to the matching thread pool according to the preset signaling priority level. The interaction module is used to route the signaling message to the corresponding business executor to complete the protocol interaction when the RunnableTask enters the matching thread pool for execution, through a pre-registered message processor mapping table.
[0018] Furthermore, to achieve the above objectives, the present invention also proposes a security gateway signaling communication device, the device comprising: a memory, a processor, and a security gateway signaling communication program stored in the memory and executable on the processor, the security gateway signaling communication program being configured to implement the steps of the security gateway signaling communication method as described above.
[0019] Furthermore, to achieve the above objectives, the present invention also proposes a storage medium storing a security gateway signaling communication program, wherein the security gateway signaling communication program, when executed by a processor, implements the steps of the security gateway signaling communication method as described above.
[0020] This invention first receives signaling messages from the Netty channel, parses the instruction codes in the signaling message header, and maps the instruction codes to a preset signaling priority level. Then, according to the preset signaling priority level, it submits the RunnableTask corresponding to the signaling message to a matching thread pool. Subsequently, when the RunnableTask enters the matching thread pool for execution, the signaling message is routed to the corresponding business executor to complete the protocol interaction through a pre-registered message processor mapping table. This invention achieves zero-latency guarantee for high-priority signaling, flexible degradation for medium- and low-priority signaling, and adaptive backpressure control for bursty traffic, thereby improving the stability and real-time performance of the gateway under high concurrency, weak network, and abnormal scenarios. Attached Figure Description
[0021] Figure 1 This is a schematic diagram of the structure of a security gateway signaling communication device in the hardware operating environment involved in the embodiments of the present invention; Figure 2 This is a flowchart illustrating the first embodiment of the secure gateway signaling communication method of the present invention; Figure 3 This is a schematic diagram of the multi-level priority thread pool scheduling and rejection policy of the first embodiment of the secure gateway signaling communication method of the present invention; Figure 4 This is a structural block diagram of the first embodiment of the security gateway signaling communication system of the present invention.
[0022] The realization of the objective, functional features and advantages of the present invention will be further explained in conjunction with the embodiments and with reference to the accompanying drawings. Detailed Implementation
[0023] It should be understood that the specific embodiments described herein are for illustrative purposes only and are not intended to limit the scope of the invention.
[0024] Reference Figure 1 , Figure 1 This is a schematic diagram of the end-to-end robust time synchronization device structure of the Advanced Driver Assistance Systems (ADAS) hardware operating environment involved in the embodiments of the present invention.
[0025] like Figure 1As shown, the security gateway signaling communication device may include: a processor 1001, such as a central processing unit (CPU), a communication bus 1002, a user interface 1003, a network interface 1004, and a memory 1005. The communication bus 1002 is used to enable communication between these components. The user interface 1003 may include a display screen or an input unit such as a keyboard; optionally, the user interface 1003 may also include a standard wired interface or a wireless interface. The network interface 1004 may optionally include a standard wired interface or a wireless interface (such as a Wireless-Fidelity (Wi-Fi) interface). The memory 1005 may be high-speed random access memory (RAM) or stable non-volatile memory (NVM), such as a disk drive. Optionally, the memory 1005 may also be a storage system independent of the aforementioned processor 1001.
[0026] Those skilled in the art will understand that Figure 1 The structure shown does not constitute a limitation on the security gateway signaling communication device and may include more or fewer components than shown, or combine certain components, or have different component arrangements.
[0027] like Figure 1 As shown, the memory 1005, which serves as a storage medium, may include an operating system, a network communication module, a user interface module, and a security gateway signaling communication program.
[0028] exist Figure 1 In the security gateway signaling communication device shown, the network interface 1004 is mainly used for data communication with the network server; the user interface 1003 is mainly used for data interaction with the user; the processor 1001 and the memory 1005 in the security gateway signaling communication device of the present invention can be set in the security gateway signaling communication device, and the security gateway signaling communication device calls the security gateway signaling communication program stored in the memory 1005 through the processor 1001 and executes the security gateway signaling communication method provided in the embodiment of the present invention.
[0029] This invention provides a secure gateway signaling communication method, referring to... Figure 2 and Figure 3 , Figure 2 This is a flowchart illustrating the first embodiment of the secure gateway signaling communication method of the present invention. Figure 3 This is a schematic diagram of the multi-level priority thread pool scheduling and rejection policy flow of the first embodiment of the secure gateway signaling communication method of the present invention.
[0030] In this embodiment, the security gateway signaling communication method includes the following steps: S1, receive signaling messages from the Netty channel, parse the instruction code in the signaling message header, and map the instruction code to a preset signaling priority level.
[0031] It is easy to understand that the execution subject of this embodiment can be a security gateway signaling communication system with functions such as data processing, network communication and program execution, or other computer devices with similar functions. This embodiment does not limit it.
[0032] Furthermore, the process of parsing the instruction code in the signaling message header and mapping the instruction code to the preset signaling priority level is as follows: the PriorityExecutorManager.getPriority() method is called to parse the signaling message header and obtain the instruction code characteristics; based on the instruction code characteristics, the preset signaling priority level is matched with the preset level mapping relationship table, and there is a one-to-one correspondence between the instruction code characteristics and the preset signaling priority in the preset level mapping relationship table.
[0033] The signaling message is GB35114 signaling message; the preset signaling priority level can be P0 critical level, P1 real-time level, P2 normal level or P3 background level.
[0034] In the specific implementation, after the gateway backend obtains the MessageProtocol message through the Netty decoder, it calls the PriorityExecutorManager.getPriority() method. Based on the characteristics of the GB35114 instruction codes, they are classified as follows: CMD_PING, CMD_LOGIN, etc., are mapped to P0 / P1 to ensure connection survival and real-time control; CMD_CATALOG_SYNC, CMD_REQUEST_CATALOG_XML, etc., are mapped to P2 for routine business such as directory synchronization; CMD_ALARM_NOTIFY, CMD_MOBILE_SUB, etc., are mapped to P3, which are asynchronous and discardable background events.
[0035] Each priority task is encapsulated as a RunnableTask, bound to a ChannelHandlerContext and a timestamp. Upon submission, the task is routed to the corresponding thread pool based on getExecutor(). The P1 thread pool has a core and maximum thread count of 20 and uses a SynchronousQueue. Upon rejection, `task.runInIoThread()` is called, and execution is redirected to the Netty IO thread via `ctx.executor().execute(this)`.
[0036] The P2 thread pool has 50 cores / maximum 100 threads and a queue capacity of 2000 using an ArrayBlockingQueue. Upon rejection, task.reject() is called, returning a NORMAL_QUEUE_FULL state.
[0037] The P3 thread pool has 50 cores / maximum 100 threads and a PriorityBlockingQueue with a queue capacity of 5000. The comparator logic is as follows: The `Comparator.comparingInt(t->t.priority.getValue()).thenComparingLong(t->-t.timestamp)` method ensures that newer tasks take precedence. When the queue is full, `poll()` removes the oldest task from the front of the queue and then retryes `execute(r)`.
[0038] S2, according to the preset signaling priority level, submit the RunnableTask corresponding to the signaling message to the matching thread pool.
[0039] Furthermore, the queue length corresponding to the matching thread pool is obtained according to the signaling priority level; it is determined whether the queue length meets the queue adjustment conditions corresponding to the matching thread pool; if not, the RunnableTask task corresponding to the signaling message is submitted to the matching thread pool; if so, the matching thread pool is subjected to queue flow control processing through a differentiated backpressure flow control strategy.
[0040] It should be noted that P0 critical level corresponds to IO thread, P1 real-time level corresponds to high-priority thread pool, P2 normal level corresponds to normal thread pool, and P3 background level corresponds to low-priority thread pool.
[0041] It should also be understood that P0 critical level: does not enter the thread pool, and directly executes the response synchronously by the Netty IO thread; the queue adjustment condition for high-priority thread pool or normal thread pool is: set a preset high-water threshold (i.e., queue full value), detect the queue length (i.e., P1 queue length or P2 queue length) in real time, and trigger queue adjustment when the queue length is greater than or equal to the queue full value; the queue adjustment condition for low-priority thread pool is: trigger queue adjustment when the queue length (P3 queue length) is greater than a percentage of the maximum capacity of the low-priority thread pool, and the percentage of the maximum capacity is user-defined.
[0042] Furthermore, the queue flow control process for the matched thread pool using the differentiated backpressure flow control strategy is as follows: when the thread pool is a high-priority thread pool or a normal thread pool, TCP layer backpressure is triggered, and the queue length is polled based on the exponential backoff check mechanism until the queue length is less than the preset low watermark threshold, then the overload is relieved and data reading is resumed.
[0043] The exponential backoff check mechanism polls the queue length using a delay period of 100ms → 200ms → 400ms → 1000ms.
[0044] Furthermore, the processing method of performing queue flow control on the matched thread pool through differentiated backpressure flow control strategy can also be as follows: when the thread pool is a low-priority thread pool, determine the maximum capacity of the low-priority thread pool; calculate the packet loss rate based on the maximum capacity and queue length using a dynamic linear probability packet loss formula; and perform queue flow control on the matched thread pool based on the packet loss rate.
[0045] The formula for dynamic linear probability packet loss is:
[0046] In the formula, For packet loss rate, The length of the queue. Maximum capacity.
[0047] In the specific implementation, a flow control state machine is maintained for each client connection to record the autoRead status, pause time, and number of pauses. When the queue length of P1 or P2 is greater than or equal to the full queue value, config().setAutoRead(false) is executed asynchronously through Netty EventLoop to trigger TCP layer backpressure. An exponential backoff check mechanism is started, polling the queue length with a delay period of 100ms→200ms→400ms→1000ms. When the length is lower than the corresponding preset low watermark threshold, config().setAutoRead(true) is executed asynchronously to resume reading. The preset low watermark threshold is also user-defined.
[0048] When the length of the P3 queue is greater than 70% of the maximum capacity, the dynamic drop rate is calculated according to the dynamic linear probability packet loss formula, with an upper limit of 90%. The decision on whether to drop the current P3 packet is made by comparing random numbers.
[0049] In this embodiment, FlowControlManager.gentleCheck() intercepts before the task is enqueued. A ConcurrentHashMap<String, FlowControlState> is maintained to record the connection states of each. When the length of the P1 queue or the P2 queue is greater than or equal to the preset high watermark threshold of 800, the autoReadState is changed from RESUMED to PAUSING through CAS, and ctx.channel().config().setAutoRead(false) is executed in the Netty EventLoop, triggering the TCP receive window to shrink. Subsequently, scheduleResumeCheck() is called to start an exponential backoff timer (initially 100 ms, doubling each time, with an upper limit of 1000 ms). If the P1 queue < 300 and the state is PAUSED during each check, autoRead(true) is restored through CAS. When the P3 queue > 7000 (70% of the maximum capacity of 10000), the discard rate is calculated. If Math.random() < discardRate, the message is directly discarded and returned as false, without occupying the thread pool resources.
[0050] S3. When the RunnableTask enters the corresponding thread pool for execution, the signaling message is routed to the corresponding service executor through the pre-registered message handler mapping table to complete the protocol interaction.
[0051] It should be noted that the pre-registered message handler mapping table is implemented using a concurrent hash table, with the key value being the signaling instruction code enumeration and the value being the functional interface processor. During distribution, the corresponding service method is directly called by looking up the table, eliminating conditional branch judgments.
[0052] In a specific implementation, a static registry is constructed using ConcurrentHashMap<ReciveMessageEnum, MessageHandler>; each instruction code is bound to the corresponding service executor method through the Java functional interface MessageHandler; during distribution, the processor is directly obtained by looking up the table for execution, eliminating the traditional switch-case branch judgments and supporting runtime dynamic expansion.
[0053] In this embodiment, MessageDispatcher is injected during Spring initialization via the @Autowired constructor. It calls registerHandlers() to map the ReciveMessageEnum enumeration to the corresponding MessageHandlerLambda expression and stores it in a static ConcurrentHashMap. After receiving a message, the Netty business handler calls MessageDispatcher.dispatch(ctx, message), first filtering unknown commands and P0 heartbeats, then using handlers.get(msgType) to obtain the handler and execute handle(). Exceptions are uniformly captured and their TraceIds are recorded to prevent single points of failure from causing thread pool thread exits.
[0054] In this embodiment, it should also be noted that connection-level task security cleanup is performed: when a specified client connection is lost or a SIP session is cancelled, the queues of each thread pool are traversed, and the pending tasks associated with the client are safely removed by comparing the Channel context attribute identifier bound to the task.
[0055] Connection-level task security cleanup specifically includes: The thread pool queue is safely traversed using an Iterator to avoid ConcurrentModificationException; the ChannelHandlerContext bound to the task is extracted, and the pre-stored client identifier attribute in the Channel is obtained; if the identifier matches the client to be cleaned up, Iterator.remove() is called to remove the task and the removal count is incremented; after cleanup, the resources occupied by the old connection are released and the platform online status cache is reset.
[0056] In the actual implementation, when the SIP session is cancelled or the TCP connection is closed, ConnectionManager.cleanupSipConnection() calls PriorityExecutorManager.clearSipRelatedTasks(clientKey).
[0057] The method internally iterates through the Iterators of the three queues P1, P2, and P3, calling isSipRelatedTask() for comparison: if the task is a RunnableTask instance, it extracts its ctx.channel().attr(NettyConstants.CLIENT_KEY).get(); if it matches the target clientKey, it executes iterator.remove(). This process is thread-safe, requires no locking, and outputs a log of the removal count for each priority level after cleanup.
[0058] In this embodiment, signaling messages from the Netty channel are first received. The instruction codes in the signaling message header are parsed, and the instruction codes are mapped to a preset signaling priority level. Then, according to the preset signaling priority level, the RunnableTask corresponding to the signaling message is submitted to the matching thread pool. Subsequently, when the RunnableTask enters the matching thread pool for execution, the signaling message is routed to the corresponding service executor to complete the protocol interaction through a pre-registered message processor mapping table. This embodiment achieves zero-latency guarantee for high-priority signaling, flexible degradation for medium- and low-priority signaling, and adaptive backpressure control for bursty traffic, thereby improving the stability and real-time performance of the gateway under high concurrency, weak network, and abnormal scenarios.
[0059] Reference Figure 4 , Figure 4 This is a structural block diagram of the first embodiment of the security gateway signaling communication system of the present invention.
[0060] like Figure 4 As shown, the security gateway signaling communication system proposed in this embodiment of the invention includes: The mapping module 4001 is used to receive signaling messages from the Netty channel, parse the instruction code in the header of the signaling message, and map the instruction code to a preset signaling priority level. The matching module 4002 is used to submit the RunnableTask corresponding to the signaling message to the matching thread pool according to the preset signaling priority level. The interaction module 4003 is used to route the signaling message to the corresponding business executor to complete the protocol interaction when the RunnableTask task enters the matching thread pool for execution, through a pre-registered message processor mapping table.
[0061] Other embodiments or specific implementations of the security gateway signaling communication system of the present invention can be found in the above-described method embodiments, and will not be repeated here.
[0062] It should be noted that, in this document, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or system 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 system. Unless otherwise specified, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or system that includes that element.
[0063] The sequence numbers of the above embodiments of the present invention are for descriptive purposes only and do not represent the superiority or inferiority of the embodiments.
[0064] Through the above description of the embodiments, those skilled in the art can clearly understand that the methods of the above embodiments can be implemented by means of software plus necessary general-purpose hardware platforms. Of course, they can also be implemented by hardware, but in many cases the former is a better implementation method. Based on this understanding, the technical solution of the present invention, or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product is stored in a storage medium (such as read-only memory / random access memory, magnetic disk, optical disk) and includes several instructions to cause a terminal device (which may be a mobile phone, computer, server, or network device, etc.) to execute the methods described in the various embodiments of the present invention.
[0065] The above are merely preferred embodiments of the present invention and do not limit the scope of the patent. Any equivalent structural or procedural transformations made based on the description and drawings of the present invention, or direct or indirect applications in other related technical fields, are similarly included within the scope of patent protection of the present invention.
Claims
1. A secure gateway signaling communication method, characterized in that, The method includes the following steps: Receive signaling messages from the Netty channel, parse the instruction code in the signaling message header, and map the instruction code to a preset signaling priority level; According to the preset signaling priority level, the RunnableTask task corresponding to the signaling message is submitted to the matching thread pool; When the RunnableTask is executed in the matching thread pool, the signaling message is routed to the corresponding business executor to complete the protocol interaction through the pre-registered message processor mapping table.
2. The method as described in claim 1, characterized in that, The process of parsing the instruction code in the signaling message header and mapping the instruction code to a preset signaling priority level includes: The PriorityExecutorManager.getPriority() method is called to parse the signaling message header and obtain the instruction code characteristics; Based on the instruction code features, a preset signaling priority level is matched using a preset level mapping table, where there is a one-to-one correspondence between the instruction code features and the preset signaling priority level.
3. The method as described in claim 1, characterized in that, The step of submitting the RunnableTask corresponding to the signaling message to the matching thread pool according to the signaling priority level includes: The queue length corresponding to the matching thread pool is obtained based on the signaling priority level; Determine whether the queue length meets the queue adjustment conditions corresponding to the matched thread pool; If not, the RunnableTask corresponding to the signaling message is submitted to the matching thread pool.
4. The method as described in claim 3, characterized in that, After determining whether the queue length meets the queue adjustment conditions corresponding to the matched thread pool, the method further includes: If so, then the matched thread pool will be subjected to queue flow control processing through a differentiated backpressure flow control strategy.
5. The method as described in claim 4, characterized in that, The step of performing queue flow control processing on the matched thread pool using a differentiated backpressure flow control strategy includes: When the thread pool is a high-priority thread pool or a normal thread pool, TCP layer backpressure is triggered, and the queue length is polled based on the exponential backoff check mechanism until the queue length is less than the preset low watermark threshold, then the overload is relieved and data reading is resumed.
6. The method as described in claim 4, characterized in that, The step of performing queue flow control processing on the matched thread pool using a differentiated backpressure flow control strategy also includes: When the thread pool is a low-priority thread pool, determine the maximum capacity of the low-priority thread pool; The packet loss rate is calculated using a dynamic linear probability packet loss formula based on the maximum capacity and the queue length. Based on the packet loss rate, queue flow control is performed on the matched thread pool.
7. The method as described in claim 6, characterized in that, The dynamic linear probability packet loss formula is as follows: In the formula, For packet loss rate, The length of the queue. Maximum capacity.
8. A secure gateway signaling communication system, characterized in that, The system includes: The mapping module is used to receive signaling messages from the Netty channel, parse the instruction codes in the signaling message header, and map the instruction codes to a preset signaling priority level. The matching module is used to submit the RunnableTask corresponding to the signaling message to the matching thread pool according to the preset signaling priority level. The interaction module is used to route the signaling message to the corresponding business executor to complete the protocol interaction when the RunnableTask enters the matching thread pool for execution, through a pre-registered message processor mapping table.
9. A security gateway signaling communication device, characterized in that, The device includes: a memory, a processor, and a security gateway signaling communication program stored in the memory and executable on the processor, the security gateway signaling communication program being configured to implement the steps of the security gateway signaling communication method as described in any one of claims 1 to 7.
10. A storage medium, characterized in that, The storage medium stores a security gateway signaling communication program, which, when executed by a processor, implements the steps of the security gateway signaling communication method as described in any one of claims 1 to 7.