Message polling resending method, device, server and storage medium

Abstract

This application relates to the field of mobile communication technology, and in particular to a message polling resending method, apparatus, server, and storage medium. The method includes: obtaining a message report push table and a client status table; identifying service messages in the message report push table that have been pushed to the target client but not received by the target client, and identifying the client status of the target client in the client status table; and when the client status is online, polling and resending service messages to the target client at first preset intervals. This solves the problems in related technologies, such as the inability to balance server performance and timeliness, leading to excessive server load, degraded client performance, and the inability of the server to monitor the real-time status of the client, which can easily result in incorrect concatenation of interface request results.

Description

Technical Field

[0001] This application relates to the field of mobile communication technology, and in particular to a message polling resending method, apparatus, server and storage medium. Background Technology

[0002] With the increasing integration of client-side networks, more and more service operators will push various service messages to clients through servers. The service message push process includes: the client sends a message retrieval request to the server, the server responds to the message retrieval request and pushes the service message to the client; if the client does not receive the service message for a long time, it will periodically resend the message retrieval request to the server until the client receives the service message.

[0003] However, by sending messages to the server periodically to obtain requests from the client, the number of communications between the client and the server is greatly increased, resulting in frequent requests between the client and the server. This not only increases the server load excessively, but also increases the request pressure on the client, leading to a deterioration in client performance. At the same time, the client's state is diverse, and there are dependencies between interface requests. Since the server cannot monitor the client's real-time state, it is easy to cause errors in the chaining of interface request results. Summary of the Invention

[0004] This application provides a message polling resending method, apparatus, server, and storage medium to solve the problems in related technologies that cannot balance server performance and timeliness, easily leading to excessive server load, degraded client performance, and the inability of the server to monitor the real-time status of the client, which can easily lead to errors in the concatenation of interface request results.

[0005] The first aspect of this application provides a message polling resending method, which is applied to a server and includes the following steps: obtaining a message report push table and a client status table; identifying service messages in the message report push table that have been pushed to a target client but not received by the target client, and identifying the client status of the target client in the client status table; when the client status is online, polling and resending the service messages to the target client at a first preset time interval.

[0006] Optionally, the step of polling and resending the service message to the target client at a first preset interval includes: obtaining the push time of the service message; calculating the polling and resending time based on the push time and the first preset interval; and pushing the service message to the target client at the polling and resending time.

[0007] Optionally, before polling and resending the service message to the target client at a first preset interval, the method further includes: obtaining the remaining validity period and / or priority of the service message; and determining the first preset interval for polling and resending the service message based on the remaining validity period and / or the priority.

[0008] Optionally, when the client status is offline, the method further includes: identifying the client status of the target client in the client status table at intervals of a second preset time.

[0009] Optionally, the message report push table includes one or more of the following: push table identifier, service message identifier, client identifier, remaining validity period of the report, push status of the service message, and push time.

[0010] Optionally, the client reporting the delivered or opened message of the service message further includes updating the push status of the service message based on the delivered or opened message.

[0011] Optionally, the client status table includes one or more of the following: client identifier, client status, and update time.

[0012] A second aspect of this application provides a message polling and resending device, which is applied to a server. The device includes: an acquisition module for acquiring a message report push table and a client status table; an identification module for identifying service messages in the message report push table that have been pushed to a target client but not received by the target client, and identifying the client status of the target client in the client status table; and a polling and resending module for polling and resending the service messages to the target client at first preset intervals when the client status is online.

[0013] A third aspect of this application provides a server, including: a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the program to implement a message polling resending method as described in the above embodiments.

[0014] A fourth aspect of this application provides a computer-readable storage medium having a computer program stored thereon, which is executed by a processor to implement a message polling and resending method as described in the above embodiments.

[0015] Therefore, this application has at least the following beneficial effects:

