Efficient non-blocking message pushing method

Abstract

The invention discloses an efficient non-blocking message pushing method, which comprises the following steps that: a client establishes connection with a short message platform server by using a socket, and the short message platform server creates a session for each connection; the client sends an authentication request for authentication; automatically generating a message queue according to a client message sending request; dynamically creating and distributing a message pushing task thread according to client configuration; the message pushing task asynchronously pushes messages in a non-blocking manner; and the socket long connection is maintained through a heartbeat mechanism and a reconnection strategy. According to the invention, the pushing efficiency of the short message status report can be improved, the non-blocking asynchronous pushing message ensures that the thread is not blocked when waiting for the IO operation is completed, the real-time pushing performance of the short message status report is further improved, the connection stability can be ensured, and particularly, efficient data transmission can be maintained in a scene of sending a large number of short messages.

Description

Technical Field

[0001] The present invention relates to the technical field of mobile communication networks, and in particular to an efficient and non-blocking message pushing method. Background Art

[0002] With the continuous advancement and popularization of Internet and mobile communication technologies, SMS services have become an indispensable part of people's daily lives. SMS services are a basic service in mobile communication networks. After sending SMS messages, users usually hope to obtain the sending status of SMS messages in a timely manner, such as whether the SMS messages are sent successfully and whether they are successfully received by the recipient. In order to achieve this function, the SMS center usually adopts the SMS status report (DR) mechanism. During the SMS sending process, the SMS center will generate an SMS status report and notify the SMS sender of the SMS status report through the callback interface. Enterprise customers have increasingly higher requirements for their business SMS messages to reach end users in a timely and reliable manner and obtain their sending status. Especially in scenarios such as commercial applications, financial transactions, and emergency notifications, the real-time and accuracy of SMS status reports are particularly important.

[0003] The early SMS status reporting mechanism was mainly based on a single-threaded polling method, that is, the client periodically sent a request to the server to query the SMS sending status. In the subsequent technical development, a callback-based SMS status report push mechanism emerged. Under this mechanism, the server actively pushes a status report to the client when the SMS sending status changes.

[0004] In the process of implementing the technical method of the embodiment of the present invention, the inventor of this patent found at least the following technical problems in the prior art: The SMS status report mechanism based on single-threaded polling can still meet the demand when the amount of SMS sent is not large, but as the amount of SMS sent increases, the polling method causes a large number of invalid requests and server load, which is inefficient and provides poor user experience. Although the SMS status report push mechanism based on callback can reduce invalid requests and improve efficiency, this callback method still has some problems, such as the bottleneck of single-threaded processing and network congestion.

[0005] In the existing technology, the push method of SMS status report usually adopts a single-threaded method or an active request query method. This method is not only inefficient, but also has limited processing capacity of a single thread when the amount of SMS messages sent is large, which can easily cause server performance bottlenecks and network congestion, resulting in push delays in SMS status reports. Enterprise business SMS messages cannot be sent to end users in a timely manner, especially in financial transactions and emergency notifications. SMS messages cannot be sent to users in a timely manner, which will seriously affect the development of business. In addition, the existing push method may be blocked due to network delays or system busyness, further reducing the push efficiency.

[0006] In summary, the existing SMS status report push method cannot meet actual usage requirements. Summary of the invention

[0007] The embodiment of the present invention provides an efficient and non-blocking message push method, which solves the problem that the existing short message status report push method cannot meet actual use requirements.

[0008] The embodiment of the present invention provides an efficient and non-blocking message push method, comprising: The client uses socket to establish a connection with the SMS platform server, and the SMS platform server creates a session for each connection; The client sends an authentication request for authentication; The client message sending request automatically generates a message queue; Dynamically create and allocate message push task threads based on client configuration; Message push task pushes messages asynchronously without blocking; Maintain long socket connections through heartbeat mechanism and reconnection strategy.

[0009] Optionally, the client uses a socket to establish a connection with the SMS platform server, and the SMS platform server creates a session for each connection, including: The SMS platform server opens the listening port and waits for the client's connection request; TCP establishes a connection between the client and the SMS platform server through a three-way handshake, and the SMS platform server creates a session for each connection.

