Message polling resending method and apparatus, and server and storage medium

Abstract

The present application relates to the technical field of mobile communications, and in particular to a message polling resending method and apparatus, and a server and a storage medium. The method comprises: acquiring a message state table and a client state table; on the basis of the message state table, identifying a service message that fails to be sent, wherein the service message that fails to be sent is a service message that has been pushed to a target client but is not received by the target client; on the basis of the client state table, identifying the target client in an online state; and at an interval of a first preset duration, performing, on the target client in an online state, polling resending of the service message that fails to be sent. Therefore, the problem in the prior art of the performance of a server and the timeliness cannot be taken into account at the same time, which easily causes an excessively high load of the server, and the performance of a client becoming poor is solved.

Description

Message polling resending method, device, server and storage medium

[0001] This application claims priority to Chinese patent application No. 202310755242.0 filed on June 21, 2023, entitled “Message polling retransmission method, device, server and storage medium,” the entire contents of which are incorporated by reference into this application. Technical Field

[0002] The present application relates to the field of mobile communication technology, and in particular to a message polling and resending method, device, server and storage medium. Background Art

[0003] With the increasing integration of client-side connectivity, more and more service operators are pushing various service messages to clients through servers. The service message push process typically involves the client sending a message request to the server, which responds and pushes the service message to the client. If the client doesn't receive a service message for a long time, it periodically resends a message request to the server until the client receives the service message.

[0004] However, the method of periodically sending messages by the client to obtain requests to the server greatly increases the number of communications between the client and the server. Frequent requests between the client and the server will not only increase the load on the server, but also increase the request pressure on the client, resulting in poor performance of the client.

[0005] Summary of the Invention

[0006] The present application provides a message polling and resending method, device, server and storage medium to solve the problems in related technologies that cannot take into account both server performance and timeliness, which easily leads to excessive server load and poor client performance.

[0007] A first embodiment of the present application provides a message polling and resending method, which is applied to a server and includes:

[0008] Get the message status table and client status table;

[0009] Identifying a service message that fails to be sent based on the message status table, wherein the service message that fails to be sent is a service message that has been pushed to a target client but has not been received by the target client;

[0010] Identifying the target client in an online state based on the client state table;

[0011] At intervals of a first preset time, the target client in an online state is polled to resend the failed service message.

[0012] Optionally, the message status table includes a service message identifier and a message status of the service message, and the message status includes a pushed status and a delivered status;

[0013] The identifying, based on the message status table, a service message that fails to be sent, includes:

[0014] The service message whose message status in the message status table is the pushed status is identified as the service message that failed to be sent.

[0015] Optionally, the method further includes:

[0016] In response to the delivered feedback message reported by the client, the message status is updated from the pushed status to the delivered status.

[0017] Optionally, the message status also includes an opened status;

[0018] The method further comprises:

[0019] In response to the opened feedback message reported by the client, the message status is updated from the delivered status to the opened status.

[0020] Optionally, the message status table further includes a client identifier, and each service message identifier is associated with the client identifier; the client status table includes the client identifier and the client status, and the client status includes an online status and an offline status;

[0021] The identifying the target client in an online state based on the client state table includes:

[0022] Determining, based on the message status table, the client identifier corresponding to the service message that failed to be sent;

[0023] The target client in the online state is identified based on the client state table and the determined client identifier.

[0024] Optionally, the message status table also includes the remaining validity period of the service message;

[0025] Identifying a service message that fails to be sent based on the message status, further comprising:

[0026] The service message in the message status table whose message status is "pushed" and whose remaining validity period is not zero is identified as the service message that failed to be sent.

[0027] Optionally, the message status table and the client status table are stored in the server.

[0028] Optionally, the first preset time interval is used to poll the target client in an online state to resend the failed service message:

[0029] Obtaining the push time of the service message that failed to be sent;

[0030] Calculate the polling resending time according to the push time and the first preset time length;

[0031] Push the failed-to-send service message to the target client in an online state at the polling resending moment.

[0032] Optionally, the message status table includes a push time, and the push time is associated with the message status;

[0033] The acquiring the push time of the service message that failed to be sent includes:

[0034] The push time corresponding to the service message whose message status in the message status table is the pushed status is determined as the push time.

[0035] Optionally, before pushing the failed service message to the target client after the first preset time interval, the method further includes:

[0036] Obtaining the remaining validity period and / or priority of the service message that failed to be sent;

[0037] A first preset duration of the push interval of the failed service message is determined according to the remaining validity period and / or the priority.

[0038] Optionally, after identifying the service message that failed to be sent based on the message status table, the method further includes:

[0039] Identifying the target client in an offline state based on the client state table;

[0040] After a second preset time period, the client status of the target client in the offline state is re-identified.

[0041] Optionally, the message status table includes a push table identifier; and / or,

[0042] The client status table includes an update time.