[0016] This application embodiment achieves this by using server-monitored polling and resending of service messages. This eliminates the need for clients to repeatedly send message retrieval requests, effectively reducing the number of communications between the client and server, avoiding frequent requests, reducing server load and pressure, and preventing client performance degradation. Simultaneously, the server monitors the client's status in real time and performs polling and resending based on that status, preventing errors in the chaining of interface request results. Furthermore, the server's periodic polling and resending of service messages effectively balances the timeliness of service messages, thus effectively balancing server performance and timeliness, improving the user experience. Therefore, it solves the technical problems in related technologies, such as the inability to balance server performance and timeliness, leading to excessive server load and client performance degradation, and the inability of the server to monitor the client's real-time status, which can easily result in errors in the chaining of interface request results.

[0017] Additional aspects and advantages of this application will be set forth in part in the description which follows, and in part will be obvious from the description, or may be learned by practice of this application. Attached Figure Description

[0018] The above and / or additional aspects and advantages of this application will become apparent and readily understood from the following description of the embodiments taken in conjunction with the accompanying drawings, wherein:

[0019] Figure 1 This is a flowchart of a message polling and resending method provided according to an embodiment of this application;

[0020] Figure 2 This is a flowchart of a message polling resending method according to an embodiment of this application;

[0021] Figure 3 This is a block diagram of a message polling resending device according to an embodiment of this application;

[0022] Figure 4 This is a schematic diagram of the server structure according to an embodiment of this application. Detailed Implementation

[0023] The embodiments of this application are described in detail below. Examples of these embodiments are shown in the accompanying drawings, wherein the same or similar reference numerals denote the same or similar elements or elements having the same or similar functions throughout. The embodiments described below with reference to the accompanying drawings are exemplary and intended to explain this application, and should not be construed as limiting this application.

[0024] With the increasing integration of client-side networks, more and more service operators will push various service messages to clients through servers, including message types with high timeliness requirements.

[0025] These types of messages have very high time requirements for delivery to the client; if they cannot be delivered in a timely manner, the message will lose its purpose.

[0026] However, due to the explosive growth in the number of client users and the limitations of server performance bottlenecks, timely expansion and sufficient budget are not feasible, making it difficult to balance server performance and timeliness for many service messages.

[0027] Currently, there are two main approaches: The first approach, in order to improve the timeliness of service messages, uses manual or semi-manual monitoring and intervention to forcibly push service messages. This approach can cause server performance to exceed the warning level, and in severe cases, it can lead to server crashes, resulting in a large number of service messages not being delivered, and even seriously affecting the services of other businesses. The second approach, in order to ensure that the server does not exceed the warning performance level, pushes service messages, especially those with high timeliness, in batches. This extends the push cycle, reduces timeliness, and leads to a decrease in client user satisfaction, which can even result in the loss of some users.

[0028] To address the above issues, in related technologies, a server receives a message retrieval request from a client. This request includes a request push time and a list of received messages. The request push time is the first push time in the previous response message received by the client from the server. The list of received messages includes the message identifier IDs of all messages previously received by the client from the server. Based on the request push time and the list of received messages in the message retrieval request, the server retrieves new messages that have not yet been sent to the client from the message queue and sends a response message back to the client. This response message includes a second push time and a list of new messages. The new message list includes the message IDs and message content of all new messages sent to the client this time. The second push time is the push time of the new messages. The response message also includes a polling period. After receiving the response message, the client counts according to the polling period. When the polling response time is exceeded, the client generates a message retrieval request and sends it to the message polling server. The polling period is set based on the load of the message polling server and / or the number of new messages in the message queue.

[0029] However, given the increasing number of clients using the method and the diversification of client states, this approach has the following problems: multiple requests between the client and the server can lead to excessive server load, increasing the request pressure on the client; the diversification of client states and the dependencies between interface requests can easily lead to errors in the chaining of interface request results.

[0030] Therefore, when server performance cannot be expanded temporarily, but service messages must be pushed to client users as early and quickly as possible, in order to reduce the impact on server performance, especially client performance, and to optimize request efficiency and accuracy, after the server sends a service message and the client receives the message and uploads the message status, the server initiates an interface request to report the push status and client status. This determines which service messages have been sent but have not yet been pushed to the client user, and which the client is online and can receive the message in time. For these clients, a resend poll is performed, that is, service messages that meet the resend conditions are pushed again every N minutes, so that the client can receive the service message in time during the next service message receiving window.