[0010] Optionally, the TCP establishes a connection between the client and the SMS platform server through a three-way handshake, including: The client sends a connection request SYN message to the SMS platform server, and randomly generates a sequence number and sends it to the SMS platform server; After receiving the connection request SYN message, the SMS platform server sends a SYN message agreeing to establish the connection, randomly generates a sequence number, and sends an ACK message to confirm the client sequence number; After the client receives the SYN message from the SMS platform server agreeing to establish the connection and the ACK message confirming the client sequence number, it sends a server confirmation ACK message to the SMS platform server. After the SMS platform server receives the server confirmation ACK message, it confirms that the connection is successfully established.

[0011] Optionally, the client sends an authentication request for authentication, including: The client sends authentication information to the SMS platform server; After the SMS platform server verifies the authentication information, it returns an authentication success message or an authentication failure message; When the authentication succeeds, the client receives an authentication success message returned by the SMS platform server and uses the cmpp20 protocol to push SMS messages; when the authentication fails, the client receives an authentication failure message returned by the SMS platform server and closes the connection between the client and the SMS platform server.

[0012] Optionally, the authentication information includes user, password, and SMS channel configuration parameters.

[0013] Optionally, the client message sending request automatically generates a message queue, including: The client application creates a message and the client sends the message to the message queue service; After the message queue service receives the message, it puts it into the client message queue; According to the preset client message processing responsibility chain, the messages are processed in order, and the message queue routes the messages to different queues according to the preset processing logic; Configure monitoring tools to manage message queue processing and service processes.

[0014] Optionally, dynamically creating and allocating message push task threads according to client configuration includes: The SMS platform server collects client configuration information; The task manager parses the client configuration information and creates a message push task, registering the task with the thread resource pool; Use thread pool to manage thread resources. According to monitoring data and client configuration requirements, TaskManager dynamically adjusts thread pool size and task allocation strategy to adapt to changing needs.

[0015] Optionally, the message push task is a non-blocking asynchronous message push task, including: The task gets the message from the message queue; The processor processes the message; The chain of responsibility filters the messages; Non-blocking threads use a synchronous non-blocking I / O model to process session data reading and writing; Basic service push message.

[0016] Optionally, the processor processes the message, including: the processor performs data matching processing on the message, and the processor identifies the receiving object and receiving destination of the message.

[0017] Optionally, maintaining a long socket connection through a heartbeat mechanism and a reconnection strategy includes: The client and the SMS platform server negotiate the heartbeat interval. If there is no data packet exchange during the heartbeat interval, the client will actively send a heartbeat packet to the SMS platform server. If the client receives a response from the SMS platform server within the heartbeat interval, the connection is valid; otherwise, the connection may be disconnected; If the client detects that the connection is disconnected, it will try to reconnect; if the SMS platform server does not receive a heartbeat packet for a long time, it will close the connection and release resources.

[0018] One or more technical solutions provided in the embodiments of the present invention have at least the following technical effects or advantages: The present invention can provide a non-blocking method that can improve the push efficiency of SMS status reports, and improves the push efficiency of SMS status reports by introducing a multi-threading method and a non-blocking asynchronous push message. The multi-threading method enables the system to process multiple SMS status report push tasks in parallel, and the non-blocking asynchronous push message ensures that the thread will not be blocked when waiting for the completion of the IO operation, so that more requests can be processed. In addition, in the network communication layer of the SMS status report push, the communication technology of the socket long connection is adopted to further improve the real-time push performance of the SMS status report. Since the Socket long connection maintains the connection between the client and the server, the overhead of frequently establishing and disconnecting the connection can be reduced, thereby reducing the delay, which is particularly important for SMS application scenarios that require real-time response, such as in commercial applications, financial transactions, emergency notifications and other scenarios. Through the heartbeat mechanism and the reconnection strategy, the stability of the connection can be guaranteed, especially in the scenario of sending a large number of SMS messages, efficient data transmission can be maintained. BRIEF DESCRIPTION OF THE DRAWINGS