[0043] The second aspect of the present application provides a message polling and resending device, which is applied to a server, wherein the device includes: an acquisition module, which is used to acquire a message status table and a client status table; an identification module, which is used to identify a service message that failed to be sent based on the message status table, wherein the service message that failed to be sent is a service message that has been pushed to a target client but has not been received by the target client; and based on the client status table, identify the target client that is in an online state; a polling and resending module, which is used to poll and resend the service message that failed to be sent to the target client that is in an online state at intervals of a first preset time length.

[0044] The third aspect of the present application provides a server, comprising: 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 and retransmission method as described in the above embodiment.

[0045] The fourth aspect of the present application provides a computer-readable storage medium on which a computer program is stored. The program is executed by a processor to implement a message polling and retransmission method as described in the above embodiment.

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

[0047] The embodiment of the present application monitors the polling and resending of service messages by the server, eliminating the need for the client to repeatedly send message acquisition requests, effectively reducing the number of communications between the client and the server, avoiding frequent requests between the client and the server, reducing server load pressure and server load, and avoiding poor performance of the client; at the same time, the server monitors the status of the client in real time, and performs polling and resending according to the client status, avoiding serial errors in the results of interface requests. In addition, the server regularly polls and resends service messages, effectively taking into account the timeliness of service messages, thereby effectively taking into account the performance and timeliness of the server and improving the user experience of the client user. Thus, the technical problem that the related technology cannot take into account the performance and timeliness of the server, which easily leads to excessive server load and poor performance of the client is solved.

[0048] Additional aspects and advantages of the present application will be given in part in the description below, and in part will become apparent from the description below, or will be learned through practice of the present application. BRIEF DESCRIPTION OF THE DRAWINGS

[0049] The above and / or additional aspects and advantages of the present application will become apparent and easily understood from the following description of the embodiments in conjunction with the accompanying drawings, in which:

[0050] FIG1 is a flow chart of a message polling and resending method provided according to an embodiment of the present application;

[0051] FIG2 is a flow chart of another message polling and resending method provided according to an embodiment of the present application;

[0052] FIG3 is a block diagram of a message polling and resending device according to an embodiment of the present application;

[0053] FIG4 is a schematic diagram of the structure of a server according to an embodiment of the present application. DETAILED DESCRIPTION

[0054] The following describes in detail embodiments of the present application, examples of which are shown in the accompanying drawings, wherein the same or similar reference numerals throughout represent the same or similar elements or elements having the same or similar functions. The embodiments described below with reference to the accompanying drawings are exemplary and are intended to be used to explain the present application, and should not be construed as limiting the present application.

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

[0056] This type of message has very high requirements for timeliness in delivery to the client. If it cannot be delivered in time, the message will lose its meaning.

[0057] However, due to the explosive growth in the number of client users and the limitations of server performance bottlenecks, timely capacity expansion and sufficient budget are impossible to achieve, and many service messages are difficult to balance between server performance and timeliness.

[0058] At present, there are mainly two ways to push service messages: the first way is to use manual or semi-manual monitoring intervention to forcibly push service messages to improve the timeliness of service messages. However, this method will cause the server performance to exceed the warning level, and in severe cases, it will cause the server to crash, resulting in a large number of service messages being unable to be delivered, and even seriously affecting the services of other businesses; the second way is to push service messages, especially time-sensitive messages, in batches to ensure that the server does not exceed the warning performance. However, this method will extend the message push cycle and reduce timeliness, resulting in reduced client user satisfaction, and in severe cases, some users will be lost.

[0059] Based on the above problems, in the related technology, the server receives a message acquisition request sent by the client, and the message acquisition request includes a request push time and a received message list; the request push time is the first push time in the last response message sent by the server that the client last received, and the received message list includes the message identification ID of all messages sent by the server that the client last received; according to the request push time and received message list in the message acquisition request, the server obtains new messages that have not been sent to the client from the message queue, and feeds back a response message to the client, the response message includes a second push time and a new message list, and the new message list includes the message ID and message content of all new messages sent to the client this time, and the second push time is the push time of the new message; wherein, the response message also includes a polling cycle; after receiving the response message, the client counts according to the polling cycle, and when the polling response time is exceeded, a message acquisition request is generated and sent to the message polling server; the polling cycle is set according to the load of the message polling server and / or the number of new messages in the message queue.

[0060] However, in the context of an increasing number of clients and diverse client states, this method has the following problems: multiple requests and interactions between the client and the server result in excessive server load and increased client request pressure; client states are diverse, and there are dependencies between interface requests, which can easily lead to errors in the concatenation of interface request results.