[0031] The following description, with reference to the accompanying drawings, illustrates a message polling resending method, apparatus, server, and storage medium according to embodiments of this application. Addressing the issues mentioned in the background art, such as the inability to balance server performance and timeliness, the server's inability to monitor the real-time status of clients, and the potential for errors in the chaining of interface request results, leading to decreased client user satisfaction and user churn, this application provides a message polling resending method. In this method, the client sends a message retrieval request to the server, the server responds to the message retrieval request, and pushes service messages to the client. The server monitors the client's status in real time. When the client's status is identified as offline, the server repeatedly checks the client's status until the client's status is online. If the client's status is identified as online but no service message has been received, then service message polling resending is required; otherwise, the client does not require service message polling resending. This solves the problems in related technologies, such as the inability to balance server performance and timeliness, resulting in excessive server load and degraded client performance; diverse client statuses; dependencies in interface requests; and the server's inability to monitor the real-time status of clients, easily leading to errors in the chaining of interface request results.

[0032] Specifically, Figure 1 This is a flowchart illustrating a message polling and resending method provided in an embodiment of this application.

[0033] like Figure 1 As shown, this message polling and resending method includes the following steps:

[0034] In step S101, the message report push table and the client status table are obtained.

[0035] The message report push table can include a push table identifier, a service message identifier, a client identifier, a remaining validity period of the report, the push status of the service message, and the push time. The push table identifier can be a push table ID (Identity document), the service message identifier can be a service message report ID, the remaining validity period of the report can be the validity period set when pushing the service message, the push status of the service message can be pushed, delivered, or opened, and the push time can be 1 minute or 5 minutes, etc., which can be limited according to the actual situation.

[0036] The client status table can include client identifier, client status, and update time.

[0037] It is understood that the server has a message report push table and a client status table. The message report push table can be used to record the push status of service messages, and the client status table can be used to record the real-time status of the client. In this embodiment, the message report push table and the client status table can be obtained periodically, such as at intervals of 1 minute or 2 minutes. The acquisition interval can be specifically set according to the requirements of message polling and resending.

[0038] In this embodiment of the application, the reporting of a delivered or opened service message by the client further includes updating the push status of the service message based on the delivered or opened message.

[0039] It is understood that, in this embodiment of the application, the client needs to update the push status of delivered or opened messages in a timely manner and record it in the client status table so that the server can accurately identify the real-time status of the client.

[0040] In step S102, service messages that have been pushed to the target client in the message report push table but have not been received by the target client are identified, and the client status of the target client in the client status table is identified.

[0041] The client status can include online status and offline status.

[0042] It is understandable that when a service message has been pushed to the target client but the target client has not received it, it indicates that the server message needs to be resent via polling. Otherwise, it indicates that the target client does not need to resent the service message via polling. In this embodiment, the server identifies the client that needs the service message resentment, rather than the client repeatedly sending message retrieval requests. This effectively reduces the number of communications between the client and the server, avoids frequent requests between the client and the server, reduces server load and pressure, and prevents client performance degradation. At the same time, the server monitors the client's status in real time and performs polling resentment based on the client's status, avoiding errors in the concatenation of interface request results. In step S103, when the client is online, the service message is resent to the target client via polling at a first preset time interval.

[0043] The first preset duration can be preset according to the timeliness of the service message, such as 10 minutes or 30 minutes, and can be limited according to the actual situation.

[0044] It is understood that in this embodiment of the application, the server identifies that the client is online but has not received a service message, and then polls and resends the service message according to a preset time interval. Otherwise, the client does not need to poll and resend the service message. This embodiment of the application sets a reasonable first preset time based on the timeliness of the service message, so that the client receives the service message as soon as possible, thereby improving the timeliness of the service message.

[0045] In this embodiment of the application, polling and resending service messages to the target client at a first preset time interval includes: obtaining the push time of the service message; calculating the polling and resending time based on the push time and the first preset time interval; and pushing the service message to the target client at the polling and resending time.

[0046] The push time of the service message can be the time when the server sends the service message to the client, and the polling resending time can be the time when the service message is polled and resent.