[0019] Figure 1 This is a flow chart of an efficient and non-blocking message push method in one embodiment of the present invention; Figure 2 A process diagram of establishing a connection by three-way handshake in one embodiment of the present invention; Figure 3 The figure is a flowchart of thread pool task management in one embodiment of the present invention. DETAILED DESCRIPTION

[0020] The embodiment of the present invention provides an efficient and non-blocking message push method, which solves the problem that the existing short message status report push method cannot meet actual use requirements.

[0021] In order to better understand the above-mentioned efficient and non-blocking message push method, the following will be described in detail in conjunction with the drawings and specific implementation methods of the specification. Obviously, the embodiments described in the present invention are part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without making creative work are within the scope of protection of the present invention.

[0022] Please refer to the following Figure 1 , an efficient and non-blocking message push method in an embodiment of the present invention is described in detail.

[0023] Step 10: The client uses the socket to establish a connection with the SMS platform server, and the SMS platform server creates a session for each connection. Step 10 specifically includes: Sub-step 101: The SMS platform server opens a listening port and waits for a connection request from a client.

[0024] During the specific implementation of sub-step 101, for example, the SMS platform server opens a listening port, waits for the client connection request to arrive, processes it, and sends a response to the connection request.

[0025] Sub-step 102: TCP establishes a connection between the client and the SMS platform server through a three-way handshake, and the SMS platform server creates a session for each connection.

[0026] In the specific implementation process of step 102, for example, after the SMS platform server is ready, the client creates an IOConnector and starts binding with the SMS platform server service port to create a Connection, and then creates a Session and associates it with the Connection. The SMS platform server will create a session for each Connection and provide various services during the session cycle, such as calling sessionCreated when the connection is created, calling sessionIdle when the connection is waiting, and calling sessionClosed when the connection is destroyed. During the session creation process, the request from the client is listened to through IOAcceptor; when a new connection is established, a new session is automatically created, which is used to provide services to the client with the same IP / port combination.

[0027] like Figure 2 As shown in the figure, TCP establishes a connection between the client and the SMS platform server through a three-way handshake, including: First handshake: The client sends a connection request SYN message to the SMS platform server, and randomly generates a sequence number (seq=J) and sends it to the SMS platform server. The client enters the SYN_SENT state and waits for confirmation from the SMS platform server.

[0028] Second handshake: After receiving the connection request SYN message, the SMS platform server confirms the client's SYN (ACK=1), and sends a SYN message agreeing to establish a connection, and randomly generates a sequence number (seq=K), and sends an ACK message to confirm the client's sequence number (ack=J+1), and the SMS platform server enters the SYN_RCVD state.

[0029] The third handshake: After the client receives the SYN message from the SMS platform server agreeing to establish the connection and the ACK message confirming the client sequence number, it sends a server confirmation ACK message to the SMS platform server. After the SMS platform server receives the server confirmation ACK message, it confirms that the connection is successfully established.

[0030] Step 20: The client sends an authentication request for authentication. Step 20 specifically includes: Sub-step 201: The client sends authentication information to the SMS platform server, wherein the authentication information includes necessary information such as user, password, and SMS channel configuration parameters.

[0031] Sub-step 202: After verifying the authentication information, the SMS platform server returns an authentication success message or an authentication failure message.

[0032] Sub-step 203: When the authentication succeeds, the client receives the authentication success message returned by the SMS platform server, and uses the cmpp20 protocol to perform SMS message push service; when the authentication fails, the client receives the authentication failure message returned by the SMS platform server, and closes the connection between the client and the SMS platform server. Among them, the SMS message push service includes operations such as starting to send and submit SMS messages and receiving SMS status reports.

[0033] Step 30: The client sends a message request and automatically generates a message queue. After the client sends a message request, the SMS platform server will automatically build a corresponding message queue (Message Queuing) according to the client configuration. Message queue is an asynchronous service-to-service communication method that allows services to decouple and buffer messages to ensure reliable message delivery. Step 30 specifically includes: Sub-step 301: The client application creates a message, and the client sends the message to the message queue service, wherein the message includes data to be transmitted.

[0034] Sub-step 302: After receiving the message, the message queue service puts it into the client message queue. The message queue storage method is orderly storage, which ensures that the messages are processed in order according to the preset priority, and the distributed lock ensures the orderly processing under concurrent processing.