[0061] Therefore, when the server performance cannot be expanded temporarily, but the service message must be pushed to the client user as soon as possible, in order to reduce the impact on the server, especially the client performance, and optimize the request efficiency and accuracy, after the server sends a service message, the client receives the message and uploads the message status, the server obtains the message status (also known as "report push status") and the client status, and determines that the server has sent but has not yet pushed it to the client user (that is, the client has not successfully received it). This type of message can also be called a failed service message; and the client status is determined to be online so that the client can receive the message in time; and then the failed service message is reissued and polled, that is, every N minutes, the service message that meets the reissue conditions is pushed to the client in the online state again, so that the client can receive the service message in time during the next window period for receiving the service message. This window period can be understood as the server querying the message status and the client status, and executing the reissue polling cycle. For example, the server can request the message status and the client status by initiating an interface.

[0062] The following describes a message polling and resending method, device, server and storage medium of an embodiment of the present application with reference to the accompanying drawings. In response to the problem mentioned in the above background technology that the performance and timeliness of the server cannot be taken into account, the present application provides a message polling and resending method, in which a message acquisition request is sent to the server by the client, and the server responds to the message acquisition request and pushes a service message to the client; the server monitors the status of the client in real time, and when the client status is identified as online and no service message is received, it is necessary to poll and resend the service message to the client, otherwise it is not necessary to poll and resend the service message to the client. Thus, the problem of the inability to take into account the performance and timeliness of the server in the related technology, resulting in excessive server load and poor client performance, etc. In some embodiments, when the client status is identified as offline, the client status is repeatedly identified until the client status is online. Since the server identifies the client status and only polls and resends service messages to clients that are online, it avoids invalidly pushing service messages to offline clients, which leads to waste of server resources. It solves the problems in related technologies such as diverse client status, front-end dependencies between interface requests, and the inability of the server to monitor the real-time status of the client, which can easily lead to serial errors in interface request results.

[0063] Specifically, Figure 1 is a flow chart of a message polling and resending method provided by an embodiment of the present application. This method can be applied to a server, for example.

[0064] As shown in FIG1 , the message polling and resending method includes the following steps:

[0065] In step S101, a message status table and a client status table are obtained.

[0066] In some embodiments, the message status of the service message and the client status of the client can be stored in the form of tables, respectively, to form a message status table (also referred to as a message report push table) and a client status table. The server can call the message status table and the client status table to obtain the message status of the service message (also referred to as the push status) from the message status table and obtain the client status from the client status table.

[0067] Among them, the message status table (message report push table) may include a push table identifier, a service message identifier, a client identifier, a remaining validity period, a message status of the service message, and a push time, etc. Among them, the push table identifier may be a push table ID (Identity document); and the service message identifier may be a service message ID. The remaining validity period of a service message (also referred to as a report remaining validity period) may indicate the effective push time of the service message, which may be, for example, the effective time set when the service message is pushed. When the remaining validity period is not zero, it means that the service message corresponding to the remaining validity period is valid and can continue to be pushed to the client. Each service message may correspond to a remaining validity period; or, at least one service message may not be set with a remaining validity period. In some embodiments, the remaining validity period may be fixed, or the remaining validity period changes in real time and is related to the push time. Exemplarily, when a server pushes a service message, it can pre-set an effective push period for each service message, such as two days. The server starts counting from the first time the service message is pushed, and records the moment of the first push as the initial push time. When the count reaches two days set for the effective push period, the service message becomes invalid, and the server will no longer resend or push the service message. Exemplarily, the remaining effective period can be in the form of a countdown. During different cycles of the resending polling process, the push time of the service message may be updated, and the effective push period corresponding to the service message is also updated. The later the push time, the shorter the effective push period.

[0068] The message status of a service message can be a pushed status, a delivered status, or an opened status. The pushed status can be updated based on the message status reported by the server. For example, after the server sends a message to the client, it can update or mark the message status in the message status table as a pushed status.

[0069] Each service message identifier can be associated with a client identifier to indicate the client to which the service message corresponding to the service message identifier is pushed. In other words, the message status table can store the correspondence between service messages and clients, so that the server can push the service message to the corresponding client based on the correspondence.

[0070] In some embodiments, the push time is associated with the service message identifier and message status, indicating the time at which the server pushed the service message to the client. For example, after pushing a service message, the server records the push time and updates the message status corresponding to the service message to "pushed." Upon receiving feedback from the client, the server further updates the message status to "delivered" or "opened." The push time can be 1 minute, 5 minutes, or other timeframes, and can be set based on actual circumstances.

[0071] The client status table may include a client identifier and a client status. The client status may include an online status and an offline status. In some embodiments, the client status table may also include an update time for the client status table. Each time the server or client backend obtains the client status and writes it to the client status table, the current write time may be recorded as the update time.