[0047] It is understood that, in this embodiment of the application, the push time is taken as the starting point. When the time without receiving the service message exceeds the first preset time, the polling resending time is calculated and the service message is resent in a polling manner to ensure that the service message is sent to the client in a timely manner. For clients with diverse service message requirements, the polling resending of service messages can be carried out by flexibly setting the first preset time to improve user satisfaction.

[0048] In this embodiment of the application, before polling and resending service messages to the target client at a first preset interval, the method further includes: obtaining the remaining validity period and / or priority of the service message; and determining the first preset interval for polling and resending service messages based on the remaining validity period and / or priority.

[0049] The remaining validity period can be the set remaining push validity time, such as 5 minutes or 10 minutes, and the priority can be the priority level set by the client to receive service messages, without specific limitations.

[0050] It is understood that the embodiments of this application determine the first preset duration based on the remaining push validity time and / or priority of the service message, and provide the client with valid service messages through the remaining validity period or priority, thereby optimizing the request efficiency of service message polling and resending and reducing server pressure.

[0051] In this embodiment of the application, when the client is in an offline state, the method further includes: identifying the client state of the target client in the client state table at intervals of a second preset time.

[0052] The second preset duration can be a pre-set time interval for the server to monitor the client status, such as 5 minutes, which can be limited according to the actual situation.

[0053] It is understood that in this embodiment of the application, the server identifies the client's status as offline and repeatedly identifies the client's status at a second preset interval until the client is online. Then, it immediately polls and resends service messages to improve the message delivery rate. The server monitors the client's status in real time to avoid errors in the chaining of interface request results.

[0054] According to the message polling resending method proposed in this application embodiment, the client sends a message retrieval request to the server, the server responds to the message retrieval request, and pushes service messages to the client; the server monitors the client's status in real time. When the client's status is identified as offline, the server repeatedly identifies the client's status until the client's status is online. When the client's status is identified as online but no service message has been received, then the service message needs to be polled and resent. Otherwise, the client does not need to poll and resend the service message. This solves the problems of not being able to balance server performance and timeliness, which can easily lead to excessive server load, degraded client performance, and the inability of the server to monitor the client's real-time status, which can easily lead to incorrect chaining of interface request results.

[0055] The following will combine Figure 2 The message polling and resending method is described in detail. In the following embodiments, the method of polling and pushing messages based on real-time status is used as an example. The specific steps are as follows:

[0056] (1) When the server pushes a service message to the client, the push service message includes a message report push table, which includes a push table ID, a report ID, a client identification code, a remaining validity period of the report, a report status, and a push time. The server identifies the report status as pushed and the remaining validity period of the report as the push time set when the report is pushed.

[0057] (2) After receiving the message service, the client reports and updates the status, such as whether it has been delivered or opened.

[0058] (3) The client writes the acquired client status into the client status table, which includes the client identification code, client status and update time. The client status can be online or offline.

[0059] (4) Update the update time and client status in the client status table in a timely manner according to the client status.

[0060] (5) The server identifies push records in the message report push table where the service message report status is pushed but not delivered.

[0061] (6) Based on (5), determine the returned push record, and the server identifies the client whose client identification code is online in the client status table in the push record.

[0062] (7) According to (6), if the client status is identified as offline, the server will identify the client status again in the client status table and repeat the identification multiple times. The frequency of the repeated identification can be flexibly adjusted until the client status is online.

[0063] (8) According to (5) to (7), the client is online but has not received the service message and needs to resend the push record.

[0064] (9) The server resends the push records that need to be resent obtained in (8), that is, it resends them. The resending frequency can be flexibly adjusted according to the timeliness and priority of the service message, such as setting it to resend once every 10 minutes or once every 30 minutes.

[0065] (10) After resending, when the client receives the service message, it should promptly update the report status in the service message push record in the message report push table.

[0066] (11) In (9), if the client still does not receive the message after resending, the server will resend the message again according to the set resending interval, that is, repeat (1) to (10) until the online client receives the report or the remaining validity period of the report expires.

[0067] In summary, the message polling resending method proposed in this application solves the problems in related technologies, such as the inability to balance server performance and timeliness, which can easily lead to excessive server load, degraded client performance, and the inability of the server to monitor the real-time status of the client, which can easily lead to incorrect chaining of interface request results.