[0035] Sub-step 303: According to the preset client message processing responsibility chain, the message is processed in order, and the message queue routes the message to different queues according to the preset processing logic.

[0036] During the specific implementation of sub-step 303, for example, the message queue routes the message to different queues according to the preset processing logic. Before entering the queue, the program processes the message in order according to the preset client message processing responsibility chain. Among them, the processing includes message information completion, signature verification, black / white list verification, sending time period verification, charging method verification, retransmission filtering, sensitive word filtering, etc. If an error occurs when processing a message, the processing program will perform a retry mechanism, such as processing according to the preset number of retries and intervals, to avoid message processing failure due to temporary problems.

[0037] Sub-step 304: Configure monitoring tools to manage message queue processing and service processes.

[0038] During the specific implementation of sub-step 304, for example, during the message queue processing and service process, a monitoring tool is configured to allow the administrator to monitor key performance indicators such as queue backlog quantity and message processing speed. The administrator can use these key performance indicators to diagnose problems and optimize performance.

[0039] Step 40: Dynamically create and allocate message push task threads according to client configuration. In the message push service, dynamically create and allocate message push task threads according to client configuration to improve the efficiency of message push. At the same time, the dynamic allocation function can realize on-demand resource allocation, greatly improving the flexibility and efficiency of the system. Step 40 specifically includes: Sub-step 401: The SMS platform server collects client configuration information.

[0040] In the specific implementation process of sub-step 401, for example, the SMS platform server provides a configuration management function for the client to collect client configuration information. The client configuration information includes: account, password, push task priority, frequency, threshold, sub-number, push task thread number, route, speed limit, number of connections, etc.

[0041] Sub-step 402: The task manager parses the client configuration information and creates a message push task, and registers the task with the thread resource pool.

[0042] In the specific implementation process of sub-step 402, for example, the system background task manager (TaskManager) will parse the collected client configuration information, create a message push task task based on this information, and then register its task with the thread resource pool. Each task contains all the information required for push. During the execution process, TaskManager is responsible for creating, allocating and managing client message push tasks, and can also buffer data.

[0043] Sub-step 403: Use the thread pool to manage thread resources. According to monitoring data and client configuration requirements, TaskManager dynamically adjusts the thread pool size and task allocation strategy to adapt to changing needs.

[0044] During the specific implementation of sub-step 403, for example: in order to efficiently process push tasks, a thread pool is used to manage thread resources. The size of the thread pool is dynamically adjusted through TaskManager. According to monitoring data and client configuration requirements, the thread pool size and task allocation strategy are dynamically adjusted to adapt to changing needs. The initialization, acquisition and recycling of the thread pool are maintained through TaskManager. TaskManager can be regarded as a collection of tasks to be executed, which is used to process tasks that must be executed successfully, and ensure that the tasks are successfully processed. If the execution fails, the task will be put back into the collection and wait for the next consumption. In practical applications, this mechanism of dynamically creating and allocating task threads can greatly improve the flexibility and efficiency of the system, especially when a large number of clients and push tasks need to be processed.

[0045] like Figure 3 As shown, the number of threads of corePoolSize and maxPoolSize is managed and dynamically maintained by TaskManager. Therefore, when these two parameters remain unchanged, the number of threads is relatively fixed. When a new task is submitted and the number of threads of corePoolSize and maxPoolSize are not full, a new thread will be created to execute the task; if only the number of corePoolSize threads is full, the task will enter the waiting queue, waiting for TaskManager to schedule idle threads or create new threads to execute the task; if the number of maxPoolSize threads is full, the task execution will be rejected. Of course, in the present invention, this situation will not occur, because in the operation and production configuration process, the corresponding number of tasks will actually be allocated according to the actual resources. Among them, corePoolSize is the number of threads that remain active in the thread pool, even if they are idle; maxPoolSize is the maximum number of threads allowed in the thread pool.

[0046] Through the SMS status report callback method based on multi-threading, the callback efficiency of the SMS status report can be effectively improved, the callback delay of the SMS status report can be reduced, the user experience can be improved, and it can be ensured that the system can still run efficiently and without blocking under high load.