[0072] In some embodiments, a message report push table and a client status table are provided in the server. In other words, the above-mentioned message status table and client status table can be stored in the server. Exemplarily, the server may include a push unit and a database, wherein the message status table and the client status table can be stored in the database, and the push unit may initiate an interface call to the message status table and the client status table in the database through the server. Among them, the message report push table can be used to record the push status of the service message, and the client status table can be used to record the real-time status of the client, and the client status may include online status and offline status. In an embodiment of the present application, the server may periodically obtain the message report push table and the client status table, such as at intervals of 1 minute or 2 minutes, and the acquisition time may be specifically set according to the requirements of message polling and resending.

[0073] In an embodiment of the present application, the client reports a delivered feedback message or an opened feedback message (such as the second feedback signal mentioned above) of a service message. In this case, the method may further include: updating the message status (push status) of the service message according to the delivered feedback message or the opened feedback message. That is, the delivered status and the opened status can be updated according to the message status reported by the client. Exemplarily, after the client receives the service message pushed by the server, it can send a first feedback message (such as the delivered feedback message mentioned above) to the server, and the server updates the message status of the service message in the message status table from the pushed status to the delivered status based on the first feedback message reported by the client; after the client detects that the user has opened the service message based on, for example, buried point reporting, real-time logs, etc., it can send a second feedback signal (such as the opened feedback message mentioned above) to the server, and the server updates the message status of the service message in the message status table from the delivered status to the opened status based on the second feedback message reported by the client.

[0074] Based on the above, if a service message pushed by the server to the client is successfully received by the client, the message status of the service message will be updated from the Pushed status to the Sent status. Therefore, a service message with the Pushed status in the message status table can be identified as a service message that failed to be sent (i.e., a service message that has been pushed to the target client but has not been received by the target client); a service message with the Delivered status or Opened status can be identified as a service message that was successfully sent (i.e., a service message that has been pushed to the target client and has been successfully received by the target client).

[0075] It is understandable that the delivered feedback message and the opened feedback message reported by the client are response information for the feedback of a specific service message that has been pushed by the server, so the server can update the message status of the specific service message based on the above feedback message. Exemplarily, the delivered feedback message and the opened feedback message can respectively carry a service message identifier, and the server can update the message status of the service message corresponding to the identifier based on the service message identifier. In some embodiments, the client can promptly update the push status of the delivered feedback message or the opened feedback message, and record it in the client status table, so that the server can accurately identify the real-time status of the client. In some embodiments, the client backend or the server can detect the client operation (such as the above-mentioned operation of reporting the delivered feedback message or the opened feedback message to the server) by means of buried point reporting, real-time logs, etc., and update the client status. In this case, the client status can be updated to an online state. In some embodiments, when the server determines based on the log that the client has not performed any operation (such as sending a request or feedback message, etc.) within a set time, it can update the client status to an offline state.

[0076] In step S102, a service message that fails to be sent is identified based on the message status table.

[0077] The service message that failed to be sent is a service message that has been pushed to the target client but has not been received by the target client.

[0078] As described above, a service message whose message status in the message status table is the pushed status may be identified as a service message that fails to be sent.

[0079] In some embodiments, when a service message that failed to be sent is set with a remaining validity period, identifying the service message that failed to be sent based on the message status further includes: identifying a service message whose message status in the message status table is "pushed" and whose remaining validity period is not zero as a service message that failed to be sent. For example, when the valid push time indicated by the remaining validity period is not zero, it means that the service message corresponding to the remaining validity period is within the validity period and can be pushed to the client again.

[0080] It is understandable that the message status table stores the correspondence between service messages and clients, so that the client corresponding to the service message that failed to be sent can be determined based on the correspondence and used as the target client. Exemplarily, the service message identifier, message status, and client identifier in the message status table are one-to-one corresponding. The server can first identify the service message (service message identifier) ​​in the message status table with a message status of pushed as the service message that failed to be sent; then the client indicated by the client identifier corresponding to the service message (service message identifier) ​​is used as the target client.

[0081] In step S103, a target client in an online state is identified based on the client state table.

[0082] As mentioned above, the client status may include an online status and an offline status.

[0083] It can be understood that when the service message has been pushed to the target client and the target client has not received the service message, it means that a service message has failed to be sent, and the server message needs to be polled and resent to the target client. Otherwise (that is, the service message has been successfully received by the target client), it means that the target client does not need to poll and resend the service message.

[0084] As described above, the message status table and the client status table respectively include a client identifier, and in the message status table the client identifier is associated with the message status of the service message, and in the client status table the client identifier is associated with the client status, so that the message status table and the client status table can be linked through the client identifier to determine the target client that is in an online state among all target clients corresponding to the identified failed service message.

[0085] In some embodiments, the step of identifying an online target client based on a client status table may include: determining, based on a message status table, a client identifier corresponding to a failed service message; and identifying an online target client based on the client status table and the determined client identifier. For example, after determining the client identifier corresponding to the failed service message, the server may search the client status corresponding to the client identifier in the client status table, filter out clients with an online status, and then perform a polling retransmission of the service message to the filtered clients.