[0068] Next, the message polling and resending apparatus proposed according to the embodiments of this application is described with reference to the accompanying drawings.

[0069] Figure 3 This is a block diagram of a message polling and resending device according to an embodiment of this application.

[0070] like Figure 3 As shown, the message polling resending device 10 includes: an acquisition module 100, an identification module 200, and a polling resending module 300.

[0071] The acquisition module 100 is used to acquire the message report push table and the client status table; the identification module 200 is used to identify service messages that have been pushed to the target client in the message report push table but have not been received by the target client, and to identify the client status of the target client in the client status table; the polling and resending module 300 is used to poll and resend service messages to the target client at a first preset time interval when the client status is online.

[0072] It should be noted that the foregoing explanation of the message polling resending method embodiment also applies to the message polling resending device of this embodiment, and will not be repeated here.

[0073] According to the message polling and resending device proposed in this application embodiment, the client sends a message retrieval request to the server, the server responds to the message retrieval request, and pushes service messages to the client; the server monitors the client's status in real time. When the client's status is identified as offline, the server repeatedly identifies the client's status until the client's status is online. When the client's status is identified as online but no service message has been received, then polling and resending of service messages is required. Otherwise, the client does not need to poll and resend service messages. This effectively solves the problems in related technologies, such as frequent requests between the client and the server, resulting in excessive server load and degraded client performance; diverse client statuses; dependencies between interface requests; inability to monitor the client's real-time status; and the high risk of incorrect concatenation of interface request results.

[0074] Figure 4 A schematic diagram of the structure of a server provided in an embodiment of this application. The server may include:

[0075] The memory 401, the processor 402, and the computer program stored on the memory 401 and capable of running on the processor 402.

[0076] When processor 402 executes the program, it implements the message polling and resending method provided in the above embodiments.

[0077] Furthermore, the vehicle also includes:

[0078] Communication interface 403 is used for communication between memory 401 and processor 402.

[0079] The memory 401 is used to store computer programs that can run on the processor 402.

[0080] The memory 401 may include high-speed RAM (Random Access Memory) memory, and may also include non-volatile memory, such as at least one disk storage.

[0081] If the memory 401, processor 402, and communication interface 403 are implemented independently, then the communication interface 403, memory 401, and processor 402 can be interconnected via a bus to complete communication between them. The bus can be an ISA (Industry Standard Architecture) bus, a PCI (Peripheral Component Interconnect) bus, or an EISA (Extended Industry Standard Architecture) bus, etc. The bus can be divided into address bus, data bus, control bus, etc. For ease of representation, Figure 4 The bus is represented by a single thick line, but this does not mean that there is only one bus or one type of bus.

[0082] Optionally, in a specific implementation, if the memory 401, processor 402, and communication interface 403 are integrated on a single chip, then the memory 401, processor 402, and communication interface 403 can communicate with each other through an internal interface.

[0083] Processor 402 may be a CPU (Central Processing Unit), an ASIC (Application Specific Integrated Circuit), or one or more integrated circuits configured to implement embodiments of this application.

[0084] This application also provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the above-described message polling and resending method.

[0085] In the description of this specification, the references to terms such as "one embodiment," "some embodiments," "example," "specific example," or "some examples," etc., indicate that a specific feature, structure, material, or characteristic described in connection with that embodiment or example is included in at least one embodiment or example of this application. In this specification, the illustrative expressions of the above terms do not necessarily refer to the same embodiment or example. Furthermore, the specific features, structures, materials, or characteristics described may be combined in any suitable manner in one or more embodiments or examples. Moreover, without contradiction, those skilled in the art can combine and integrate the different embodiments or examples described in this specification, as well as the features of different embodiments or examples.

[0086] Furthermore, the terms "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of technical features indicated. Thus, a feature defined as "first" or "second" may explicitly or implicitly include at least one of that feature. In the description of this application, "N" means at least two, such as two, three, etc., unless otherwise explicitly specified.

[0087] Any process or method described in the flowchart or otherwise herein can be understood as representing a module, segment, or portion of code comprising one or N executable instructions for implementing custom logic functions or processes, and the scope of the preferred embodiments of this application includes additional implementations in which functions may be performed not in the order shown or discussed, including substantially simultaneously or in reverse order depending on the functions involved, as should be understood by those skilled in the art to which embodiments of this application pertain.