[0047] Step 50: Message push task non-blocking asynchronous push message. In the message push task, non-blocking asynchronous push message is an efficient way to ensure timely delivery of messages without blocking the main thread or other tasks of the process. In order to support multi-threaded asynchronous execution of tasks, the thread life cycle is elegantly managed through the thread pool, which can effectively reuse thread resources and improve performance. Step 50 specifically includes: Sub-step 501: The task obtains a message from a message queue.

[0048] In the specific implementation process of sub-step 501, for example: TaskManager is responsible for managing and maintaining the execution of scheduled tasks. When it monitors that there are messages to be sent in the message queue, TaskManager will schedule a task to read the message from the message queue, and after reading the message, it will hand it over to the processor Handler for processing.

[0049] Sub-step 502: The processor processes the message; the processor processes the message, including: the processor performs data matching processing on the message, and the processor identifies the receiving object and receiving destination of the message.

[0050] Sub-step 503: The responsibility chain filters the message.

[0051] In the specific implementation process of step 503, for example, in the process of message push service, a series of interception and filtering processing functions are usually required. In the present invention, the responsibility chain mode is adopted, that is, each interception and filtering function is encapsulated into an independent processing object, and each processor can process the request or pass it to the next processor in the chain. The responsibility chain generally includes: signature verification, segment routing, provincial routing, channel routing, retransmission filtering, frequency filtering and other responsibility chain functions.

[0052] Sub-step 504: The non-blocking thread uses a synchronous non-blocking I / O model to process session data reading and writing.

[0053] In the specific implementation process of sub-step 504, for example: Processor is a non-blocking thread that processes session IO, which is used to process the data reading and writing of the current session and perform business processing. When the service is initialized, a thread pool will be initialized, and the size of the pool will be passed in through the constructor of NioSocketAcceptor. Each processor thread will reference this thread pool, that is, each processor thread runs in this thread pool. Among them, the non-blocking mechanism adopts the NIO communication mechanism in java, which is a synchronous non-blocking I / O model. Non-blocking read enables a thread to send a request to read data from a channel, but it can only get the currently available data. If there is no data available at present, nothing will be obtained. Instead of keeping the thread blocked, the thread can continue to do other things until the data becomes readable, and the same is true for non-blocking writes. A thread requests to write some data to a channel, but there is no need to wait for it to be fully written. The thread can do other things at the same time.

[0054] Sub-step 505: basic service push message.

[0055] During the specific implementation process, sub-step 505 includes: the main functions of the basic service service include managing the socket long connection session, managing the responsibility chain, and processing the data transmission between the server and the client.

[0056] Step 60: Maintaining a long socket connection through a heartbeat mechanism and reconnection strategy. The heartbeat mechanism is used to maintain a long socket connection in order to ensure that the connection between the client and the server remains active, even if there is no data transmission. Because in socket network communication, a connection without communication for a long time may be regarded as an invalid connection by the network device and closed. The heartbeat mechanism avoids this by sending heartbeat packets regularly, maintaining the stability of the long socket connection, ensuring that the long connection can be automatically restored in abnormal situations, reducing the overhead of connection establishment and disconnection, and improving overall performance. Step 60 specifically includes: Sub-step 601: The client and the SMS platform server negotiate the heartbeat interval. If there is no data packet exchange within the heartbeat interval, the client will actively send a heartbeat packet to the SMS platform server. The heartbeat interval can be set to 30 seconds. Of course, different durations can be set as the heartbeat interval according to actual conditions, and the present invention is not limited thereto.

[0057] Sub-step 602: If the client receives a response from the SMS platform server within the heartbeat interval, the connection is valid; otherwise, the connection may be disconnected.

[0058] In the specific implementation process of sub-step 602, for example, after the client sends a heartbeat packet, it waits for the SMS platform server to receive a response. If the client receives a response from the SMS platform server within the heartbeat detection time, it is considered that the connection is still valid; if the client does not receive a response from the SMS platform server within the heartbeat detection time, it may be considered that the connection has been disconnected.