[0086] In the embodiment of the present application, the server identifies the client that needs to resend the service message, rather than the client repeatedly sending a message acquisition request, thereby effectively reducing the number of communications between the client and the server, avoiding frequent requests between the client and the server, reducing the server load pressure and server load, and avoiding the client's performance from deteriorating; at the same time, the server monitors the client's status in real time, and only polls and resends the client in the online state according to the client status, avoiding the problem of serial errors in the interface request results and invalid push of service messages to the offline client.

[0087] In step S104, the target client in the online state is polled at intervals of a first preset time to resend the failed service message.

[0088] The server executes the above steps S101-S103 each time to identify the service message that failed to be sent and the target client that is online, and can send the service message that failed to be sent to the target client that is online to complete a message resending.

[0089] After the server re-pushes the service message identified as failed to be sent to the target client, it can re-execute steps S101-S103 above. Thus, when the target client is online, the server can poll and resend the service message identified as failed to be sent to the target client at intervals of a first preset duration. The first preset duration can be understood as the period during which the server performs polling and resending. It is understood that the service message identified as failed to be sent may be different in each polling and resending cycle.

[0090] In some embodiments, in the message status table, the server may identify multiple service messages that failed to be sent, and the server may resend the multiple service messages that failed to be sent in sequence.

[0091] The first preset duration may be a pre-set time based on the validity of the service message, such as 10 minutes or 30 minutes, etc., and may be limited based on actual conditions.

[0092] It is understood that in the embodiment of the present application, the server identifies a client that is in an online state and has not successfully received a service message, and polls and resends the service message according to the preset time interval. Otherwise, the client does not need to be polled and resent the service message. The embodiment of the present application sets a reasonable first preset time length 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.

[0093] In an embodiment of the present application, polling and resending a service message to a target client at intervals of a first preset time duration includes: obtaining the push time of the service message that failed to be sent; calculating the polling and resending time based on the push time and the first preset time duration; and pushing the service message that failed to be sent to the target client at the polling and resending time.

[0094] The push time of a failed service message can be the time when the server first sent the service message to the client or the time when it was sent in the previous cycle. It is understood that the service message sent at the push time was not successfully received by the client, and thus the message status corresponding to the service message is pushed. Therefore, the push time can be determined as the push time for the service message with the message status of pushed in the message status table. The polling resend time can be the time when the service message is polled and resent.

[0095] It can be understood that the embodiment of the present application takes the push time as the starting point. When the time for not receiving the service message exceeds the first preset time, the polling reissue time is calculated and the service message is polled and reissued to ensure that the service message is sent to the client in a timely manner. For clients with diverse service message requirements, the first preset time is flexibly set to poll and reissue the service message, thereby improving user satisfaction.

[0096] In an embodiment of the present application, before polling and resending the service message to the target client at an interval of a first preset time, the method also includes: obtaining the remaining validity period and / or priority of the service message that failed to be sent; and determining the first preset time interval for pushing the service message that failed to be sent based on the remaining validity period and / or priority.

[0097] The remaining validity period may be the remaining push validity period set for the service message, such as 5 minutes or 10 minutes. The remaining validity period may be stored in the message status table and associated with the service message identifier and the message status of the service message. The priority may be the level of receiving the service message pre-set by the client, and is not specifically limited. In some embodiments, the shorter the remaining validity period of the service message, the shorter the first preset duration; the higher the priority of the service message, the shorter the first preset duration, so as to ensure the timeliness of the service message and improve user satisfaction.

[0098] It can be understood that the embodiment of the present application determines the first preset duration based on the remaining push validity time and / or priority of the service message, provides the client with valid service messages through the remaining validity period or priority, optimizes the request efficiency of service message polling and reissue, and reduces server pressure.

[0099] In an embodiment of the present application, after identifying a failed service message based on the message status table, when identifying the status of the target client corresponding to the identified failed service message based on the client status table, the identified target client may be in an offline state. When the client status of the target client is offline, the server may further re-identify the client status of these target clients in the client status table at a second preset time interval, thereby continuously detecting changes in the status of the target client. In other words, after identifying a failed service message based on the message status table, the method may further include: identifying the target client in an offline state based on the client status table; and re-identifying the client status of the target client in an offline state at a second preset time interval.

[0100] The second preset duration may be a preset time interval for the server to monitor the client status, such as 5 minutes, and may be limited according to actual conditions.

[0101] In some embodiments, when the server identifies a client as offline, it repeatedly identifies the client's status at intervals of a second predetermined time until the target client's client status is updated to online. After identifying the target client as online, the server immediately performs a polling retransmission of service messages to send the identified failed service messages to the online target client, thereby improving message delivery rates. In this manner, the server monitors the client's status in real time, avoiding errors in the concatenation of interface request results.