[0088] It should be understood that the various parts of this application can be implemented using hardware, software, firmware, or a combination thereof. In the above embodiments, the N steps or methods can be implemented using software or firmware stored in memory and executed by a suitable instruction execution system. If implemented in hardware, as in another embodiment, it can be implemented using any one or a combination of the following techniques known in the art: discrete logic circuits having logic gates for implementing logical functions on data signals, application-specific integrated circuits (ASICs) having suitable combinational logic gates, programmable gate arrays (FPGAs), field-programmable gate arrays (FPGAs), etc.

[0089] Those skilled in the art will understand that all or part of the steps of the methods in the above embodiments can be implemented by a program instructing related hardware. The program can be stored in a computer-readable storage medium, and when executed, the program includes one or a combination of the steps of the method embodiments.

[0090] Although embodiments of this application have been shown and described above, it is understood that the above embodiments are exemplary and should not be construed as limiting this application. Those skilled in the art can make changes, modifications, substitutions and variations to the above embodiments within the scope of this application.

Claims

1. A message polling retransmission method, characterized by, The method is applied to a server, and the method includes the following steps: Retrieve the message report push table and client status table; Identify service messages that have been pushed to the target client in the message report push table but have not been received by the target client, and identify the client status of the target client in the client status table; When the client is in an online state, the service message is resent to the target client in a polling manner at a first preset time interval; The client needs to update the push status of delivered or opened messages in a timely manner and record it in the client status table; The server identifies clients that need to resend service messages, rather than clients repeatedly sending message retrieval requests. The step of polling and resending the service message to the target client at a first preset interval includes: Obtain the push time of the service message; Calculate the polling resend time based on the push time and the first preset duration; The service message is pushed to the target client at the specified polling resend time. Before polling and resending the service message to the target client at a first preset time interval, the process further includes: Obtain the remaining validity period and / or priority of the service message; The first preset duration of the service message polling resending interval is determined based on the remaining validity period and / or the priority. When the client is in an offline state, the following is also included: The client status of the target client in the client status table is identified at intervals of a second preset time.

2. The message polling resending method according to claim 1, characterized in that, The message report push table includes one or more of the following: push table identifier, service message identifier, client identifier, remaining validity period of the report, push status of the service message, and push time.

3. The message polling resending method according to claim 1 or 2, characterized by, The client's reporting of the delivered or opened service message also includes: Update the push status of the service message based on the delivered message or the opened message.

4. The message polling resending method of claim 1, wherein, The client status table includes one or more of the following: client identifier, client status, and update time.

5. A message polling retransmission apparatus characterized by comprising: The device is used in a server, wherein the device includes: The acquisition module is used to retrieve the message report push table and the client status table; The identification module is used to identify service messages that have been pushed to the target client in the message report push table but have not been received by the target client, and to identify the client status of the target client in the client status table; The polling and resending module is used to poll and resend the service message to the target client at a first preset time interval when the client is in an online state. The client needs to update the push status of delivered or opened messages in a timely manner and record it in the client status table; The server identifies clients that need to resend service messages, rather than clients repeatedly sending message retrieval requests. The step of polling and resending the service message to the target client at a first preset interval includes: Obtain the push time of the service message; Calculate the polling resend time based on the push time and the first preset duration; The service message is pushed to the target client at the specified polling resend time. Before polling and resending the service message to the target client at a first preset time interval, the process further includes: Obtain the remaining validity period and / or priority of the service message; The first preset duration of the service message polling resending interval is determined based on the remaining validity period and / or the priority. When the client is in an offline state, the following is also included: The client status of the target client in the client status table is identified at intervals of a second preset time.

6. A server, characterized by include: A memory, a processor, and a computer program stored in the memory and executable on the processor, the processor executing the program to implement the message polling resending method as described in any one of claims 1-4.

7. A computer-readable storage medium having stored thereon a computer program, characterized in that, The program is executed by the processor to implement the message polling resending method as described in any one of claims 1-4.

Images