[0059] Sub-step 603: If the client detects that the connection is disconnected, it attempts to reconnect; if the SMS platform server does not receive a heartbeat packet for a long time, it closes the connection and releases resources.

[0060] Obviously, those skilled in the art can make various changes and modifications to the present invention without departing from the spirit and scope of the present invention. Thus, if these modifications and variations of the present invention fall within the scope of the claims of the present invention and their equivalents, the present invention is also intended to include these modifications and variations.

Claims

1. An efficient and non-blocking message push method, characterized in that: include: The client uses socket to establish a connection with the SMS platform server, and the SMS platform server creates a session for each connection; The client sends an authentication request for authentication; The client message sending request automatically generates a message queue; Dynamically create and allocate message push task threads based on client configuration; Message push task non-blocking asynchronous push message; Maintain long socket connections through heartbeat mechanism and reconnection strategy.

2. The method according to claim 1, characterized in that The client uses a socket to establish a connection with the SMS platform server, and the SMS platform server creates a session for each connection, including: The SMS platform server opens the listening port and waits for the client's connection request; TCP establishes a connection between the client and the SMS platform server through a three-way handshake, and the SMS platform server creates a session for each connection.

3. The method according to claim 2, characterized in that The TCP establishes a connection between the client and the SMS platform server through a three-way handshake, including: The client sends a connection request SYN message to the SMS platform server, and randomly generates a sequence number and sends it to the SMS platform server; After receiving the connection request SYN message, the SMS platform server sends a SYN message agreeing to establish the connection, randomly generates a sequence number, and sends an ACK message to confirm the client sequence number; After the client receives the SYN message from the SMS platform server agreeing to establish the connection and the ACK message confirming the client sequence number, it sends a server confirmation ACK message to the SMS platform server. After the SMS platform server receives the server confirmation ACK message, it confirms that the connection is successfully established.

4. The method according to claim 1, characterized in that The client sends an authentication request for authentication, including: The client sends authentication information to the SMS platform server; After the SMS platform server verifies the authentication information, it returns an authentication success message or an authentication failure message; When the authentication succeeds, the client receives an authentication success message returned by the SMS platform server and uses the cmpp20 protocol to push SMS messages; when the authentication fails, the client receives an authentication failure message returned by the SMS platform server and closes the connection between the client and the SMS platform server.

5. The method according to claim 4, characterized in that The authentication information includes user, password, and short message channel configuration parameters.

6. The method according to claim 1, characterized in that The client message sending request automatically generates a message queue, including: The client application creates a message and the client sends the message to the message queue service; After the message queue service receives the message, it puts it into the client message queue; According to the preset client message processing responsibility chain, the messages are processed in order, and the message queue routes the messages to different queues according to the preset processing logic; Configure monitoring tools to manage message queue processing and service processes.

7. The method according to claim 1, characterized in that The dynamically creating and allocating message push task threads according to the client configuration includes: The SMS platform server collects client configuration information; The task manager parses the client configuration information and creates a message push task, registering the task with the thread resource pool; Use thread pool to manage thread resources. According to monitoring data and client configuration requirements, TaskManager dynamically adjusts thread pool size and task allocation strategy to adapt to changing needs.

8. The method according to claim 1, characterized in that The message push task is a non-blocking asynchronous message push task, including: The task gets the message from the message queue; The processor processes the message; The chain of responsibility filters the messages; Non-blocking threads use a synchronous non-blocking I / O model to process session data reading and writing; Basic service push message.

9. The method according to claim 8, characterized in that The processor processes the message, including: the processor performs data matching processing on the message, and the processor identifies the receiving object and receiving destination of the message.

10. The method according to claim 1, characterized in that Maintaining a long socket connection through a heartbeat mechanism and a reconnection strategy includes: The client and the SMS platform server negotiate the heartbeat interval. If there is no data packet exchange during the heartbeat interval, the client will actively send a heartbeat packet to the SMS platform server. If the client receives a response from the SMS platform server within the heartbeat interval, the connection is valid; otherwise, the connection may be disconnected; If the client detects that the connection is disconnected, it will try to reconnect; if the SMS platform server does not receive a heartbeat packet for a long time, it will close the connection and release resources.

Images