[0102] According to the message polling and resending method proposed in the embodiment of the present application, the client sends a message acquisition request to the server, the server responds to the message acquisition request, and pushes the service message to the client; the server monitors the status of the client in real time, and when the client status is identified as offline, the client status is repeatedly identified until the client status is online. When the client status is identified as online and no service message is received, 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 problem of not being able to take into account the performance and timeliness of the server, which easily leads to excessive server load and poor client performance, and the server cannot monitor the real-time status of the client, which easily leads to serial errors in the interface request results.

[0103] The message polling and resending method will be described in detail below with reference to FIG2 . In the following embodiment, a method for resending a message based on a real-time status and polling and pushing is taken as an example. The specific steps are as follows:

[0104] (1) When the server pushes a service message to the client, a message status table (also called a message report push table) can be established, wherein the message status table includes a push table ID, a service message identifier (also called a report ID), a client identifier (also called a client identification code), the remaining validity period of the service message (also called the remaining validity period of the report), the message status of the service message (also called the report status) and the push time. After the server pushes the service message, it updates / identifies the message status of the service message as a pushed state. In addition, the server can treat a service message whose message status is a pushed state and whose remaining validity period is not zero as a service message that has failed to be sent and needs to be resent. The remaining validity period of the report is the effective push time set when the report (service message) is pushed.

[0105] (2) After receiving the service message, the client reports and updates the report status, such as updating the message status of the service message to the delivered state or the opened state.

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

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

[0108] (5) The server identifies a push record in the message report push table in which the report status of the service message is pushed but not delivered. The push record includes a service message that failed to be sent.

[0109] (6) According to (5), the server identifies the client whose client identification code in the push record is in the client status table.

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

[0111] (8) According to (5) to (7), if the client status is identified as online, it is determined that the acquired client is online but has not received the service message, and a push record needs to be resent.

[0112] (9) The server resends the push record obtained in (8) that needs to be resent, that is, it resends the service message that failed to be sent. The resending frequency can be flexibly adjusted according to the timeliness and priority of the service message, such as setting the resending frequency to be once every 10 minutes, once every 30 minutes, etc.

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

[0114] (11) For (9), after resending, if the client still does not receive the message, the server will resend the polling 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. It can be seen that the service message that needs to be resent by the server (i.e., the service message that failed to be sent) must meet the requirement that the remaining validity period has not expired, that is, the remaining validity period is not zero.

[0115] In summary, the message polling and resending method proposed in the embodiment of the present application solves the problem that the related technology cannot take into account both the performance and timeliness of the server, which easily leads to excessive server load and poor client performance, and the server cannot monitor the real-time status of the client, which easily leads to serial errors in the interface request results.

[0116] Next, the message polling and resending device proposed in accordance with an embodiment of the present application will be described with reference to the accompanying drawings.

[0117] FIG3 is a block diagram of a message polling and resending device according to an embodiment of the present application.

[0118] As shown in FIG3 , the message polling and resending device 10 includes: an acquisition module 100 , an identification module 200 and a polling and resending module 300 .

[0119] Among them, the acquisition module 100 is used to obtain the message status table (also known as the message report push table) and the client status table; the identification module 200 is used to identify the service message that failed to be sent based on the message status table, and identify the target client in the online state based on the client status table, wherein the service message that failed to be sent is a service message that has been pushed to the target client but has not been received by the target client; the polling and retransmission module 300 (also known as the push module) is used to send the service message that failed to be sent to the target client in the online state, and can specifically be used to poll and retransmit the service message that failed to be sent to the target client in the online state at intervals of a first preset time length.

[0120] In some embodiments, the identification module 200 can also be used to identify service messages in the message report push table that have been pushed to the target client and 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 can also be used to poll and resend service messages to the target client at intervals of a first preset time length when the client status is online.

[0121] It should be noted that the above explanation of the message polling and resending method embodiment is also applicable to the message polling and resending device of this embodiment, and will not be repeated here.

[0122] According to the message polling and resending device proposed in the embodiment of the present application, the client sends a message acquisition request to the server, the server responds to the message acquisition request, and pushes the service message to the client; the server monitors the status of the client in real time, and when the client status is identified as offline, the client status is repeatedly identified until the client status is online. When the client status is identified as online and no service message is received, the service message needs to be polled and resent, otherwise the client does not need to poll and resend the service message, which effectively solves the problem of frequent requests between the client and the server in the related technology, resulting in excessive server load and poor client performance; the client status is diverse, and there is a front-end dependency relationship between the interface requests, and the real-time status of the client cannot be monitored, which can easily lead to problems such as serial connection errors in the interface request results.

[0123] FIG4 is a schematic diagram of the structure of a server provided in an embodiment of the present application. The server may include:

[0124] Memory 401 , processor 402 , and computer programs stored in the memory 401 and executable on the processor 402 .

[0125] When the processor 402 executes the program, the message polling and resending method provided in the above embodiment is implemented.

[0126] Furthermore, the vehicle further comprises:

[0127] The communication interface 403 is used for communication between the memory 401 and the processor 402 .

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

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

[0130] If memory 401, processor 402, and communication interface 403 are implemented independently, communication interface 403, memory 401, and processor 402 can be interconnected via a bus and communicate with each other. The bus can be an ISA (Industry Standard Architecture) bus, a PCI (Peripheral Component Interconnect) bus, or an EISA (Extended Industry Standard Architecture) bus. Buses can be divided into address buses, data buses, control buses, etc. For ease of illustration, FIG4 shows only one thick line, but this does not mean that there is only one bus or only one type of bus.

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

[0132] The processor 402 may be a CPU (Central Processing Unit), or an ASIC (Application Specific Integrated Circuit), or one or more integrated circuits configured to implement the embodiments of the present application.

[0133] An embodiment of the present application also provides a computer-readable storage medium having a computer program stored thereon, which implements the above-mentioned message polling and retransmission method when executed by a processor.

[0134] Item 1. A message polling and resending method, wherein the method is applied to a server, wherein the method comprises the following steps:

[0135] Get the message report push table and client status table;

[0136] Identify the service message in the message report push table that has been pushed to the target client and has not been received by the target client, and identify the client status of the target client in the client status table; when the client status is online, poll and resend the service message to the target client at intervals of a first preset time length.

[0137] Item 2. The message polling and resending method according to Item 1, wherein the polling and resending of the service message to the target client at intervals of a first preset time length comprises:

[0138] Obtaining the push time of the service message;

[0139] Calculate the polling resending time according to the push time and the first preset time length;

[0140] Push the service message to the target client at the polling resending time.

[0141] Item 3. The message polling and resending method according to Item 1 or 2, wherein, before polling and resending the service message to the target client at a first preset interval, the method further comprises:

[0142] Obtaining the remaining validity period and / or priority of the service message;

[0143] A first preset duration of the service message polling resending interval is determined according to the remaining validity period and / or the priority.

[0144] Item 4. The message polling and resending method according to Item 1, further comprising:

[0145] The client status of the target client in the client status table is identified at intervals of a second preset time.

[0146] Item 5. The message polling and resending method according to Item 1, wherein the message report push table includes one or more of a push table identifier, a service message identifier, a client identifier, a report remaining validity period, a service message push status, and a push time.

[0147] Item 6. The message polling and resending method according to Item 1 or 5, wherein the client reports the delivered message or the opened message of the service message, further comprising:

[0148] The push status of the service message is updated according to the delivered message or the opened message.

[0149] Item 7. The message polling and resending method according to Item 1, wherein the client status table includes one or more of a client identifier, a client status, and an update time.

[0150] Item 8. A message polling and resending device, wherein the device is applied to a server, wherein the device comprises:

[0151] The acquisition module is used to obtain the message report push table and the client status table;

[0152] an identification module, configured to identify a service message in the message report push table that has been pushed to a target client and has not been received by the target client, and to identify a client status of the target client in the client status table;

[0153] The polling and resending module is used to poll and resend the service message to the target client at intervals of a first preset time when the client is in an online state.

[0154] Item 9. A server, comprising: 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 the message polling and retransmission method as described in any one of items 1-7.

[0155] Item 10. A computer-readable storage medium having a computer program stored thereon, wherein the program is executed by a processor to implement the message polling and retransmission method as described in any one of items 1-7.

[0156] In the description of this specification, the description with reference to the terms "one embodiment", "some embodiments", "example", "specific example", or "some examples" means that the specific features, structures, materials or characteristics described in conjunction with the embodiment or example are included in at least one embodiment or example of the present application. In this specification, the schematic representations of the above terms do not necessarily refer to the same embodiment or example. Moreover, the specific features, structures, materials or characteristics described can be combined in any one or N embodiments or examples in a suitable manner. In addition, those skilled in the art can combine and combine different embodiments or examples described in this specification and the features of different embodiments or examples without contradiction.

[0157] Furthermore, the terms "first" and "second" are used for descriptive purposes only and should not be understood to indicate or imply relative importance or implicitly specify the number of technical features indicated. Thus, a feature specified as "first" or "second" may explicitly or implicitly include at least one such feature. In the description of this application, "N" means at least two, for example, two, three, etc., unless otherwise specifically defined.

[0158] Any process or method description in a flowchart or otherwise described herein may be understood to represent a module, fragment or portion of code comprising one or N executable instructions for implementing a custom logical function or process step, and the scope of the preferred embodiments of the present application includes alternative implementations in which functions may be performed in a different order than shown or discussed, including performing functions in a substantially simultaneous manner or in a reverse order depending on the functions involved, which should be understood by those skilled in the art to which the embodiments of the present application pertain.

[0159] It should be understood that various parts of the present application can be implemented using hardware, software, firmware, or a combination thereof. In the above embodiment, the N steps or methods can be implemented using software or firmware stored in a memory and executed by a suitable instruction execution system. If implemented using hardware, as in another embodiment, any one of the following technologies known in the art or a combination thereof can be used: a discrete logic circuit having a logic gate circuit for implementing a logic function on a data signal, an application-specific integrated circuit having a suitable combination of logic gate circuits, a programmable gate array, a field programmable gate array, etc.

[0160] Those skilled in the art will understand that all or part of the steps in the method of the above embodiment can be completed by instructing related hardware through a program, and the program can be stored in a computer-readable storage medium. When the program is executed, it includes one or a combination of the steps of the method embodiment.

[0161] Although the embodiments of the present application have been shown and described above, it can be understood that the above embodiments are exemplary and cannot be understood as limitations on the present application. Ordinary technicians in this field can change, modify, replace and modify the above embodiments within the scope of the present application.

Claims

1. A message polling and resending method, characterized in that: The method is applied to a server, and the method comprises: Get the message status table and client status table; Identifying a service message that has failed to be sent based on the message status table, wherein the service message that has failed to be sent is a service message that has been pushed to a target client but has not been received by the target client; Identify the target client in an online state based on the client state table; At intervals of a first preset time, the target client in an online state is polled to resend the failed service message.

2. The message polling and resending method according to claim 1, characterized in that: The message status table includes a service message identifier and a message status of a service message, wherein the message status includes a pushed status and a delivered status; The identifying, based on the message status table, a service message that fails to be sent, comprises: The service message whose message status in the message status table is in the pushed status is identified as the service message whose sending fails.

3. The message polling and resending method according to claim 2, characterized in that: The method further comprises: In response to the delivered feedback message reported by the client, the message status is updated from the pushed status to the delivered status.

4. The message polling and resending method according to claim 2, characterized in that: The message status also includes an opened status; The method further comprises: In response to the opened feedback message reported by the client, the message status is updated from the delivered status to the opened status.

5. The message polling and resending method according to claim 2, characterized in that: The message status table also includes a client identifier, and each of the service message identifiers is associated with the client identifier; the client status table includes the client identifier and the client status, and the client status includes an online status and an offline status; The step of identifying the target client in an online state based on the client state table includes: Based on the message status table, determining the client identifier corresponding to the service message that failed to be sent; The target client in the online state is identified based on the client state table and the determined client identifier.

6. The message polling and resending method according to claim 2, characterized in that: The message status table also includes the remaining validity period of the service message; Identifying a service message that fails to be sent based on the message status, further comprising: The service message whose message status in the message status table is the pushed status and whose remaining validity period is not zero is identified as the service message that failed to be sent.

7. The message polling and resending method according to any one of claims 1 to 6, characterized in that: The message status table and the client status table are stored in the server.

8. The message polling and resending method according to any one of claims 1 to 6, characterized in that: The step of polling and resending the failed-to-send service message to the target client in an online state at a first preset time interval includes: Obtain the push time of the service message that failed to be sent; Calculate the polling resending time according to the push time and the first preset time length; The failed-to-send service message is pushed to the target client in an online state at the polling resending moment.

9. The message polling and resending method according to claim 8, characterized in that: The message status table includes a push time, and the push time is associated with the message status; The acquiring the push time of the service message that failed to be sent includes: The push time corresponding to the service message whose message status in the message status table is the pushed status is determined as the Push moment.

10. The message polling and resending method according to any one of claims 1 to 6, characterized in that: Before polling and resending the failed-to-send service message to the target client in an online state at the first preset time interval, the method further includes: Obtaining the remaining validity period and / or priority of the service message that failed to be sent; A first preset duration of the polling resending interval of the failed-sending service message is determined according to the remaining validity period and / or the priority.

11. The message polling and resending method according to any one of claims 1 to 6, characterized in that: After identifying the service message that failed to be sent based on the message status table, the method further includes: Identify the target client in an offline state based on the client state table; After a second preset time period, the client status of the target client in the offline state is re-identified.

12. The message polling and resending method according to any one of claims 1 to 6, characterized in that: The message status table includes a push table identifier; and / or, The client status table includes an update time.

13. A message polling and resending device, characterized in that: The device is applied to a server, wherein the device comprises: An acquisition module is used to acquire a message status table and a client status table; an identification module, configured to identify a service message that fails to be sent based on the message status table, wherein the service message that fails to be sent is a service message that has been pushed to a target client but has not been received by the target client; and to identify the target client that is in an online state based on the client status table; The polling and resending module is used to poll and resend the failed service message to the target client in the online state at intervals of a first preset time.

14. A server, characterized in that: include: 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 the message polling and resending method according to any one of claims 1 to 12.

15. A computer-readable storage medium having a computer program stored thereon, characterized in that: The program is executed by a processor to implement the message polling and resending method according to any one of claims 1 to 12.

Images