IoT technology-based message pushing method, and apparatus

Abstract

The present application relates to the field of Internet of Things. Disclosed are an IOT technology-based message pushing method, and an apparatus. The method is executed by a server, and comprises: acquiring configuration information of a target client, the configuration information comprising a first configuration result for a maximum reception rate and a second configuration result for the number of pushing batches; determining first pushing parameters of the target client on the basis of the first configuration result and the second configuration result, the first pushing parameters comprising a first pushing rate and a first batch quantity of a first batch of messages, and sending the first batch of messages to the target client according to the first pushing parameters; acquiring feedback information; and, on the basis of the feedback information and the configuration information, determining second pushing parameters, the second pushing parameters comprising a second pushing rate and a second batch quantity of a second batch of messages, and the second batch of messages referring to messages to be sent to the target client in a next batch. The present application is used for effectively controlling the reasonability of message pushing.

Description

A message push method and device based on IOT technology

[0001] This application claims priority to Chinese patent application No. 202311225959.0, filed with the State Intellectual Property Office of China on September 21, 2023, entitled “A method and device for pushing messages,” the entire contents of which are incorporated herein by reference. This application also claims priority to Chinese patent application No. 202311786503.1, filed with the State Intellectual Property Office of China on December 22, 2023, entitled “A method and device for pushing messages based on IoT technology,” the entire contents of which are incorporated herein by reference. Technical Field

[0002] The present application relates to the field of Internet of Things, and in particular to a message push method and device based on IOT technology. Background Art

[0003] In subscription-based push messaging systems, servers often need to push batches of messages related to a client's business data to a specific client. For example, in SMS messaging, a client can send SMS messages to 10 users through the SMS server. When the user devices of these 10 users return a message indicating whether the SMS was successfully sent, the server needs to push these 10 messages to the client.

[0004] The number of messages a server sends to a client per second is called the push rate. If the server's push rate is too high, the client may experience malfunctions or message loss. If the server's push rate is too low, the client may experience significant delays in receiving messages.

[0005] Therefore, it is very necessary for the message system to accurately control push parameters such as push rate and push messages reasonably.

[0006] Summary of the Invention

[0007] The present application provides a message push method and device based on IOT technology, which is used to effectively control the rationality of message push.

[0008] In order to achieve the above objectives, this application adopts the following technical solutions.

[0009] In the first aspect, an embodiment of the present application provides a message push method based on IOT technology, which is executed by a server, and the server is used to receive messages sent by a sender. A buffer queue is set in the server, and the buffer queue is used to cache messages, including: obtaining configuration information of the target client, the configuration information including a first configuration result for the maximum receiving rate and a second configuration result for the number of push batches; based on the first configuration result and the second configuration result, determining the first push parameter of the target client, the first push parameter including the first push rate and the first batch number of the first batch of messages, and the buffer queue including the first batch of messages; sending the first batch of messages to the target client according to the first push parameter; obtaining feedback information, the feedback information is used to indicate the situation of the target client receiving the first batch of messages; determining the second push parameter based on the feedback information and the configuration information, the second push parameter including the second push rate and the second batch number of the second batch of messages, and the second batch of messages refers to the messages sent to the target client in the next batch.

[0010] In the above method, since the server can obtain the configuration information of the target client, the server can accurately know the information related to the receiving capability of the target client configured based on the performance of the receiving end (for example, at least one of the maximum receiving rate, batch push address, batch number, status code, error code, or additional storage resources). In this way, when the server pushes messages to the target client, it can adaptively adjust the push parameters of the target client in the previous batch based on the configuration feedback mechanism. For example, the server can accurately know the situation of the target client receiving the first batch of messages through the feedback information returned by the target client for the messages pushed in the previous batch (that is, the first batch of messages). Then, by combining the configuration information and feedback information of the target client, the server can more accurately adaptively adjust the push parameters corresponding to the first batch of messages (that is, the first push parameters) to obtain the second push parameters, thereby making the second batch of messages subsequently pushed based on the second push parameters more in line with the current receiving capability of the target client, so as to effectively control the rationality of message push.

[0011] In one implementation, the configuration information includes a status code and an error code, the status code is used to indicate a first adjustment strategy, and the error code is used to indicate a second adjustment strategy; based on the feedback information and the configuration information, the second push parameter is determined, including: if the feedback information contains a feedback code, and the feedback code is a status code, then based on the first adjustment strategy, the second push parameter is determined; if the feedback information contains a feedback code, and the feedback code is a status code and an error code, then based on the second adjustment strategy, it is determined as the second push parameter.

[0012] In the above implementation, the server can make flexible adjustments based on the feedback code and configuration information included in the feedback information. Different feedback codes will result in different adjustment strategies for determining the second push parameters, so that the second push parameters can be determined more accurately.

[0013] In one implementation, based on the first adjustment strategy, determining the second push parameter includes: determining the rate adjustment result of the first push rate; based on the rate adjustment result, the first adjustment strategy and the first push parameter, determining the second push rate and the second batch number respectively; and determining the push parameters including the second push rate and the second batch number as the second push parameter.

[0014] In the above implementation method, when the feedback code of the feedback information is a status code, the determination of the second push parameter is related to the rate adjustment result of the first push rate, that is, different rate adjustment results will correspond to different second push parameters. This flexible adjustment of the push parameters can more accurately determine the second push parameters.

[0015] In one implementation, the second push rate and the second batch quantity are determined respectively based on the rate adjustment result, the first adjustment strategy and the first push parameter, including: if the rate adjustment result indicates that the first push rate is the initial push rate, then based on the first configuration result and the first adjustment strategy, the second push rate is determined, and the first batch quantity is determined as the second batch quantity; if the rate adjustment result indicates that the first push rate is the adjusted push rate, then the first push rate is determined as the second push rate, and based on the client feedback parameters and the first adjustment strategy, the second batch quantity is determined; the client feedback parameters include performance parameters and network parameters fed back by the target client.

[0016] In the above implementation, when the first push rate in the first push parameter has not been adjusted, the second push rate can be determined based on the first configuration result and the first adjustment strategy, that is, only the push rate needs to be adjusted, and there is no need to adjust the first batch number in the first push parameter. When the first push rate in the first push parameter has been adjusted, it is necessary to further adjust the first batch number, which means that in the embodiment of the present application, there is no need to repeatedly adjust the same parameter (for example, push rate or batch number), but rather the second push parameter can be determined quickly and more accurately by adjusting the push rate first and then adjusting the batch number.

[0017] In one implementation, the second push rate is determined based on the first configuration result and the first adjustment strategy, including: when the first configuration result indicates that the target client has configured the maximum receiving rate, based on the first adjustment strategy, the maximum receiving rate is determined as the second push rate; when the first configuration result indicates that the target client has not configured the maximum receiving rate, the second push rate is determined based on the first adjustment strategy and the client feedback parameter.

[0018] In the above implementation, the embodiment of the present application can adjust the target clients with and without the maximum receiving rate configured in different ways according to the first configuration result for the maximum receiving rate, thereby improving the flexibility of parameter adjustment.

[0019] In one implementation, determining the second push parameter based on the second adjustment strategy includes: determining the target push parameter indicated by the second adjustment strategy; if the target push parameter is a target push rate or a target batch quantity, determining the second push parameter based on the target push parameter and the first push parameter; if the target push parameter includes a target push rate and a target batch quantity, determining the target push parameter as the second push parameter.

[0020] In the above implementation, different error codes may indicate different target push parameters. For example, only one of the push rate or batch quantity may be adjusted, or both the push rate and batch quantity may be adjusted. This adjustment method is more flexible.

[0021] In one implementation, the buffer queue includes N queues with different push priorities, where N is a positive integer; based on the first configuration result and the second configuration result, the first push parameter of the target client is determined, including: determining the queue with the highest push priority in the buffer queue as the target queue, and determining the target client based on the client corresponding to the target queue; determining the first push rate of the target client based on the first configuration result; determining the first batch quantity of the target client based on the second configuration result; and determining the push parameters including the first push rate and the first batch quantity as the first push parameters.

[0022] In the above implementation, since the N queues included in the buffer queue have different push priorities, this means that when pulling from the buffer queue, it is necessary to give priority to pulling the queue with the highest push priority, that is, the content of the target queue can be sent first, which will effectively avoid the server's backlog of high-value messages (for example, verification code messages), thereby achieving stable operation of high-value services for high-value customers. In addition, the server needs to determine the push rate and batch quantity of the first batch of messages according to the configuration information for the maximum receiving rate and batch push configuration results, so as to obtain push parameters (i.e., the first push parameters) that are more in line with the receiving capacity of the target client, rather than adopting an unfounded attempt method. Therefore, the parameter determination method provided in the embodiment of the present application is more reasonable.

[0023] In one implementation, based on the first configuration result, determining the first push rate of the target client includes: if the first configuration result indicates that the target client has been configured with a maximum receiving rate, determining the maximum receiving rate as the first push rate of the target client; if the first configuration result indicates that the target client has not been configured with a maximum receiving rate, determining the first push rate of the target client based on the client type of the target client.

[0024] In the above implementation, the server can determine the first push parameters of the target clients with and without configured maximum receiving rates in different ways according to the configuration results for the maximum receiving rate in the configuration information, thereby improving the flexibility and rationality of determining the push parameters.

[0025] In one implementation, based on the client type of the target client, a first push rate of the target client is determined, including: when the client type of the target client is the first type, the default push rate is determined as the first push rate of the target client, and the first type is used to indicate that the target client is a client that sends business data for the first time; when the client type of the target client is the second type, based on the historical push rate of the target client, the first push rate of the target client is determined, and the second type is used to indicate that the target client is a client that has sent business data.

[0026] In the above implementation, the push rates of the first type of target clients (e.g., new clients) and the second type of clients (e.g., old clients) can be determined in different ways according to the type of target clients, thereby improving the flexibility of determining the first push rate.

[0027] In one implementation, the configuration information includes a third configuration result for a batch callback address; and sending the first batch of messages to a target client based on a first push parameter, including: if the third configuration result indicates that the target client has configured a unified batch callback address, sending the first batch of messages to the target client based on the unified batch callback address and the first push parameter; if the third configuration result indicates that the target client has configured batch callback addresses corresponding to M business types, searching for a target batch callback address that matches the business type corresponding to the first batch of messages from the M batch callback addresses, and sending the first batch of messages to the target client based on the target batch callback address and the first push parameter, where M is a positive integer.

[0028] In this implementation, messages can be flexibly pushed to target clients based on their different configurations and the callback addresses they use for messages. If the third configuration result indicates that the target client has configured multiple batch callback addresses, the server can directly distribute the first batch of messages based on their service types. This effectively avoids a backlog of high-value messages (e.g., verification code messages) on the server, ensuring that high-priority services are completely unaffected by low-priority services.

[0029] In one implementation, the method further includes: receiving a data sending request from a target client, the data sending request including business data associated with the target client and an object identifier of a business object to be sent; sending the business data to the business object based on the object identifier; receiving a message for describing the business data, and storing the received message.

[0030] In the above implementation, after sending the business data in the data sending request to the business object, the server can temporarily store the received message instead of directly pushing it to the target client when it is received, which can effectively avoid uncontrolled rate.

[0031] In one implementation, the method also includes: when the time difference between the current timestamp and the previous division timestamp reaches the division time threshold, determining the messages stored in the server as the initial queue; based on the division factors, dividing and sorting the initial queue to obtain a message queue, and the message queue is used to determine the buffer queue.

[0032] In the above implementation, the server can re-divide and sort the messages temporarily stored in itself every division period, so that when it is subsequently based on the buffer queue, it can give priority to sending high-value messages (for example, verification code messages) to achieve stable operation of high-value services for high-value customers.

[0033] In one implementation, the division factors include a first division factor, the first division factor is related to A business types, and A is a positive integer; based on the division factors, the initial queue is divided and sorted to obtain a buffer queue, including: based on the business type corresponding to each message in the initial queue, the initial queue is divided and processed to obtain A first queues; according to the push priorities corresponding to the A business types, the A first queues are sorted to obtain a first sorted queue; based on the first sorted queue, the message queue is determined.

[0034] In the above implementation, the server can divide and sort the initial queue according to the business type (for example, verification code type, promotion type, notification type, etc.), so that messages with high timeliness requirements can be sorted first so that they can be sent first later, thereby effectively avoiding the backlog of high-timeliness messages.

[0035] In one implementation, the division factor also includes a second division factor, the division priority of the second division factor is lower than the division priority of the first division factor, and the second division factor is related to B customer levels, where B is a positive integer; based on the first sorting queue, determining the message queue includes: based on the customer level corresponding to each message in the first sorting queue, dividing and processing the A first queues in the first sorting queue respectively to obtain (A*B) second queues; sorting the (A*B) second queues according to the push priorities corresponding to the B customer levels to obtain a second sorting queue; determining the message queue based on the second sorting queue.

[0036] In the above implementation, after the server divides and sorts the initial queue according to the business type, it can also divide and sort each first queue according to the customer level, so that the messages of high-value customers can be sorted first so that they can be sent first in the future, thereby achieving stable operation of the business of high-value customers.

[0037] In one implementation, the division factors also include a third division factor, the division priority of the third division factor is lower than the division priority of the second division factor, and the third division factor is related to C push rates, where C is a positive integer; based on the second sorting queue, determining the message queue includes: based on the client corresponding to each message in the second sorting queue, at the push rate determined by the current timestamp, dividing and processing the (A*B) second queues in the second sorting queue respectively to obtain (A*B*C) third queues; sorting the (A*B*C) third queues according to the push priorities corresponding to the C push rates to obtain the message queue.

[0038] In the above implementation, after the server divides and sorts the initial queue according to business type and customer level, it can also divide and sort each second queue according to the push rate, so as to effectively avoid the situation where slow clients easily cause accumulation and affect fast clients.

[0039] In one implementation, the method further includes: determining the message batches corresponding to the first batch of messages and the number of remaining messages, respectively, where the remaining messages are messages associated with the target client in the buffer queue other than the first batch of messages; if the message batch reaches a batch threshold and the number of messages reaches a number threshold, generating a prompt message for instructing the target client to upgrade; and sending the prompt message to the target client.

[0040] In the above implementation, when the server determines that there are still a large number of messages to be sent to the target client after adjusting the push parameters multiple times, the server can promptly notify the target client by sending a prompt message generated by itself to the target client, so as to effectively avoid message backlog in the server.

[0041] In one implementation, the method further includes: receiving a storage purchase request from a target client; allocating additional storage resources to the target client based on the storage purchase request, the additional storage resources being used to store messages associated with the target client to be sent when the target client's receiving capacity is insufficient.

[0042] In the above implementation, when the server receives a storage purchase request from a target client, it can allocate additional storage resources to the target client, thereby effectively avoiding the situation where messages are lost due to insufficient receiving capacity of the target client itself.

[0043] In one implementation, the method further includes: receiving a message pull request from a target client; and sending the message in the additional storage resource to the target client.

[0044] In the above implementation, after receiving the message pull request sent by the target client, the server can send the message in the additional storage resources to the target client, that is, the target client can receive the message at this time, which can reduce the situation where the target client has no remaining computing power and causes the message to be lost.

[0045] On the second aspect, an embodiment of the present application provides a message push method based on IOT technology, which is executed by a target client, and the target client is used to send configuration information associated with the receiving capability of the target client to the server, the configuration information including a first configuration result for the maximum receiving rate and a second configuration result for the batch quantity, including: receiving the first batch of messages sent by the server; determining feedback information, the feedback information is used to indicate the situation of the target client receiving the first batch of messages; sending feedback information to the server; receiving the second batch of messages from the server, and the second push parameters corresponding to the second batch of messages are determined based on the feedback information and the configuration information.

[0046] In the above method, since the target client is most aware of its own performance as a receiver, after sending configuration information related to the target client's receiving capabilities to the server, message push can be implemented based on a configuration feedback mechanism. For example, when the target client receives the first batch of messages sent by the server, it can dynamically return feedback information indicating its own receiving capabilities to the server, thereby achieving the goal of receiving the next batch of messages (i.e., the second batch of messages) that are more in line with the target client's current receiving capabilities, thereby effectively controlling the rationality of message push.

[0047] In one implementation, the configuration information includes H configuration parameters, where H is a positive integer, and the H configuration parameters include at least one of a maximum receiving rate, a number of push batches, a batch callback address, a status code, an error code, or additional storage resources.

[0048] In the above implementation, the target client can flexibly configure at least one of the configuration parameters according to its own performance. That is, the target client can support dynamic adjustment of push parameters through the configuration feedback mechanism to better meet customer service demands, thereby controlling the rationality of message push.

[0049] In one implementation, the method further includes: displaying prompt information sent by the server, the prompt information being used to instruct the target client to upgrade; and adjusting the receiving capability of the target client in response to a client upgrade operation in response to the prompt information.

[0050] In the above implementation, after receiving the prompt information sent by the server, the target client can upgrade the client to improve its own receiving ability, thereby controlling the rationality of message push.

[0051] In one implementation, the method further includes: displaying a prompt message sent by the server, the prompt message being used to instruct the target client to upgrade; generating a storage purchase request in response to a storage purchase operation for the prompt message, the storage purchase request being used to request the server to allocate additional storage resources for the target client, the additional storage resources being also used to store messages associated with the target client to be sent when the target client's receiving capacity is insufficient; and sending the storage purchase request to the server.

[0052] In the above implementation, after receiving the prompt information sent by the server, the target client can purchase additional storage resources to alleviate the pressure of current message reception, thereby controlling the rationality of message push.

[0053] In one implementation, the method further includes: sending a message pull request to the server; and receiving a message returned by the server from the additional storage resource.

[0054] In the above implementation, the target client can actively pull messages from the additional storage resources of the server, so that the server returns messages that are consistent with its own receiving capabilities based on the message pull request, rather than the server actively pushing messages. This can effectively reduce the situation where the target client is unable to receive messages due to insufficient computing power.

[0055] On the third aspect, an embodiment of the present application provides a message push device based on IOT technology, which is applied to a server, and the server is used to receive messages sent by a sender. A buffer queue is set in the server, and the buffer queue is used to cache messages, including: a processing unit, used to obtain configuration information of the target client, the configuration information includes a first configuration result for the maximum receiving rate and a second configuration result for the number of push batches; the processing unit is also used to determine the first push parameter of the target client based on the first configuration result and the second configuration result, the first push parameter includes the first push rate and the first batch number of the first batch of messages, and the buffer queue includes the first batch of messages; the transceiver unit is used to send the first batch of messages to the target client according to the first push parameter; the processing unit is also used to obtain feedback information, and the feedback information is used to indicate the situation of the target client receiving the first batch of messages; the processing unit is also used to determine the second push parameter based on the feedback information and the configuration information, the second push parameter includes the second push rate and the second batch number of the second batch of messages, and the second batch of messages refers to the messages sent to the target client in the next batch.

[0056] In one implementation, the configuration information includes a status code and an error code, the status code is used to indicate a first adjustment strategy, and the error code is used to indicate a second adjustment strategy; the processing unit is also used to determine a second push parameter based on the feedback information and the configuration information, including: a processing unit, specifically used to determine the second push parameter based on the first adjustment strategy if the feedback information contains a feedback code and the feedback code is a status code; a processing unit, specifically used to determine the second push parameter based on the second adjustment strategy if the feedback information contains a feedback code and the feedback code is a status code and an error code.

[0057] In one implementation, a processing unit is specifically used to determine a second push parameter based on a first adjustment strategy, including: a processing unit is specifically used to determine a rate adjustment result of the first push rate; a processing unit is specifically used to determine a second push rate and a second batch quantity based on the rate adjustment result, the first adjustment strategy, and the first push parameter; a processing unit is specifically used to determine the push parameters including the second push rate and the second batch quantity as the second push parameter.

[0058] In one implementation, a processing unit is specifically used to determine the second push rate and the second batch quantity based on the rate adjustment result, the first adjustment strategy and the first push parameter, respectively, including: a processing unit is specifically used to determine the second push rate based on the first configuration result and the first adjustment strategy if the rate adjustment result indicates that the first push rate is the initial push rate, and determine the first batch quantity as the second batch quantity; a processing unit is specifically used to determine the first push rate as the second push rate if the rate adjustment result indicates that the first push rate is the adjusted push rate, and determine the second batch quantity based on the client feedback parameters and the first adjustment strategy; the client feedback parameters include performance parameters and network parameters fed back by the target client.

[0059] In one implementation, the processing unit is specifically used to determine the second push rate based on the first configuration result and the first adjustment strategy, including: a processing unit is specifically used to determine the maximum receiving rate as the second push rate based on the first adjustment strategy when the first configuration result indicates that the target client has configured the maximum receiving rate; a processing unit is specifically used to determine the second push rate based on the first adjustment strategy and the client feedback parameter when the first configuration result indicates that the target client has not configured the maximum receiving rate.

[0060] In one implementation, the processing unit is specifically used to determine the second push parameter based on the second adjustment strategy, including: a processing unit, specifically used to determine the target push parameter indicated by the second adjustment strategy; a processing unit, specifically used to determine the second push parameter based on the target push parameter and the first push parameter if the target push parameter is a target push rate or a target batch quantity; a processing unit, specifically used to determine the target push parameter as the second push parameter if the target push parameter includes a target push rate and a target batch quantity.

[0061] In one implementation, the buffer queue includes N queues with different push priorities, where N is a positive integer; the processing unit is also used to determine the first push parameters of the target client based on the first configuration result and the second configuration result, including: a processing unit, specifically used to determine the queue with the highest push priority in the buffer queue as the target queue, and determine the target client based on the client corresponding to the target queue; a processing unit, specifically used to determine the first push rate of the target client based on the first configuration result; a processing unit, specifically used to determine the first batch quantity of the target client based on the second configuration result; a processing unit, specifically used to determine the push parameters including the first push rate and the first batch quantity as the first push parameters.

[0062] In one implementation, a processing unit is specifically used to determine a first push rate of a target client based on a first configuration result, including: a processing unit is specifically used to determine the maximum receiving rate as the first push rate of the target client if the first configuration result indicates that the target client has been configured with a maximum receiving rate; a processing unit is specifically used to determine the first push rate of the target client based on the client type of the target client if the first configuration result indicates that the target client has not been configured with a maximum receiving rate.

[0063] In one implementation, a processing unit is specifically used to determine a first push rate of a target client based on a client type of the target client, including: a processing unit is specifically used to determine a default push rate as the first push rate of the target client when the client type of the target client is the first type, the first type being used to indicate that the target client is a client that sends business data for the first time; a processing unit is specifically used to determine the first push rate of the target client based on a historical push rate of the target client when the client type of the target client is the second type, the second type being used to indicate that the target client is a client that has sent business data.

[0064] In one implementation, the configuration information includes a third configuration result for a batch callback address; a processing unit is specifically used to send the first batch of messages to the target client based on the first push parameter, including: a processing unit is specifically used to send the first batch of messages to the target client based on the unified batch callback address and the first push parameter if the third configuration result indicates that the target client has configured a unified batch callback address; a processing unit is specifically used to search for a target batch callback address that matches the business type corresponding to the first batch of messages from the M batch callback addresses if the third configuration result indicates that the target client has configured batch callback addresses corresponding to M business types, and send the first batch of messages to the target client based on the target batch callback address and the first push parameter, where M is a positive integer.

[0065] In one implementation, the message push device also includes: a transceiver unit, which is also used to receive a data sending request from a target client, the data sending request includes business data associated with the target client and an object identifier of the business object to be sent; the transceiver unit is also used to send business data to the business object based on the object identifier; the transceiver unit is also used to receive messages used to describe business data; and the processing unit is also used to store the received messages.

[0066] In one implementation, the message push device also includes: a processing unit, which is also used to determine the messages stored in the server as the initial queue when the time difference between the current timestamp and the previous division timestamp reaches the division time threshold; the processing unit is also used to divide and sort the initial queue based on the division factor to obtain a message queue, and the message queue is used to determine the buffer queue.

[0067] In one implementation, the division factor includes a first division factor, which is related to A business types, where A is a positive integer; the processing unit is also used to divide and sort the initial queue based on the division factor to obtain a buffer queue, including: a processing unit, which is specifically used to divide and process the initial queue based on the business type corresponding to each message in the initial queue to obtain A first queues; a processing unit, which is specifically used to sort the A first queues according to the push priorities corresponding to the A business types to obtain a first sorted queue; and a processing unit, which is specifically used to determine the message queue based on the first sorted queue.

[0068] In one implementation, the division factor also includes a second division factor, the division priority of the second division factor is lower than the division priority of the first division factor, and the second division factor is related to B customer levels, where B is a positive integer; the processing unit is specifically used to determine the message queue based on the first sorting queue, including: a processing unit is specifically used to divide and process the A first queues in the first sorting queue based on the customer level corresponding to each message in the first sorting queue, to obtain (A*B) second queues; the processing unit is specifically used to sort the (A*B) second queues according to the push priorities corresponding to the B customer levels, to obtain a second sorting queue; the processing unit is specifically used to determine the message queue based on the second sorting queue.

[0069] In one implementation, the division factors also include a third division factor, the division priority of the third division factor is lower than the division priority of the second division factor, and the third division factor is related to C push rates, where C is a positive integer; the processing unit is specifically used to determine the message queue based on the second sorting queue, including: a processing unit is specifically used to divide and process the (A*B) second queues in the second sorting queue based on the push rate determined by the current timestamp of the client corresponding to each message in the second sorting queue, to obtain (A*B*C) third queues; the processing unit is specifically used to sort the (A*B*C) third queues according to the push priorities corresponding to the C push rates, to obtain the message queue.

[0070] In one implementation, the message push device also includes: a processing unit, which is also used to determine the message batches corresponding to the first batch of messages and the number of messages of the remaining messages, respectively, and the remaining messages are messages associated with the target client in the buffer queue other than the first batch of messages; the processing unit is also used to generate a prompt message for instructing the target client to upgrade if the message batch reaches a batch threshold and the number of messages reaches a number threshold; the transceiver unit is also used to send the prompt message to the target client.

[0071] In one implementation, the message push device also includes: a transceiver unit, which is also used to receive a storage purchase request from a target client; a processing unit, which is also used to allocate additional storage resources to the target client based on the storage purchase request, and the additional storage resources are used to store messages associated with the target client to be sent when the target client's receiving capacity is insufficient.

[0072] In one implementation, the message push device further includes: a transceiver unit, further configured to receive a message pull request from a target client; and a transceiver unit, further configured to send the message in the additional storage resource to the target client.

[0073] In the fourth aspect, an embodiment of the present application provides a message push device based on IOT technology, which is applied to a target client, and the target client is used to send configuration information associated with the receiving capability of the target client to the server, and the configuration information includes a first configuration result for the maximum receiving rate and a second configuration result for the batch number, including: a transceiver unit, used to receive the first batch of messages sent by the server; a processing unit, used to determine feedback information, and the feedback information is used to indicate the situation where the target client receives the first batch of messages; the transceiver unit is also used to send feedback information to the server; the transceiver unit is also used to receive the second batch of messages from the server, and the second push parameters corresponding to the second batch of messages are determined based on the feedback information and the configuration information.

[0074] In one implementation, the configuration information includes H configuration parameters, where H is a positive integer, and the H configuration parameters include at least one of a maximum receiving rate, a number of push batches, a batch callback address, a status code, an error code, or additional storage resources.

[0075] In one implementation, the message push device also includes: a processing unit, which is also used to display the prompt information sent by the server, the prompt information is used to instruct the target client to upgrade; the processing unit is also used to respond to the client upgrade operation for the prompt information and adjust the receiving capability of the target client.

[0076] In one implementation, the message push device also includes: a processing unit, which is also used to display the prompt information sent by the server, and the prompt information is used to instruct the target client to upgrade; the processing unit is also used to respond to the storage purchase operation for the prompt information and generate a storage purchase request, and the storage purchase request is used to request the server to allocate additional storage resources to the target client, and the additional storage resources are also used to store messages associated with the target client to be sent when the target client's receiving capacity is insufficient; the transceiver unit is also used to send a storage purchase request to the server.

[0077] In one implementation, the message push device further includes: a transceiver unit, further configured to send a message pull request to the server; and a transceiver unit, further configured to receive a message returned by the server from the additional storage resource.

[0078] In the fifth aspect, the present application provides a message push system based on IOT technology, and the message push system includes various modules for executing the message push method in the first aspect or any possible implementation of the first aspect, and the second aspect or any possible implementation of the second aspect.

[0079] Among them, the message push system has the function of implementing the methods in the first and second aspects above. The function can be implemented by hardware, or by hardware executing corresponding software implementation. The hardware or software includes one or more modules corresponding to the above functions. In one possible design, the message push system includes: a server and a target client, the server is used to receive messages sent by the sender, and a buffer queue is set in the server, and the buffer queue is used to cache messages; the server obtains configuration information of the target client, and the configuration information includes a first configuration result for the maximum receiving rate and a second configuration result for the number of push batches; the server determines the first push parameter of the target client based on the first configuration result and the second configuration result, and the first push parameter includes the first push rate and the first batch number of the first batch of messages; the buffer queue includes the first batch of messages; the server sends the first batch of messages to the target client according to the first push parameter; the target client determines feedback information; the feedback information is used to indicate the situation of the target client receiving the first batch of messages; the target client sends feedback information to the server; the server determines the second push parameter based on the feedback information and the configuration information; the second push parameter includes the second push rate and the second batch number of the second batch of messages; the second batch of messages refers to the messages sent to the target client in the next batch.

[0080] In the sixth aspect, an embodiment of the present application provides a message push device based on IOT technology, including a memory and a processor, the memory is used to store computer instructions, and the processor is used to call and run computer instructions from the memory to implement a method such as the first aspect or any one of the implementation methods of the first aspect, or to implement a method such as the second aspect or any one of the implementation methods of the second aspect.

[0081] In the seventh aspect, an embodiment of the present application provides a computer-readable storage medium based on IOT technology, wherein the computer-readable storage medium stores instructions. When the instructions are executed on a processor, the method as in the first aspect or any one of the implementation methods in the first aspect is implemented, or the method as in the second aspect or any one of the implementation methods in the second aspect is implemented.

[0082] In an eighth aspect, an embodiment of the present application provides a computer program product based on IOT technology, the computer program product including instructions, which, when executed on a processor, implement a method as in the first aspect or any one of the implementations of the first aspect, or implement a method as in the second aspect or any one of the implementations of the second aspect.

[0083] The technical effects produced by any implementation method in the above-mentioned second to eighth aspects and each aspect can refer to the above-mentioned first aspect and the corresponding implementation method in the first aspect, and the repetitions will not be repeated here. BRIEF DESCRIPTION OF THE DRAWINGS

[0084] FIG1 is a schematic diagram of a network architecture provided in an embodiment of the present application;

[0085] FIG2 is an interaction diagram of a method for message push provided in an embodiment of the present application;

[0086] FIG3 is a schematic diagram of a scenario in which messages are pushed according to push priority according to an embodiment of the present application;

[0087] FIG4 is a schematic diagram of a control method for message push in a short message service according to an embodiment of the present application;

[0088] FIG5 is a schematic diagram of a control method for message push in a device access service according to an embodiment of the present application;

[0089] FIG6 is a schematic diagram of a method for message push provided in an embodiment of the present application;

[0090] FIG7 is a schematic diagram of a scenario of dividing an initial queue provided by an embodiment of the present application;

[0091] FIG8 is a schematic diagram of a framework for message push according to push priority provided by an embodiment of the present application;

[0092] FIG9 is a second schematic diagram of a method for message push provided in an embodiment of the present application;

[0093] FIG10 is a structural diagram of a message push device based on IOT technology provided in an embodiment of the present application;

[0094] FIG11 is a second structural diagram of a message push device based on IOT technology provided in an embodiment of the present application. DETAILED DESCRIPTION

[0095] The technical solutions in the embodiments of the present application will be described below in conjunction with the drawings in the embodiments of the present application. In order to facilitate the clear description of the technical solutions in the embodiments of the present application, in the embodiments of the present application, words such as "first" and "second" are used to distinguish between identical or similar items with substantially the same functions and effects. Those skilled in the art will understand that words such as "first" and "second" do not limit the quantity and execution order, and words such as "first" and "second" do not necessarily limit differences. At the same time, in the embodiments of the present application, words such as "exemplary" or "for example" are used to indicate examples, illustrations or explanations. Any embodiment or design described as "exemplary" or "for example" in the embodiments of the present application should not be interpreted as being more preferred or more advantageous than other embodiments or design solutions. Specifically, the use of words such as "exemplary" or "for example" is intended to present related concepts in a concrete way for easy understanding.

[0096] To facilitate understanding of the technical solutions provided in the embodiments of the present application, the following terms related to the message system involved in the embodiments of the present application are first introduced:

[0097] 1. Message

[0098] In short message services (e.g., Message&SMS, MSGSMS), the message here can be a status report describing whether the short message is actually sent to a device (e.g., a user terminal such as a mobile phone), which can also be called a short message receipt. In the IoT Device Access (loTDA) service, the message here can also be called a device message, that is, the device message can be used to describe the response result (e.g., device status) corresponding to the execution of the device command, which is business data, or it can be used to describe events or alarm messages actively reported by the device. In message push services (e.g., Simple Message Notification, SMN), the message here can also be called a subscription message, that is, the subscription message can be used to describe the subscription data that the target client needs to obtain when participating in the subscription service.

[0099] 2. Service Providers

[0100] A service provider (SP), also known as a tenant or customer, is a client that sends business data (for example, text messages or device commands) and is also the receiver of messages.

[0101] 3. Gateway (e.g., supplier SMS gateway)

[0102] The supplier's SMS gateway is used to connect to the operator's network to send SMS messages in the SMS service and return status reports to the SMS service.

[0103] 4. SMS service

[0104] Short Message Service (SMS): A messaging system that receives SMS messages, sends them to end devices via a gateway, and reports status back to the service provider's system. The SMS service is also known as the sender of status reports or the pusher.

[0105] 5. Device access service

[0106] Device access services (e.g., IoTDA services) are used to issue device commands to devices to control their operation or receive event or alarm messages reported by them. Because the device access platform corresponding to a device access service can correspond to one or more devices, a single device command often returns a large number of device messages (depending on the number of devices).

[0107] 6. Message push service

[0108] The message push service is a subscription push system that often allows users to subscribe once and receive multiple push notifications. For example, the server corresponding to the message push service needs to push subscription data to target clients participating in the subscription service based on the performance of the target clients.

[0109] 7. Push parameters

[0110] Push parameters include push rate and batch size. The push rate refers to the number of push requests sent by the server to the client per second. For example, if the push rate is 200QPS, it means that the server controls the number of push requests sent to the client per second to be 200. The batch size refers to the number of messages contained in a push request.

[0111] In order to clearly describe the following embodiments, a brief introduction to the relevant technologies is first given.

[0112] In current technical solutions, traditional message push methods require calculating the average response time of the receiving end to sent messages. This average response time is then compared with a preset value to determine how to adjust the push rate. However, in real-world scenarios, excessively high push rates can lead to abnormalities such as receiver failures. Therefore, adjusting the push rate based solely on response time is far from accurate.

[0113] To address the above-mentioned issues, an embodiment of the present application provides a new message push method. This method can be applied to a server, where the server can be used to receive messages sent by a sender. The server is provided with a buffer queue for caching messages. In this method, the server can first obtain configuration information of a target client. This configuration information can include a first configuration result for a maximum receiving rate and a second configuration result for the number of push batches. Furthermore, in the process of pushing messages to the target client, the server can determine first push parameters for the target client based on the first and second configuration results. The first push parameters can include a first push rate and a first batch number for the first batch of messages. At this point, the server can send the first batch of messages to the target client based on the first push parameters. The server can then obtain feedback information and determine second push parameters based on the feedback information and the configuration information. The feedback information can be used to indicate whether the target client has received the first batch of messages. The second push parameters can include a second push rate and a second batch number for the second batch of messages. The second batch of messages refers to the messages sent to the target client in the next batch.

[0114] In an embodiment of the present application, since the server can obtain the configuration information of the target client, the server can accurately know the information associated with the receiving capability of the target client configured based on the performance of the receiving end (for example, including at least one of the maximum receiving rate, status code, batch push address, batch number, status code, error code, or additional storage resources). In this way, when the server pushes messages to the target client, it can adaptively adjust the push parameters of the target client in the previous batch based on the configuration feedback mechanism. For example, the server can accurately know the situation of the target client receiving the first batch of messages through the feedback information returned by the target client for the messages pushed in the previous batch (i.e., the first batch of messages). Then, by combining the configuration information and feedback information of the target client, the server can more accurately adaptively adjust the push parameters corresponding to the first batch of messages (i.e., the first push parameters) to obtain the second push parameters, thereby making the second batch of messages subsequently pushed based on the second push parameters more in line with the current receiving capability of the target client, so as to effectively control the rationality of message push.

[0115] Among them, the message push method provided in the embodiment of the present application relates to the field of Internet of Things, wherein the Internet of Things (IOT) refers to the real-time collection of any object or process that needs to be monitored, connected, or interacted with through various devices and technologies such as various information sensors, radio frequency identification technology, global positioning systems, infrared sensors, laser scanners, etc., and the collection of various required information such as sound, light, heat, electricity, mechanics, chemistry, biology, and location. Through various possible network accesses, ubiquitous connections between things and things, and between things and people are achieved, and intelligent perception, identification, and management of objects and processes are realized. The Internet of Things is an information carrier based on the Internet, traditional telecommunications networks, etc., which allows all ordinary physical objects that can be independently addressed to form an interconnected network.

[0116] Cloud IOT aims to connect the information sensed and instructions received by sensor devices in traditional IoT to the Internet, truly realize networking, and achieve massive data storage and computing through cloud computing technology. Since the characteristic of IoT is that things are connected to each other and the current operating status of each "object" is perceived in real time, a large amount of data information will be generated in this process. How to aggregate this information and how to filter useful information from the massive information to support decision-making for subsequent development have become key issues affecting the development of IoT. IoT Cloud based on cloud computing and cloud storage technology has therefore become a strong support for IoT technology and applications.

[0117] It can be seen that the server in the embodiment of the present application may be an independent physical server, or it may be a server cluster or distributed system composed of multiple physical servers, or it may be a cloud server deployed in the cloud. Of course, the server here can also be a server used in the field of Internet of Things (also known as IOT server), wherein the IOT server can be used to receive messages generated by business objects to push the received messages. The business objects here may include sensors, smart phones, tablets, laptops, desktop computers, smart speakers, smart watches, robots, smart home appliances (for example, smart TVs, air conditioners, lights, etc.), vehicle-mounted terminals, smart locks, wearable devices, etc., which will not be specifically limited here.

[0118] Among them, the scenario involved in the message push method provided in the embodiment of the present application may be a short message service or a device access service. In actual application, the solution provided in the embodiment of the present application can also be applied to other scenarios. For example, the message push method provided in the embodiment of the present application can also be applied to message push solutions of other subscription push systems, such as message push services. Of course, the message push method may also be applied to enterprises or other short message platforms, may also be applied to cloud service platforms, and may also be sold as a feature, which is not limited by the embodiment of the present application.

[0119] The following describes the network architecture of the message push method provided by the embodiment of the present application:

[0120] Please refer to Figure 1, which is a structural diagram of a network architecture provided by an embodiment of the present application. As shown in Figure 1, the network architecture can be applied to a message push system corresponding to the SMS service. The message push system may include a server 100 and a client 110 for providing SMS services, and may also include a supplier SMS gateway 130 and a device cluster. Among them, the device cluster here may include one or more devices, and there is no limit on the number of devices here. Each device in the device cluster is used to receive business data (for example, SMS) sent by the client 110.

[0121] For details, please refer to Table 1, which is a schematic table provided in an embodiment of the present application for describing each module in the network architecture. As shown in Table 1:

[0122] Table 1

[0123] As shown in Figure 1, the server 100 in the embodiment of the present application can be an independent physical server, a server cluster or distributed system composed of multiple physical servers, or a cloud server providing cloud computing services. In particular, the embodiment of the present application does not limit the number of servers.

[0124] The device where the client 110 is located and each device in the device cluster may include: smart phones, tablet computers, laptop computers, desktop computers, smart speakers, smart watches, car terminals, smart TVs and other smart terminals with data processing capabilities. It is understandable that the client 110 may include a social client, a multimedia client (e.g., a video client), an entertainment client (e.g., a game client), an information stream client, an education client, a live broadcast client, etc. The application client may be an independent client or an embedded sub-client integrated into a client (e.g., a social client, an education client, a multimedia client, etc.), which is not limited here.

[0125] The client 110 can establish a network connection with the server 100 to facilitate data exchange with the server 100 through the network connection. The network connection here is not limited to a connection method, and can be directly or indirectly connected through a wired communication method, or directly or indirectly connected through a wireless communication method, or through other methods, which are not limited in this application.

[0126] It should be understood that the operational configuration shown in FIG1 means that the client 110 can perform feedback adjustment by configuring configuration parameters associated with its own receiving capabilities. Exemplarily, the SMS service can provide a service interface for configuration, so that the customer corresponding to the client 110 can configure the configuration parameters such as the maximum receiving rate, batch quantity, batch callback address, additional storage resources or status code in the service interface based on the client's own performance. Among them, for different SMS protocols, their status codes can be configured differently or the same, which is not limited here. For example, in the HyperText Transfer Protocol (HTTP) protocol, its status code can be configured as status code 1; in the Short Message Peer-to-Peer (SMPP) protocol, its status code can be configured as status code 2.

[0127] The batch callback address refers to the address used to receive status reports; the additional storage resources refer to the storage space purchased by client 110 on server 100 (for example, additional Kafka, OBS, etc.). The additional storage resources are used to store status reports associated with client 100 to be sent when client 110's receiving capacity is insufficient, that is, to temporarily store status reports that client 110 cannot receive. The status code is used to indicate the flow control strategy for client 110. For example, if the push rate in the push parameters of the previous batch is 500QPS, then if the client has configured a maximum receiving rate (for example, 200QPS), the flow control strategy can instruct server 100 to adjust the push rate in the current push parameters to the maximum receiving rate of client 110, that is, from 500QPS to 200QPS; if the client has not configured a maximum receiving rate, the flow control strategy can instruct server 100 to reduce the push rate in the current push parameters, for example, from 500QPS to 300QPS, until the push requirements are met. The push requirement here means that the client 110 no longer feeds back a status code or an error code to the server 100.

[0128] In an actual business scenario, the client 110 can call the interface of the SMS service and send a data sending request to the server 100, so that the server 100 can send a text message to the business object (for example, a user terminal) based on the object identifier. The data sending request here can include a text message and the object identifier of the business object to be sent. Specifically, the server 100 can submit the text message to the supplier SMS gateway 120, which is connected to the operator network to send the text message to the business object separately. Of course, if the devices in the device cluster interact with the server directly, the server 100 does not need to forward the text message through other devices, but can directly send the text message to the business object separately.

[0129] It is understandable that in the specific implementation of this application, relevant data such as object identification of business objects, when the above embodiments of this application are applied to specific products or technologies, need to obtain user permission or consent, and the collection, use and processing of relevant data must comply with relevant laws, regulations and standards of relevant countries and regions.

[0130] Each device in the device cluster can generate a status report indicating whether the SMS is successfully sent based on the received SMS, and send the status report to the supplier SMS gateway 120 through the operator network. When the server 100 receives the status report returned by the supplier SMS gateway 120, it can first temporarily store the received status report and then push it, thereby effectively avoiding uncontrolled rate. Among them, the buffer queue shown in Figure 1 can be the real-time remaining queue obtained after pushing the initial queue (i.e., the unordered queue composed of the status reports temporarily stored by the server 100), or it can be the real-time remaining queue obtained after pushing the message queue (i.e., the ordered queue obtained after dividing and sorting the status reports temporarily stored by the server 100 according to the push priority). It will not be limited here. Among them, the division and sorting here can include the processing of division according to the division factors, and the processing of sorting according to the push priority of the division factors.

[0131] The server 100 in the embodiment of the present application can also be used to periodically divide received status reports based on multiple factors, such as customer information (VIP information) obtained by the billing center, SMS service type (e.g., verification code type, notification type, promotion type, etc.), and push rate, to obtain queues with different push priorities. This can effectively ensure the stable operation of high-value services for high-value customers when subsequently pushing messages according to push priority.

[0132] In addition, the server 100 can also be used to collect statistics on the message push status of the client 110 within a certain period to obtain parameters such as the maximum response delay, average response delay, maximum push rate, minimum push rate and average push rate, and display them to the customers corresponding to the target client for reference.

[0133] It is understandable that, since the server 100 is able to obtain the configuration information of the client 110 in advance, when pushing a message to the client 110, the server 100 can determine the first push parameter of the client 110 based on the first configuration result (i.e., the configuration result for the maximum receiving rate) and the second configuration result (i.e., the configuration result for the number of push batches) in the configuration information. Among them, the first push parameter here may include the first push rate and the first batch number of the first batch of status reports (i.e., the first batch of messages), and the buffer queue includes the first batch of status reports. Further, the server 100 can send the first batch of status reports to the client 110 according to the first push parameter.

[0134] The server 100 can receive feedback information sent by the client 110 to learn about the client 110's reception of the first batch of status reports. The server 100 can then determine the second push parameters based on the feedback information and the configuration information, thereby making the second batch of status reports (i.e., the second batch of messages) subsequently pushed based on the second push parameters more consistent with the current receiving capability of the client 110. It can be seen that the message push method provided in the embodiment of the present application can more accurately adjust the dynamic push parameters of the client 110 through the status code feedback mechanism pre-configured in the server 100 for the client 110, thereby effectively controlling the rationality of message push.

[0135] Among them, the specific implementation method of the server pushing messages to the target client based on the status code feedback mechanism configured by the target client can refer to the embodiment methods corresponding to Figures 2 to 9 below.

[0136] Further, please refer to Figure 2, which is an interactive diagram of a method for message push provided by an embodiment of the present application. As shown in Figure 4, the method can be jointly executed by a server and a target client. In the SMS service, the target client here can be the client 110 shown in Figure 1 above, and the server can be the server 100 shown in Figure 1 above. The method can at least include S101-S107:

[0137] S101: The server obtains configuration information of the target client.

[0138] Among them, the number of clients that have a network connection relationship with the server can be one or more clients, which means that the server can obtain the configuration information corresponding to each client. Since each client is most aware of its own performance as a receiving end, each client can effectively control the status code feedback mechanism by configuring H configuration parameters such as the maximum receiving rate in the SMS service; H is a positive integer. For the sake of convenience, the target client can be taken as an example here. In an embodiment of the present application, the configuration information of the target client refers to the information configured by the target client for its own performance in the business service provided by the server (for example, SMS service, device access service or message push service, etc.). The configuration information may include H configuration parameters related to the receiving capability of the target client. These H configuration parameters may include at least one of the maximum receiving rate, the number of push batches, the batch callback address, the status code, the error code or the additional storage resources.

[0139] It should be understood that the server can provide the target client with a business page for configuration (e.g., a console page), and the client corresponding to the target client can configure one or more configuration parameters on this page. It is understood that the business page can instruct the target client to configure in the form of a table, in the form of a video, or in the form of a pop-up window. Of course, other forms (e.g., text or image prompts) can also be included, which will not be limited here.

[0140] For ease of understanding, the embodiment of the present application can be taken as an example in the form of a table to illustrate the specific implementation method for the target client to be configured in the business page. Specifically, please refer to Table 2, which is a schematic table for configuring the target client provided by the embodiment of the present application. The schematic table may include configuration parameters, configuration areas, and configuration instructions, so that the customers corresponding to the target client can quickly and clearly know the various meanings represented by each configuration parameter, thereby improving the configuration rate. Of course, Table 2 is only a form of expression for reference. In actual business scenarios, other items (for example, reference values) may also be included, which will not be limited here. As shown in Table 2:

[0141] Table 2

[0142] Status Code 1, Status Code 2, and Status Code 3 can be the same or different. Since Table 2 contains multiple error codes, and different error codes indicate different push parameters, this means that when the server receives an error code, it can adjust both the push rate and batch size simultaneously, or adjust either the push rate or batch size individually, effectively increasing configuration flexibility.

[0143] After the client corresponding to the target client completes the configuration of the target client according to Table 2, it can perform a trigger operation to submit the configuration information contained in Table 2 to the server. The trigger operation here can include contact operations such as clicking and long pressing, and can also include non-contact operations such as voice and gestures, which are not limited here. After receiving the configuration information of the target client, the server can store it.

[0144] It can be understood that if the target client configures a unified batch callback address, it means that subsequent target clients can directly receive messages pushed by the server in batches according to the batch quantity value, without distinguishing the business type corresponding to the message (for example, SMS type); if the target client configures the batch callback address separately, it means that subsequent target clients can directly receive messages distributed by the server according to the business type, which will effectively avoid the backlog of high-value messages (for example, verification code messages) on the server, and can also effectively avoid the target client's own flow limiting or backlog of high-value messages.

[0145] Based on the above Table 2, it can be seen that the configuration information obtained by the server may include a first configuration result for the maximum receiving rate and a second configuration result for the number of push batches.

[0146] S102: The server determines a first push parameter of the target client based on the first configuration result and the second configuration result.

[0147] Specifically, since a buffer queue is provided in the server, the server needs to determine the client (i.e., the target client) that currently needs to push a message based on the buffer queue. Then, the server can determine a first push rate for the target client based on the first configuration result, determine a first batch size for the target client based on the second configuration result, and determine the push parameters including the first push rate and the first batch size as the first push parameters corresponding to the target client.

[0148] Among them, the buffer queue can be a real-time remaining queue obtained after pushing the initial queue (that is, an unordered queue composed of messages temporarily stored by the server 100), or it can be an ordered queue obtained after pushing the message queue (that is, an ordered queue obtained after dividing and sorting the messages temporarily stored by the server 100 according to the push priority), which will not be limited here.

[0149] It is understood that when the buffer queue is not partitioned and sorted, the method for determining the target client is related to the number of clients currently associated with the buffer queue. For example, if all messages in the buffer queue belong to the same client, the server may determine this client as the target client; if the messages in the buffer queue belong to different clients, the server may determine any client as the target client.

[0150] Optionally, when there are a large number of clients, the messages in the buffer queue may be related to the importance of the client, the type of service, or the client's push rate. Therefore, to effectively ensure the stable operation of high-value services for high-value clients, the server can regularly sort and sort the currently temporarily stored messages to obtain a message queue.

[0151] For ease of understanding, further, please refer to Figure 3, which is a schematic diagram of a scenario in which messages are pushed according to push priority, provided in an embodiment of the present application. Among them, the client system corresponding to Figure 3 may include multiple clients that interact with the server 100 for data. Each client can be used to send text messages to the server 100 through the data plane. The server 100 here is used to provide SMS services and is the receiving end of messages (for example, SMS receipts); wherein the SMS receipts here can be used to describe whether the SMS is actually sent to a device (for example, a user terminal such as a mobile phone). It can be understood that the feedback module shown in Figure 3 can be used to receive feedback information returned by each client, and the feedback information here is used to reflect the receiving capability of its client.

[0152] As shown in FIG3 , queue L may be a buffer queue stored in the server 100. The buffer queue may include N queues of different push priorities, specifically including status report queue 1, status report queue 2, status report queue 3, ..., and status report queue N. Here, N is a positive integer.

[0153] When the server 100 pushes the status reports in each queue included in the buffer queue, the server 100 can determine the queue with the highest push priority in the buffer queue as the target queue, and determine the target client based on the client corresponding to the target queue, that is, the target client at this time refers to the client corresponding to the queue with the highest push priority in the buffer queue.

[0154] For example, if the number of clients corresponding to the target queue (for example, status report queue 1) is 1, the server 100 can directly determine the client corresponding to the target queue as the target client; of course, if the number of clients corresponding to the target queue is multiple, the target client here can be any one of these multiple clients. For example, if the target queue includes both status reports for sending to client 1 and status reports for sending to client 2, the target client determined by the server 100 can be any one of the two clients, that is, it can be client 1 or client 2.

[0155] It is understandable that the target queue has the highest push priority, which means that when the server 100 pulls from the buffer queue, it needs to give priority to pulling the target queue, and when sending the sorting queue out, it also needs to give priority to sending the contents of the target queue.

[0156] Furthermore, the server may determine first push parameters corresponding to the target client based on the first configuration result and the second configuration result in the configuration information. The first push parameters may be push parameters that are not pushed to the target client for the first time in the current divided period, i.e., push parameters that have been adjusted based on the target client's previous feedback information, or they may be initial push parameters that are pushed to the target client for the first time in the current divided period. How to reasonably determine the initial push parameters that are pushed to the target client for the first time is also very important for message push.

[0157] It is understood that the server can more reasonably determine the initial push parameters of the target client by obtaining the configuration information of the target client in advance. For example, the server can determine the first push rate of the target client based on the first configuration result, determine the first batch size of the target client based on the second configuration result, and then determine the push parameters including the first push rate and the first batch size (i.e., the initial push parameters) as the first push parameters.

[0158] For the first push rate, if the first configuration result indicates that the target client has configured a maximum receiving rate, the server may determine the maximum receiving rate as the first push rate of the target client.

[0159] If the first configuration result indicates that the target client is not configured with a maximum receiving rate, the server can determine the first push rate of the target client based on the client type of the target client. Specifically, when the client type of the target client is the first type, the server can determine the default push rate (for example, 1QPS) as the first push rate of the target client; wherein, the first type here is used to indicate that the target client is a client that sends business data for the first time, and the default push rate here can be dynamically adjusted according to the actual business situation, and will not be limited here. When the client type of the target client is the second type, the server can determine the first push rate of the target client based on the historical push rate of the target client. wherein, the second type here is used to indicate that the target client is a client that has sent business data.

[0160] For example, the server can determine the average push rate within a recent historical period (one day or one week) as the first push rate of the target client, or directly determine the most recent historical push rate as the first push rate of the target client, or determine the highest push rate or the lowest push rate within a recent historical period as the first push rate of the target client. Examples of these will not be given one by one here.

[0161] Among them, for the first batch quantity, if the second configuration result indicates that the target client has configured the batch quantity, the server can determine the configured batch quantity as the first batch quantity of the target client; if the second configuration result indicates that the target client has not configured the batch quantity, the server can determine the default batch quantity (for example, 100) as the first batch quantity of the target client.

[0162] It can be seen from this that the server can flexibly determine the first push parameters for clients with configured maximum receiving rate, clients without configured maximum receiving rate, clients with configured batch number, and clients without configured batch number, thereby improving the rationality of the first push.

[0163] Then, the server may determine the first batch of status reports (i.e., the first batch of messages) that match the first push parameters from the determined target queue. For example, if the first batch is 100 and the number of status reports in the target queue is 300, the server may randomly select 100 status reports from the 300 status reports as the first status reports.

[0164] For another example, if the first batch quantity is 100 and the number of status reports in the target queue is 30, the server can directly use these 30 status reports as the first status reports. Optionally, if the sorting result of the buffer queue indicates that the client corresponding to the next queue after the target queue is also the target client, then when the number of status reports of the target queue does not meet the first batch quantity, the server can determine the status report that matches the difference between the first batch quantity and the number of status reports of the target queue from the next queue of the target queue, and then all the status reports in the target queue (for example, 30 status reports) and the status reports determined from the next queue of the target queue (for example, 70 status reports) can be used as the first batch of status reports.

[0165] S103: The server sends the first batch of messages to the target client according to the first push parameter.

[0166] The configuration information may include a configuration result for a batch callback address (i.e., a third configuration result). Specifically, if the third configuration result indicates that the target client has configured a unified batch callback address, the server may send the first batch of messages to the target client based on the unified batch callback address and the first push parameter. If the third configuration result indicates that the target client has configured batch callback addresses corresponding to M business types, the server may search for a batch callback address that matches the business type corresponding to the first batch of messages from the M batch callback addresses, and send the first batch of messages to the target client based on the found batch callback address; M is a positive integer.

[0167] For example, if the business type corresponding to the first batch of messages is the verification code class, and the third configuration result indicates that the batch callback address of the target client is the batch callback address corresponding to the three business types, which may specifically include the message address corresponding to the verification code class (for example, address 1), the message address corresponding to the promotion class (for example, address 2), and the message address corresponding to the notification class (for example, address 3), then the server can find the batch callback address (that is, address 1) that matches the verification code class from these three addresses, and then send the first batch of messages to the target client based on address 1.

[0168] S104: The target client determines feedback information.

[0169] The feedback information here is used to indicate the status of the target client receiving the first batch of messages, such as dynamic rate feedback. For example, if the number of the first batch of messages is less than or equal to the current number that the target client can receive, the feedback information determined by the target client may include client feedback parameters. The client feedback parameters here may be push parameters determined by the target client itself that meet the current receiving capacity, or performance parameters and network parameters fed back by the target client. Client feedback parameters are not limited here. If the number of the first batch of messages is greater than the current number that the target client can receive, the feedback information determined by the target client may be information consisting of a feedback code, or information consisting of a feedback code and client feedback parameters. The feedback code here may be a status code, or a status code and an error code.

[0170] The performance parameters here may include the target client's current storage space, remaining resource computing power, etc.; network parameters may include the target client's current network environment, the push latency of the first batch of messages, etc. The push latency here may refer to the time difference between the timestamp when the first batch of messages are pushed to the target client and the timestamp when the target client returns the response.

[0171] S105: The target client sends feedback information to the server.

[0172] Among them, the target client sends feedback information to the server, which means that the target client can perform dynamic rate feedback so that the server can adjust the push parameters of the target client in time.

[0173] S106: The server determines a second push parameter based on the feedback information and the configuration information.

[0174] The configuration information includes a status code and an error code. The status code indicates the first adjustment policy, and the error code indicates the second adjustment policy. Specifically, if the feedback information includes a feedback code, and the feedback code is a status code, the server may determine the second push parameter based on the first adjustment policy. If the feedback information includes a feedback code, and the feedback code is a status code and an error code, the server may determine the second push parameter based on the second adjustment policy. If the feedback information does not include a feedback code but includes client feedback parameters, the server may determine the second push parameter based on the client feedback parameters.

[0175] Since the first push parameter here may be a push parameter for which neither the push rate nor the batch size has been adjusted, or may be a push parameter for which the push rate has been adjusted but the batch size has not been adjusted, it is necessary to explain each of these different situations separately. It is understood that if the feedback information includes a feedback code, and the feedback code is a status code, the server may first determine the rate adjustment result of the first push rate, and then, based on the rate adjustment result, the first adjustment policy, and the first push parameter, determine the second push rate and the second batch size, respectively, and determine the push parameters including the second push rate and the second batch size as the second push parameters.

[0176] If the rate adjustment result indicates that the first push rate is the initial push rate (i.e., the push rate that has not been adjusted), the server can determine the second push rate based on the first configuration result and the first adjustment strategy, and directly determine the first batch quantity as the second batch quantity. For example, when the first configuration result indicates that the target client has configured the maximum receiving rate, the server can directly determine the maximum receiving rate as the second push rate based on the first adjustment strategy; when the first configuration result indicates that the target client has not configured the maximum receiving rate, the server can determine the second push rate based on the first adjustment strategy and the client feedback parameters. Among them, the client feedback parameters here may be carried in the feedback information, or they may be requested by the server to the client at this time. The method of determining the client feedback parameters will not be limited here.

[0177] For example, the server can directly reduce the first push rate based on the target client's own performance parameters and network parameters, and determine the reduced first push rate as the second push rate. The second push rate is more consistent with the target client's current receiving capacity. The push delay here can refer to the time difference between the timestamp when the first batch of messages is pushed to the target client and the timestamp when the target client returns a response.

[0178] Of course, since the server also has the function of collecting statistics for the target client within a certain period, the server can store the target client's highest push rate (e.g., 300QPS), average push rate (e.g., 100QPS), lowest push rate (e.g., 1QPS), etc. within the period. Based on this, when the server performs a speed reduction process on the first push parameter, it can directly compare the first push rate with the average push rate counted by the server. If the first push rate (e.g., 150QPS) is greater than the average push rate, the speed reduction process here can refer to adjusting the first push rate to the average push rate.

[0179] If the rate adjustment result indicates that the first push rate is the adjusted push rate, the server may directly determine the first push rate as the second push rate and determine the second batch size based on the client feedback parameters and the first adjustment strategy. For example, the server may reduce the first batch size based on the client feedback parameters to obtain the second batch size.

[0180] Optionally, if the feedback information includes a feedback code, and the feedback code is a status code or an error code, the server may determine the target push parameter indicated by the second adjustment policy, and further determine the second push parameter based on the target push parameter. For example, if the target push parameter is a target push rate or a target batch size, the second push parameter may be determined based on the target push parameter and the first push parameter; if the target push parameter includes a target push rate and a target batch size, the target push parameter may be determined as the second push parameter.

[0181] For example, if the error code in the feedback information is error code 1 in Table 2 above, the server can directly determine the target push rate corresponding to error code 1 as the second push rate, and directly determine the target batch quantity corresponding to error code 1 as the second batch quantity; if the error code in the feedback information is error code 2 in Table 2 above, the server does not need to adjust the batch quantity, and directly determines the target push rate corresponding to error code 2 as the second push rate, and directly determines the first batch quantity as the second batch quantity; if the error code in the feedback information is error code 3 in Table 2 above, the server does not need to adjust the push rate, and directly determines the target batch quantity corresponding to error code 3 as the second batch quantity, and directly determines the first push rate as the second push rate.

[0182] S107: The server sends a second batch of messages according to the second push parameter.

[0183] The determination of the second batch of messages is related to the buffer queue currently stored in real time by the server.

[0184] It is understandable that in the embodiment of the present application, the queue obtained after the server divides and sorts the temporarily stored messages within this division and sorting cycle may be referred to as the message queue. If the buffer queue in the embodiment of the present application refers to the real-time remaining queue obtained after pushing the queues corresponding to each client in the message queue according to the push priority, then for the convenience of distinction, the embodiment of the present application may refer to the buffer queue for determining the first batch of messages as the first buffer queue, and the queue obtained after pushing each queue in the first buffer queue and in which the highest push priority is still the target client for the first time is referred to as the second buffer queue.

[0185] For example, the messages in the message queue may be related to three clients (specifically SP1, SP2, and SP3). The sorting results of the queues in the message queue may be queue L1 corresponding to SP1, queue L2 corresponding to SP2, queue L3 corresponding to SP2, queue L4 corresponding to SP1, queue L5 corresponding to SP3, and queue L6 corresponding to SP1. Then, when the target client is SP1 and the first buffer queue is the message queue itself, the second buffer queue here refers to the real-time remaining queue obtained after the server has pushed queue L1, queue L2, and queue L3, that is, the queues of the second buffer queue are sorted as queue L4, queue L5, and queue L6.

[0186] It should be understood that the message queue's partition timestamp is the same as the first and second buffer queue's partition timestamps. Therefore, when determining the second batch of messages, the server needs to determine whether the time difference between the current timestamp and the previous partition timestamp (e.g., the partition timestamp of the second buffer queue) reaches the partition duration threshold, thereby determining whether it is necessary to re-partition and reorder the messages currently temporarily stored on the server.

[0187] For example, if the time difference between the current timestamp and the previous division timestamp (i.e., the division timestamp of the above-mentioned buffer queue) does not reach the division time threshold, and the buffer queue at this time is the second buffer queue, the server can directly determine the second batch of messages that meet the second push parameters in the queue with the highest push priority in the second buffer queue (for example, queue L4).

[0188] For another example, if the difference between the current timestamp and the last division timestamp reaches the division time threshold, and the buffer queue at this time is the second buffer queue, then the server needs to re-divide and sort all the messages in the second buffer queue and the new messages received by the server between the last division timestamp and the current division timestamp to obtain a new message queue. Among them, the embodiment of the present application can refer to the queue obtained after pushing each queue in the new message queue, and the queue in which the highest push priority appears for the first time and is still the target client, as the third buffer queue. Then, when the real-time buffer queue is the third buffer queue, the server can directly determine the second batch of messages that meet the second push parameters in the queue with the highest push priority in the third buffer queue.

[0189] Furthermore, the server may send a second batch of messages to the target client according to the second push parameter. The sending method for the second batch of messages may refer to the description of the sending method for the first batch of messages in step S103 above, and will not be repeated here.

[0190] It can be seen from this that the target client (for example, the subscriber) in the embodiment of the present application can configure the status code feedback mechanism, configure the batch push address and batch number, and configure the receiving rate so that the server can more accurately know the performance of the target client as the receiving end. When the server (for example, the pusher) pushes a message, it can dynamically adjust the push parameters based on the configuration information and the feedback information returned last time, thereby effectively controlling the rationality of the message push. In addition, the server in the embodiment of the present application can distinguish the temporarily stored messages based on the priority of the subscriber to obtain a buffer queue with different push priorities, which can effectively avoid low-priority subscribers affecting high-priority subscribers. And for scenarios where the subscriber's performance is very poor or does not have R&D capabilities, the pusher can also choose the additional storage resources purchased by the subscriber for temporary storage, thereby effectively avoiding the situation where the message cannot be successfully pushed due to insufficient receiving capacity of the subscriber.

[0191] For ease of understanding, further reference is made to FIG4 , which is a schematic diagram illustrating a control method for message push in a short message service according to an embodiment of the present application. The message push system corresponding to FIG4 may include a server 100 and a client 110 . The provider service shown in FIG4 may be provided by the provider short message gateway 120 shown in FIG1 . The provider service may be used to send short messages to business objects and may also be used to receive short message receipts generated by business objects.

[0192] In the message push system corresponding to the SMS service, there is generally a distinction between the data plane (i.e., the user plane) and the management plane (i.e., the control plane) as shown in Figure 4. The data plane here can be used to interact with the client 110 for data, and specifically can include receiving SMS messages sent by the client 110, sending SMS receipts that are consistent with its dynamic push parameters to the client 100, and receiving feedback information returned by the client 110. The management plane here can be used to transmit control signaling. For example, the client 110 can configure the batch callback address or batch quantity of the client 110 through the SMS console portal, and can also configure the maximum receiving rate of the client 110, and can also configure the status code feedback mechanism, which will not be limited here. Among them, the configuration of the status code feedback mechanism here can refer to the configuration of the status code or error code shown in Table 2 above by the client 110.

[0193] It is understood that when the server 100 pushes a text message receipt to the client 110, it can dynamically feedback and adjust the push parameters of the client 110 based on the feedback information and configuration information of the client 110. Based on the concept of acceleration, when the acceleration of the push rate decreases to 0, or when the feedback information of the client 110 contains at least one of an error code or a status code, the push rate will no longer be increased, and the push parameters of the client 110 will be adjusted according to the feedback information and configuration information of the client 110. For example, when the feedback code in the feedback information of the client 110 is a status code, the server 100 can first adjust the push rate of the client 110 according to the adjustment strategy corresponding to the status code; if the adjusted push rate still does not meet the push requirements (for example, the feedback code in the feedback information is still a status code), the server 100 can adjust the batch number of the client 110; if the adjusted batch number still does not meet the push requirements, in order to avoid a backlog in the SMS service, a prompt message can be sent to the client 110 to promptly notify the client 110 to take action (for example, to upgrade the client or purchase additional storage resources).

[0194] The specific implementation of the server 100 pushing messages to the client 110 can refer to the description of steps S101 to S107 in the embodiment corresponding to FIG. 2 , which will not be further described here.

[0195] The additional storage resources shown in FIG4 are allocated to client 110 by server 100 upon receiving a storage purchase request from client 110. The storage purchase request may include the storage specification (e.g., 500 GB) required by client 110. The additional storage resources can be used to store pending messages associated with client 110 when client 110's receiving capacity is insufficient.

[0196] It should be understood that if the server 100 has adjusted the push rate and batch quantity of the client 110, and the feedback information returned by the client 110 still indicates that the receiving capacity of the client 110 is insufficient, at this time, the server 100 can temporarily store the SMS receipt associated with the client 110 to be sent in the additional storage resources.

[0197] In addition, client 110 also has the function of actively pulling SMS receipts from additional storage resources. For example, when client 110 has excess computing power, that is, its receiving capacity is sufficient to obtain new SMS receipts, client 110 can actively send a message pull request to server 100, where the message pull request here can carry the number of SMS receipts that client 110 can receive (for example, 50). When server 100 receives the message pull request, it can send 50 SMS receipts determined from the additional storage resources to client 110.

[0198] It can be seen that this method of improving the receiving capacity of the client 110 by purchasing additional storage resources in the server 100 is not only technically easy and easy to implement without the need for a high-level R&D team, but can also greatly reduce the customer cost of the client 110 in the SMS service.

[0199] Further, please refer to Figure 5, which is a schematic diagram of a control method for message push in a device access service provided by an embodiment of the present application. The message push system corresponding to Figure 5 may include a server 200 and a client 210. Here, the server 200 may be an IOT server, which is not only used to provide device access services, but also to receive messages sent by devices (for example, device messages); the client 210 may be a target client to which the message is to be pushed, as determined by the server 200.

[0200] It can be understood that since the client 210 can issue device commands (for example, commands for setting water pressure) to multiple devices separately through the device access platform corresponding to the device access service, and can also receive events or alarm messages actively reported by the devices, the device messages here can be used to describe the response results corresponding to the business data after executing the device command, and can also be used to describe events or alarm messages actively reported by the device, which will not be limited here.

[0201] Since a device command often returns a large number of device messages, if the device messages received by the server 200 are pushed to the client 210 instantaneously, this will cause a message impact on the client 210. Based on this, the embodiment of the present application can also push messages to the client 210 through the status code feedback mechanism, batch quantity, fixed rate configuration (for example, maximum receiving rate) and push priority, thereby greatly reducing the probability of impact failure of the client 210 and also receiving device messages in a timely manner.

[0202] As shown in Figure 5, in the message push system corresponding to the device access service, the server 200 may include a data plane (i.e., a user plane) and a management plane (i.e., a control plane). The data plane here can be used to interact with the client 210 for data, and specifically may include receiving device commands sent by the client 210, sending device messages that are consistent with its dynamic push parameters to the client 200, and receiving feedback information returned by the client 210. The management plane here can be used to transmit control signaling. For example, the client 210 can configure the batch callback address or batch quantity of the client 210 through the console portal, and can also configure the maximum receiving rate of the client 210, and can also configure the status code feedback mechanism, which will not be limited here. The configuration of the status code feedback mechanism here may refer to the configuration of the status code or error code through the client 210.

[0203] It is understandable that when the server 200 pushes the device message to the client 210 , it can dynamically feedback and adjust the push parameters of the client 210 according to the feedback information of the client 210 and the configuration information of the client 210 .

[0204] The specific implementation of the server 200 pushing messages to the client 210 can refer to the description of steps S101 to S107 in the embodiment corresponding to FIG. 2 , which will not be further described here.

[0205] The additional storage resources shown in Figure 5 are allocated to client 210 by server 200 upon receiving a storage purchase request from client 210. The storage purchase request may include the storage specification (e.g., 500GB) required by client 210. This additional storage resource can be used to store pending device messages associated with client 210 when client 210's receiving capacity is insufficient. Furthermore, client 210 can also proactively query the additional storage resources for device messages.

[0206] It can be seen that this method of improving the receiving capacity of the client 210 by purchasing additional storage resources in the server 200 is not only technically easy and easy to implement without the need for a high-level R&D team, but can also greatly reduce the customer cost of the client 210 in the device access service.

[0207] The following describes the method provided in the embodiment of the present application from the perspective of a single network device in conjunction with the accompanying drawings.

[0208] Please refer to Figure 6, which is a schematic diagram of a method for message push provided by an embodiment of the present application. As shown in Figure 6, the method can be executed by a server, which is used to receive messages sent by a sender, and a buffer queue is set in the server, which is used to cache messages. The server can be the server 100 for providing SMS service shown in Figure 4 above, or the server 200 for providing device access service shown in Figure 5 above, which will not be limited here. The method can at least include S201-S205:

[0209] S201: Obtain configuration information of the target client.

[0210] Among them, the number of clients that have a network connection relationship with the server can be one or more clients, which means that the server can obtain the configuration information corresponding to each client. Since each client is most aware of its own performance as a receiving end, each client can configure H configuration parameters such as the maximum receiving rate in the SMS service to facilitate subsequent effective control of push parameters; H is a positive integer. For ease of explanation, the target client can be taken as an example here. Among them, the configuration information obtained by the server may include a first configuration result for the maximum receiving rate and a second configuration result for the number of push batches.

[0211] S202: Determine a first push parameter of the target client based on the first configuration result and the second configuration result.

[0212] The first push parameter here may include a first push rate and a first batch quantity of the first batch of messages, and the buffer queue includes the first batch of messages.

[0213] The server in the embodiment of the present application can also receive a data sending request from the target client. The data sending request here may include business data associated with the target client (for example, text messages, device commands or subscription data, etc.) and the object identifier of the business object to be sent. Then, based on the object identifier, the server can send the business data associated with the target client to the business object, receive messages describing the business data, and store the received messages. In the embodiment of the present application, the device used to send messages can be referred to as a sending end. The sending end here may be a business object, or it may be a gateway for forwarding messages generated by a business object, which will not be limited here.

[0214] Furthermore, the server may determine a buffer queue based on the received message. It should be understood that the message push process will be affected by a variety of factors, including the business type corresponding to the message (for example, the type corresponding to the text message), the customer level corresponding to the client, and the push rate corresponding to the client. Of course, other factors may also be included here, such as the content influence of the client, where the content influence here may refer to the score obtained by the evaluation object (for example, an experienced expert, etc.) after evaluating the data quality of the business data (for example, text messages, etc.) sent by the client.

[0215] In terms of business types, for example, in SMS services, verification code SMS messages have higher timeliness requirements and generally cannot exceed a certain duration (for example, 1 minute). The sending time is dispersed and relatively uniform, while the timeliness of notification SMS messages is slightly weaker, and promotion SMS messages are even weaker; but the sending time of notification SMS messages and promotion SMS messages are relatively concentrated, and the QPS is higher than that of verification code SMS messages, which are prone to congestion. Of course, it is not ruled out that some emergency notification SMS messages require delay guarantees, so the push priority of different business types should be different, that is, verification code type > notification type > promotion type. Similarly, in device access services, devices report alarms and events at the same time, and there is burst traffic, which can easily cause traffic peaks to the client; or when the number of devices is huge, after the client sends commands to a batch of devices, the responses of these devices will also cause traffic peaks. Based on this, according to the timeliness evaluation, the push priority of different business types should also be different, that is, alarm type > event type > command response type.

[0216] Whether in SMS services, device access services, or push messaging services, customers are differentiated by level. For example, these levels can include super important customers (e.g., SVIP), important customers (e.g., VIP), regular customers, unknown customers (i.e., clients sending service data for the first time), and test customers. Different levels have different requirements. Generally speaking, super VIP customers may have higher latency and quality requirements. Therefore, to prevent queue consumption failures for regular customers from affecting VIP customers, queues are differentiated by level.

[0217] Regarding the push rate, in order to effectively avoid the situation where slow clients easily cause accumulation and affect fast clients, it is also necessary to differentiate queues according to the push rate.

[0218] In order to effectively ensure the stable operation of high-value services for high-value customers, the specific implementation method of how the server regularly divides and sorts the currently temporarily stored messages will be described in detail below. Among them, the server in the embodiment of the present application can record the division timestamp corresponding to each division period. When the time difference between the current timestamp and the previous division timestamp reaches the division time threshold, the message stored by the server can be determined as the initial queue, and then the initial queue can be divided and sorted based on the division factors to obtain a message queue. Among them, the message queue here is used to determine the buffer queue. For example, if the client corresponding to the highest push priority in the message queue is the target client, then the buffer queue at this time is the message queue itself. If the client with the highest push priority in the message queue is a client other than the target client, then the buffer queue at this time is the real-time remaining queue obtained after pushing the message queue.

[0219] The partitioning factors may include multiple partitioning factors with different partitioning priorities. Here, three partitioning factors may be used as an example, specifically including a first partitioning factor (e.g., related to A business type), a second partitioning factor (e.g., related to B customer levels), or a third partitioning factor (e.g., related to C push rates). A, B, and C are all positive integers. The partitioning priority of the second partitioning factor is lower than that of the first partitioning factor; and the partitioning priority of the third partitioning factor is lower than that of the second partitioning factor.

[0220] This means that when the division factor is only any one of the first division factor, the second division factor or the third division factor mentioned above, the server can divide and process the initial queue according to this division factor to obtain a message queue; when the division factor is any two of the first division factor, the second division factor or the third division factor mentioned above (for example, a division factor composed of the first division factor and the second division factor, or a division factor composed of the second division factor and the third division factor, or a division factor composed of the first division factor and the third division factor), the server needs to divide and sort the initial queue according to the division priorities corresponding to these two division factors to obtain a message queue; when the division factor is composed of the first division factor, the second division factor and the third division factor, the server needs to first divide and sort the initial queue according to the first division factor to obtain a first sorted queue, then divide and sort the first sorted queue according to the second division factor to obtain a second sorted queue, and then divide and sort the second sorted queue according to the third division factor to obtain a message queue.

[0221] For example, if the current partitioning factors include the first partitioning factor, the server may partition the initial queue based on the business type corresponding to each message in the initial queue to obtain A first queues. The server may then sort the A first queues according to the push priorities corresponding to the A business types to obtain a first sorted queue. Furthermore, the server may determine a message queue based on the first sorted queue.

[0222] Among them, when the business service provided by the server is SMS service, the A business types related to the first division factor can be taken as 3 as an example, which can specifically include verification code type, notification type and promotion type, among which the push priority corresponding to the verification code type is higher than the push priority corresponding to the notification type, and the push priority corresponding to the notification type is higher than the push priority corresponding to the promotion type; when the business service provided by the server is device access service, these A business types can also be taken as 3 as an example, which can specifically include alarm type, event type and command response type, among which the push priority corresponding to the alarm type is higher than the push priority corresponding to the event type, and the push priority corresponding to the event type is higher than the push priority corresponding to the command response type.

[0223] It is understandable that if the current division factor is only the first division factor, the server may directly determine the first sorting queue as the message queue.

[0224] If the current division factor includes not only the first division factor but also the second division factor, the server needs to sort and divide the first sorting queue again based on the second division factor. Among them, whether in the SMS service, the device access service, or the message push service, the B customer levels related to the second division factor can be 4 for example, which can specifically include super VIP, VIP, ordinary customers and unknown customers. For example, the server can divide and process the A first queues in the first sorting queue based on the customer level corresponding to each message in the first sorting queue, and obtain (A*B) second queues, and then sort the (A*B) second queues according to the push priorities corresponding to the B customer levels to obtain the second sorting queue. Furthermore, the server can also determine the message queue based on the second sorting queue.

[0225] It is understandable that if the current division factors only include the first division factor and the second division factor, the server may directly determine the second sorting queue as the message queue.

[0226] If the current division factor includes not only the first division factor and the second division factor, but also the third division factor, the server needs to sort and divide the second sorting queue again based on the third division factor. Among them, the C push rates related to the third division factor can be taken as 4 as an example, specifically including rate 1 (for example, a rate of 2000QPS), rate 2 (for example, a rate of 1000QPS and less than 2000QPS), rate 3 (for example, a rate of 100QPS and less than 1000QPS) and rate 4 (for example, a rate of less than 100QPS). Among them, the push priority of rate 1 is greater than the push priority of rate 2; and the push priority of rate 2 is greater than the push priority of rate 3; the push priority of rate 3 is greater than the push priority of rate 4. For example, the server can divide the (A*B) second queues in the second sorting queue into (A*B*C) third queues based on the push rate determined by the current timestamp and the client corresponding to each message in the second sorting queue; and then sort the (A*B*C) third queues according to the push priorities corresponding to the C push rates to obtain the message queue.

[0227] For ease of understanding, please further refer to Figure 7, which is a schematic diagram of a scenario for dividing the initial queue provided by an embodiment of the present application. As shown in Figure 7, the supplier service can be used to send messages to the server 100 (for example, SMS receipts in SMS services), and the server 100 can divide and sort the received messages based on different division factors to push messages to the client 110 according to the push priority. Among them, the division factors here may include a first division factor related to the business type, a second division factor related to the customer level, and a third division factor related to the push rate. Among them, the business type may include verification code type, notification type, and promotion type; the customer level may include super VIP, VIP, and ordinary customers; the push rate may include rate 1 (for example, a rate of 2000 QPS), rate 2 (for example, a rate of 1000 QPS and less than 2000 QPS), rate 3 (for example, a rate of 100 QPS and less than 1000 QPS), and rate 4 (for example, a rate of less than 100 QPS).

[0228] It is understandable that when the time difference between the current timestamp and the previous division timestamp reaches the division time threshold, the server can determine the message stored by the server as the initial queue. Since the first division factor among the division factors has the highest division priority, the server 100 can divide the initial queue based on the business type corresponding to each message in the initial queue to obtain three first queues. Among them, the three first queues here can specifically include a notification queue, a verification code queue, and a promotion queue. At this time, the server 100 can sort the three first queues according to the push priorities corresponding to the above three business types to obtain a first sorted queue, wherein the sorting results of the three queues of the first sorted queue here are a verification code queue, a notification queue, and a promotion queue.

[0229] Then, the server 100 further needs to sort and divide the three first queues in the first sorting queue based on the second division factor. For example, the server 100 can divide the verification code queue based on the customer level corresponding to each message in the first sorting queue, thereby obtaining three second queues corresponding to the verification code queue. These three second queues can include a super VIP queue newly divided from the verification code queue, a VIP queue newly divided from the verification code queue, and a regular customer queue newly divided from the verification code queue. Similarly, the server can also obtain three second queues corresponding to the notification queue (i.e., a super VIP queue newly divided from the notification queue, a VIP queue newly divided from the notification queue, and a regular customer queue newly divided from the notification queue), as well as three second queues corresponding to the promotion queue (i.e., a super VIP queue newly divided from the promotion queue, a VIP queue newly divided from the promotion queue, and a regular customer queue newly divided from the promotion queue). In other words, after dividing the first sorting queue based on the second division factor, the server can obtain nine second queues. Then, the server 100 may sort the nine second queues according to the push priorities corresponding to the three client levels, so as to obtain a second sorted queue.

[0230] Furthermore, the server also needs to sort and divide the 9 second queues in the second sorting queue based on the third division factor. For example, the server 100 can divide a second queue in the second sorting queue (for example, a super VIP queue newly divided from the verification code queue) based on the push rate determined by the current timestamp of the client corresponding to each message in the second sorting queue, and obtain 4 third queues corresponding to different rates. Similarly. After the server 100 sorts and divides the 9 second queues based on the third division factor, it can obtain 36 third queues. Then, the server can sort the 36 third queues according to the push priorities corresponding to the 4 push rates, thereby obtaining a message queue.

[0231] For ease of understanding, further reference is made to Table 3, which is a schematic table provided in an embodiment of the present application for representing the push priority of each queue in a message queue. The message queue shown in Table 3 may be the message queue corresponding to FIG. 7 above, and the message queue in the table may include 36 third queues with different push priorities. As shown in Table 3:

[0232] Table 3

[0233] It can be understood that the server 100 can push messages in sequence based on the push priority of each queue in the message queue shown in Table 3 during this division period, thereby effectively avoiding the situation where the push of low-priority subscribers affects high-priority subscribers, that is, solving the problem of mutual influence of push queues, and thus ensuring the stable operation of high-value services of high-value customers.

[0234] S203: Send the first batch of messages to the target client according to the first push parameter.

[0235] Among them, since the configuration information includes the third configuration result for the batch callback address, when the server determines the first batch of messages that match the first push parameters from the buffer queue, it can send the first batch of messages to the target client based on the first batch of messages and the third configuration result.

[0236] S204: Obtain feedback information.

[0237] The feedback information here can be used to indicate whether the target client has received the first batch of messages.

[0238] S205: Determine a second push parameter based on the feedback information and the configuration information.

[0239] The second push parameters here may include a second push rate and a second batch quantity for the second batch of messages, where the second batch of messages refers to messages sent to the target client in the next batch.

[0240] The specific implementation of steps S201 to S205 can be found in the description of steps S101 to S107 in the embodiment corresponding to FIG. 2 , and will not be repeated here.

[0241] For ease of understanding, further reference is made to FIG8 , which is a schematic diagram of a framework for message push according to push priority provided by an embodiment of the present application. As shown in FIG8 , the client system here may include M clients corresponding to each client, where M is a positive integer, and may specifically include SP1, SP2, ..., and SPM. The server 100 for providing SMS service may include a push module, a pull module, a gateway docking module, and an SP management module. The buffer queue shown in FIG8 may be the real-time remaining queue obtained after pushing the message queue shown in Table 3 above.

[0242] Among them, the SP management module can be used to obtain the customer levels corresponding to these M clients (for example, super VIP, VIP, ordinary users and unknown users, etc.), and use them as a dividing factor; the gateway docking module can be used to receive status reports reported by the supplier gateway, and can also be used to divide and sort the received status reports based on the customer levels and other dividing factors (for example, business type, push rate, etc.) obtained by the SP management module; it can also be used to receive feedback information returned by each client; the pull module can pull messages according to the buffer queue and put them into the corresponding SP queue; the push module can be used to push messages to these M clients separately according to the push priority, and can also be used to send the feedback information returned by each client to the gateway docking module.

[0243] As shown in Figure 8, the messages in the SP1 queue here refer to the messages pulled from the buffer queue by the server 100 based on the pull module for sending to SP1. The SP1 queue may include the verification code queue corresponding to SP1, the notification queue corresponding to SP1, and the promotion queue corresponding to SP1. Similarly, the messages in the SP2 queue refer to the messages pulled from the buffer queue by the server 100 based on the pull module for sending to SP2. The SP2 queue may also include the verification code queue corresponding to SP2, the notification queue corresponding to SP2, and the promotion queue corresponding to SP2, and so on. They will not be explained one by one here.

[0244] It is understandable that if the first push parameter is a push parameter that has adjusted both the push rate and the number of batches, and the feedback information here still indicates that the push requirements are not met (i.e., the current receiving capability of the target client is still unable to successfully receive the first batch of messages), then the server can determine the message batches corresponding to the first batch of messages and the number of remaining messages, respectively. Among them, the remaining messages here can be messages associated with the target client other than the first batch of messages in the buffer queue. If the message batch reaches the batch threshold (for example, 10), and the number of messages of the remaining messages reaches the number threshold (for example, 500), the server can generate a prompt message for instructing the target client to upgrade, and then send a prompt message to the target client. Among them, the batch threshold and the number threshold here can both be parameters that are dynamically adjusted according to business conditions.

[0245] In other words, if the server has adjusted the push rate and batch size, but a large number of messages are still waiting to be sent on the server side, resulting in a message backlog, in order to ensure that the target client's timeliness is not affected, the server needs to send a prompt message to the target client to report the alert. The prompt message can instruct the target client to upgrade or purchase additional storage resources.

[0246] Further, please refer to Figure 9, which is a second schematic diagram of a method for message push provided by an embodiment of the present application. As shown in Figure 9, the method can be executed by a target client, and the target client is used to send configuration information associated with the receiving capability of the target client to the server, and the configuration information includes a first configuration result for the maximum receiving rate and a second configuration result for the batch number, wherein the target client can be the client 110 for sending text messages shown in Figure 4 above, or the client 210 for issuing device commands shown in Figure 5 above, which will not be limited here. The method can at least include S301-S304:

[0247] S301, receiving the first batch of messages sent by the server.

[0248] Specifically, if the target client has configured a unified batch callback address, the target client may receive the first batch of messages based on the unified batch callback address and the first push parameter. If the target client has configured batch callback addresses corresponding to M service types, the target client may receive the first batch of messages based on the batch callback address and the first push parameter that match the service type corresponding to the first batch of messages; M is a positive integer.

[0249] This means that the embodiment of the present application supports the client to configure multiple customer addresses. For example, a message callback address is configured for the verification code category, and another message callback address is configured for the promotion category and notification category respectively. This will ensure that high-priority, low-speed business is completely unaffected by low-priority, high-speed business.

[0250] S302: Determine feedback information corresponding to the first batch of messages.

[0251] The feedback information here is used to indicate the status of the target client receiving the first batch of messages, such as dynamic rate feedback. For example, if the number of the first batch of messages is less than or equal to the current number that the target client can receive, the feedback information determined by the target client may include client feedback parameters. The client feedback parameters here may be push parameters determined by the target client itself that meet the current receiving capacity, or performance parameters and network parameters fed back by the target client. Client feedback parameters are not limited here. If the number of the first batch of messages is greater than the current number that the target client can receive, the feedback information determined by the target client may be information consisting of a feedback code, or information consisting of a feedback code and client feedback parameters. The feedback code here may be a status code, or a status code and an error code.

[0252] S303: Send feedback information to the server.

[0253] Among them, the target client sends feedback information to the server, which means that the target client can perform dynamic rate feedback so that the server can adjust the push parameters of the target client in time.

[0254] S304: Receive a second batch of messages from the server.

[0255] The second push parameter corresponding to the second batch of messages is determined based on the feedback information and the configuration information.

[0256] The specific implementation of S301-S104 can refer to the description of S103-S107 in the embodiment corresponding to FIG2 above, and will not be repeated here.

[0257] Optionally, after executing step S303, the target client may also receive a prompt message sent by the server to instruct the target client to upgrade, and display the prompt message. For example, the prompt message here may include text information and business controls. The text message here may be "Your current receiving capacity cannot meet the demand, please deal with it in time." The business controls here may include a first business control (for example, an "upgrade" control) for instructing the client to upgrade and a second business control (for example, a "storage purchase" control) for instructing the purchase of additional storage resources.

[0258] For example, the target client can respond to the client upgrade operation for the prompt information and adjust the receiving capability of the target client. The client upgrade operation here can be a trigger operation executed by the client corresponding to the target client for the "upgrade" control.

[0259] For another example, the target client can generate a storage purchase request to allocate additional storage resources to the target client in response to a storage purchase operation in response to the prompt information, and then send the storage purchase request to the server. The additional storage resources can be used to store pending messages associated with the target client when the target client's receiving capacity is insufficient. The storage purchase operation here can be a triggering operation executed by the client corresponding to the target client in response to a "Storage Purchase" control.

[0260] Among them, the triggering operations involved in the embodiments of the present application may include non-contact operations such as voice and gestures, and may also include contact operations such as clicks and long presses, which will not be limited here.

[0261] When the target client has surplus computing power, that is, its receiving capacity is sufficient to obtain new messages, the target client can actively send a message pull request to the server, and then receive the message returned by the server from the additional storage resources.

[0262] Further, referring to Figure 10, Figure 10 is a schematic diagram of the structure of a message push device based on IoT technology provided in an embodiment of the present application. As shown in Figure 10, the message push device 1 may include at least one of a processing unit 1001 and a transceiver unit 1002. These units can perform the response functions of each device in the above method embodiment.

[0263] In a possible implementation, the message push device 1 can be used to implement the function of the server in FIG6 , where the server is used to receive messages sent by a sender, and a buffer queue is provided in the server, which is used to cache messages.

[0264] Specifically, processing unit 1001 is used to obtain configuration information of the target client, the configuration information includes a first configuration result for the maximum receiving rate and a second configuration result for the number of push batches; processing unit 1001 is also used to determine the first push parameters of the target client based on the first configuration result and the second configuration result, the first push parameters include the first push rate and the first batch number of the first batch of messages, and the buffer queue includes the first batch of messages; transceiver unit 1002 is used to send the first batch of messages to the target client according to the first push parameters; processing unit 1001 is also used to obtain feedback information, and the feedback information is used to indicate the situation of the target client receiving the first batch of messages; processing unit 1001 is also used to determine the second push parameters based on the feedback information and the configuration information, the second push parameters include the second push rate and the second batch number of the second batch of messages, and the second batch of messages refers to the messages sent to the target client in the next batch.

[0265] In one implementation, the configuration information includes a status code and an error code, the status code is used to indicate a first adjustment strategy, and the error code is used to indicate a second adjustment strategy; the processing unit 1001 is also used to determine a second push parameter based on the feedback information and the configuration information, including: the processing unit 1001 is specifically used to determine the second push parameter based on the first adjustment strategy if the feedback information contains a feedback code and the feedback code is a status code; the processing unit 1001 is specifically used to determine the second push parameter based on the second adjustment strategy if the feedback information contains a feedback code and the feedback code is a status code and an error code.

[0266] In one implementation, the processing unit 1001 is specifically used to determine the second push parameter based on the first adjustment strategy, including: the processing unit 1001 is specifically used to determine the rate adjustment result of the first push rate; the processing unit 1001 is specifically used to determine the second push rate and the second batch number based on the rate adjustment result, the first adjustment strategy and the first push parameter; the processing unit 1001 is specifically used to determine the push parameters including the second push rate and the second batch number as the second push parameters.

[0267] In one implementation, the processing unit 1001 is specifically used to determine the second push rate and the second batch quantity based on the rate adjustment result, the first adjustment strategy and the first push parameter, respectively, including: the processing unit 1001 is specifically used to determine the second push rate based on the first configuration result and the first adjustment strategy if the rate adjustment result indicates that the first push rate is the initial push rate, and determine the first batch quantity as the second batch quantity; the processing unit 1001 is specifically used to determine the first push rate as the second push rate if the rate adjustment result indicates that the first push rate is the adjusted push rate, and determine the second batch quantity based on the client feedback parameters and the first adjustment strategy; the client feedback parameters include performance parameters and network parameters fed back by the target client.

[0268] In one implementation, the processing unit 1001 is specifically used to determine the second push rate based on the first configuration result and the first adjustment strategy, including: the processing unit 1001 is specifically used to determine the maximum receiving rate as the second push rate based on the first adjustment strategy when the first configuration result indicates that the target client has configured the maximum receiving rate; the processing unit 1001 is specifically used to determine the second push rate based on the first adjustment strategy and the client feedback parameter when the first configuration result indicates that the target client has not configured the maximum receiving rate.

[0269] In one implementation, the processing unit 1001 is specifically used to determine the second push parameter based on the second adjustment strategy, including: the processing unit 1001 is specifically used to determine the target push parameter indicated by the second adjustment strategy; the processing unit 1001 is specifically used to determine the second push parameter based on the target push parameter and the first push parameter if the target push parameter is a target push rate or a target batch quantity; the processing unit 1001 is specifically used to determine the target push parameter as the second push parameter if the target push parameter includes a target push rate and a target batch quantity.

[0270] In one implementation, the buffer queue includes N queues with different push priorities, where N is a positive integer; the processing unit 1001 is also used to determine the first push parameters of the target client based on the first configuration result and the second configuration result, including: the processing unit 1001 is specifically used to determine the queue with the highest push priority in the buffer queue as the target queue, and determine the target client based on the client corresponding to the target queue; the processing unit 1001 is specifically used to determine the first push rate of the target client based on the first configuration result; the processing unit 1001 is specifically used to determine the first batch quantity of the target client based on the second configuration result; the processing unit 1001 is specifically used to determine the push parameters including the first push rate and the first batch quantity as the first push parameters.

[0271] In one implementation, the processing unit 1001 is specifically used to determine the first push rate of the target client based on the first configuration result, including: the processing unit 1001 is specifically used to determine the maximum receiving rate as the first push rate of the target client if the first configuration result indicates that the target client has been configured with a maximum receiving rate; the processing unit 1001 is specifically used to determine the first push rate of the target client based on the client type of the target client if the first configuration result indicates that the target client has not been configured with a maximum receiving rate.

[0272] In one implementation, the processing unit 1001 is specifically used to determine the first push rate of the target client based on the client type of the target client, including: the processing unit 1001 is specifically used to determine the default push rate as the first push rate of the target client when the client type of the target client is the first type, and the first type is used to indicate that the target client is a client that sends business data for the first time; the processing unit 1001 is specifically used to determine the first push rate of the target client based on the historical push rate of the target client when the client type of the target client is the second type, and the second type is used to indicate that the target client is a client that has sent business data.

[0273] In one implementation, the configuration information includes a third configuration result for a batch callback address; a processing unit 1001 is specifically used to send the first batch of messages to a target client based on a first push parameter, including: processing unit 1001 is specifically used to send the first batch of messages to the target client based on the unified batch callback address and the first push parameter if the third configuration result indicates that the target client has configured a unified batch callback address; processing unit 1001 is specifically used to search for a target batch callback address that matches the business type corresponding to the first batch of messages from the M batch callback addresses if the third configuration result indicates that the target client has configured batch callback addresses corresponding to M business types, and send the first batch of messages to the target client based on the target batch callback address and the first push parameter, where M is a positive integer.

[0274] In one implementation, the message push device also includes: a transceiver unit 1002, which is also used to receive a data sending request from a target client, the data sending request includes business data associated with the target client and an object identifier of the business object to be sent; the transceiver unit 1002 is also used to send business data to the business object based on the object identifier; the transceiver unit 1002 is also used to receive a message for describing the business data; the processing unit 1001 is also used to store the received message.

[0275] In one implementation, the message push device also includes: a processing unit 1001, which is also used to determine the message stored in the server as the initial queue when the time difference between the current timestamp and the previous division timestamp reaches the division time threshold; the processing unit 1001 is also used to divide and sort the initial queue based on the division factor to obtain a message queue, and the message queue is used to determine the buffer queue.

[0276] In one implementation, the division factor includes a first division factor, which is related to A business types, where A is a positive integer; the processing unit 1001 is also used to divide and sort the initial queue based on the division factor to obtain a buffer queue, including: the processing unit 1001 is specifically used to divide and process the initial queue based on the business type corresponding to each message in the initial queue to obtain A first queues; the processing unit 1001 is specifically used to sort the A first queues according to the push priorities corresponding to the A business types to obtain a first sorted queue; the processing unit 1001 is specifically used to determine the message queue based on the first sorted queue.

[0277] In one implementation, the division factor also includes a second division factor, the division priority of the second division factor is lower than the division priority of the first division factor, and the second division factor is related to B customer levels, where B is a positive integer; the processing unit 1001 is specifically used to determine the message queue based on the first sorting queue, including: the processing unit 1001 is specifically used to divide and process the A first queues in the first sorting queue based on the customer level corresponding to each message in the first sorting queue, to obtain (A*B) second queues; the processing unit 1001 is specifically used to sort the (A*B) second queues according to the push priorities corresponding to the B customer levels, to obtain a second sorting queue; the processing unit 1001 is specifically used to determine the message queue based on the second sorting queue.

[0278] In one implementation, the division factors also include a third division factor, the division priority of the third division factor is lower than the division priority of the second division factor, and the third division factor is related to C push rates, where C is a positive integer; the processing unit 1001 is specifically used to determine the message queue based on the second sorting queue, including: the processing unit 1001 is specifically used to divide and process the (A*B) second queues in the second sorting queue based on the push rate determined by the current timestamp of the client corresponding to each message in the second sorting queue, to obtain (A*B*C) third queues; the processing unit 1001 is specifically used to sort the (A*B*C) third queues according to the push priorities corresponding to the C push rates, to obtain the message queue.

[0279] In one implementation, the message push device also includes: a processing unit 1001, which is also used to determine the message batches corresponding to the first batch of messages and the number of messages of the remaining messages, respectively, and the remaining messages are messages associated with the target client in the buffer queue except the first batch of messages; the processing unit 1001 is also used to generate a prompt message for instructing the target client to upgrade if the message batch reaches the batch threshold and the number of messages reaches the number threshold; the transceiver unit 1002 is also used to send a prompt message to the target client.

[0280] In one implementation, the message push device also includes: a transceiver unit 1002, which is also used to receive a storage purchase request from a target client; a processing unit 1001, which is also used to allocate additional storage resources to the target client based on the storage purchase request, and the additional storage resources are used to store messages associated with the target client to be sent when the target client's receiving capacity is insufficient.

[0281] In one implementation, the message push device further includes: a transceiver unit 1002, further configured to receive a message pull request from a target client; and a transceiver unit 1002, further configured to send a message in an additional storage resource to the target client.

[0282] The specific implementation of the processing unit 1001 and the transceiver unit 1002 can be found in the description of steps S201 to S205 in the embodiment corresponding to FIG6 , which will not be described in detail here.

[0283] In another possible implementation, the message push device 1 can be used to implement the function of the target client in Figure 9. The target client here is used to send configuration information associated with the receiving capability of the target client to the server, where the configuration information includes a first configuration result for the maximum receiving rate and a second configuration result for the batch number.

[0284] Specifically, the transceiver unit 1002 is used to receive the first batch of messages sent by the server; the processing unit 1001 is used to determine feedback information, and the feedback information is used to indicate the situation of the target client receiving the first batch of messages; the transceiver unit 1002 is also used to send feedback information to the server; the transceiver unit 1002 is also used to receive the second batch of messages from the server, and the second push parameters corresponding to the second batch of messages are determined based on the feedback information and configuration information.

[0285] In one implementation, the configuration information includes H configuration parameters, where H is a positive integer, and the H configuration parameters include at least one of a maximum receiving rate, a number of push batches, a batch callback address, a status code, an error code, or additional storage resources.

[0286] In one implementation, the message push device also includes: a processing unit 1001, which is also used to display the prompt information sent by the server, the prompt information is used to instruct the target client to upgrade; the processing unit 1001 is also used to respond to the client upgrade operation for the prompt information and adjust the receiving capability of the target client.

[0287] In one implementation, the message push device also includes: a processing unit 1001, which is also used to display the prompt information sent by the server, and the prompt information is used to instruct the target client to upgrade; the processing unit 1001 is also used to respond to the storage purchase operation for the prompt information and generate a storage purchase request, and the storage purchase request is used to request the server to allocate additional storage resources to the target client. The additional storage resources are also used to store messages associated with the target client to be sent when the target client's receiving capacity is insufficient; the transceiver unit 1002 is also used to send a storage purchase request to the server.

[0288] In one implementation, the message push device further includes: a transceiver unit 1002, further configured to send a message pull request to the server; and a transceiver unit 1002, further configured to receive a message returned by the server from the additional storage resource.

[0289] The specific implementation of the transceiver unit 1002 and the processing unit 1001 can be found in the description of steps S301 to S304 in the embodiment corresponding to FIG9 , which will not be described in detail here.

[0290] Further, please refer to Figure 11, which is a second structural diagram of a message push device based on IoT technology provided in an embodiment of the present application. As shown in Figure 11, specifically, the message push device 2 can be used to implement the functions of the server in Figure 6, or the message push device 2 can be used to implement the functions of the target client in Figure 9.

[0291] 11 , the message push device 2 includes all or part of the hardware in a processor 1101, a communication interface 1102, and a memory 1103. The number of processors 1101 in the message push device 2 may be one or more, with one processor being used as an example in FIG11 . In the embodiment of the present application, the processor 1101, the communication interface 1102, and the memory 1103 may be connected via a bus system or other means, with FIG11 using a bus system 1104 as an example.

[0292] Processor 1101 may be a central processor unit (CPU), a network processor (NP), or a combination of a CPU and an NP. Processor 1101 may also include a hardware chip. The hardware chip may be an application-specific integrated circuit (ASIC), a programmable logic device (PLD), or a combination thereof. The PLD may be a complex programmable logic device (CPLD), a field-programmable gate array (FPGA), a generic array logic (GAL), or any combination thereof.

[0293] The communication interface 1102 is used to receive and send data. Specifically, the communication interface 1102 may include a receiving interface and a sending interface. The receiving interface may be used to receive data, and the sending interface may be used to send data. The number of the communication interface 1102 may be one or more.

[0294] Memory 1103 may include volatile memory, such as random-access memory (RAM); memory 3003 may also include non-volatile memory, such as flash memory, hard disk drive (HDD) or solid-state drive (SSD); memory 1103 may also include a combination of the above types of memory.

[0295] Optionally, the memory 1103 stores an operating system and programs, executable modules or data structures, or subsets thereof, or extended sets thereof, wherein the programs may include various operating instructions for implementing various operations. The operating system may include various system programs for implementing various basic services and processing hardware-based tasks. The processor 1101 may read the programs in the memory 1103 to implement the methods provided in the embodiments of the present application.

[0296] The memory 1103 may be a storage device in the message pushing device 2 , or may be a storage device independent of the message pushing device 2 .

[0297] Bus system 1104 may be a Peripheral Component Interconnect (PCI) bus or an Extended Industry Standard Architecture (EISA) bus. Bus system 3004 may be divided into an address bus, a data bus, a control bus, etc. For ease of illustration, FIG11 shows only one thick line, but this does not mean that there is only one bus or only one type of bus.

[0298] In some possible embodiments, the above-mentioned message push device can be implemented as a virtualized device. For example, the virtualized device can be a virtual machine (VM) running a program for sending message functions, and the virtual machine is deployed on a hardware device (for example, a physical server). A virtual machine refers to a complete computer system with complete hardware system functions simulated by software and running in a completely isolated environment. The virtual machine can be configured as a message push device. For example, the function of the message push device can be implemented based on a general physical server in combination with network function virtualization (NFV) technology. Those skilled in the art can virtualize a message push device with the above-mentioned functions on a general physical server in combination with NFV technology by reading this application, and will not go into details here.

[0299] It should be noted that the message push device mentioned in the embodiments of the present application can be a target client, a server, or a chip used to implement the method of the present application, and the embodiments of the present application do not specifically limit this. When the message push device is a chip, the interface circuit in the chip can be used to perform the receiving or sending operations in the message push device, and the processor in the chip can be used to perform the processing operations.

[0300] In a specific implementation, an embodiment of the present application further provides a chip including a processor and an interface circuit, wherein the interface circuit is configured to receive instructions and transmit them to the processor; and the processor is configured to execute the operations of each message push device in the above-mentioned message push method. The processor is coupled to a memory, which is configured to store programs or instructions. When the programs or instructions are executed by the processor, the chip implements the method in any of the above-mentioned method embodiments.

[0301] Optionally, there may be one or more processors in the chip. The processor may be implemented in hardware and / or software. When implemented in hardware, the processor may be a logic circuit, an integrated circuit, etc. When implemented in software, the processor may be a general-purpose processor implemented by reading software code stored in a memory.

[0302] Optionally, the chip may include one or more memories. The memory may be integrated with the processor or may be provided separately from the processor, which is not limited in this application. For example, the memory may be a non-transient processor, such as a read-only memory (ROM), which may be integrated with the processor on the same chip or provided on separate chips. This application does not specifically limit the type of memory or the configuration of the memory and the processor.

[0303] Exemplarily, the chip may be a field programmable gate array (FPGA), an application-specific integrated circuit (ASIC), a system on chip (SoC), a central processor unit (CPU), a network processor (NP), a digital signal processor (DSP), a microcontroller unit (MCU), a programmable logic device (PLD), or other integrated chips.

[0304] An embodiment of the present application also provides a computer-readable storage medium based on IOT technology, including instructions or computer programs, which, when executed on a processor, enables the processor to execute the message push method provided in the above embodiment.

[0305] The embodiments of the present application also provide a computer program product based on IOT technology, which includes instructions or computer programs. When the computer program product is executed on a processor, the computer program product enables the message push device to execute the method for dynamically adjusting push parameters provided in the above embodiments.

[0306] The terms "first," "second," "third," "fourth," and the like (if any) in the specification and claims of this application and in the accompanying drawings are used to distinguish similar objects and are not necessarily used to describe a particular order or sequential sequence. It should be understood that the terms used in this manner are interchangeable where appropriate so that the embodiments described herein can be implemented in an order other than that illustrated or described herein. In addition, the terms "including" and "having," and any variations thereof, are intended to cover non-exclusive inclusions, e.g., a process, method, system, product, or apparatus comprising a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.

[0307] Those skilled in the art will clearly understand that, for the convenience and brevity of description, the specific working processes of the systems, devices and units described above can refer to the corresponding processes in the aforementioned method embodiments and will not be repeated here.

[0308] In the several embodiments provided in this application, it should be understood that the disclosed systems, devices and methods can be implemented in other ways. For example, the device embodiments described above are merely illustrative. For example, the division of units is only a logical business division. In actual implementation, there may be other division methods, such as multiple units or components can be combined or integrated into another system, or some features can be ignored or not executed. Another point is that the mutual coupling or direct coupling or communication connection shown or discussed can be an indirect coupling or communication connection through some interface, device or unit, which can be electrical, mechanical or other forms.

[0309] The units described as separate components may or may not be physically separate, and the components shown as units may or may not be physical units, that is, they may be located in one place or distributed across multiple network units. Some or all of the units may be selected according to actual needs to achieve the purpose of the embodiments of the present application.

[0310] Those skilled in the art will appreciate that, in one or more of the examples above, the services described herein may be implemented using hardware, software, firmware, or any combination thereof. When implemented using software, these services may be stored in a computer-readable medium or transmitted as one or more instructions or codes on a computer-readable medium. Computer-readable media include computer storage media and communication media, wherein communication media include any medium that facilitates the transmission of computer programs from one location to another. Storage media may be any available medium that can be accessed by a general-purpose or special-purpose computer.

[0311] The above specific implementation methods further describe in detail the purpose, technical solutions and beneficial effects of this application. It should be understood that the above are only specific implementation methods of this application.

[0312] The above embodiments are only used to illustrate the technical solutions of the present application, rather than to limit them. Although the present application has been described in detail with reference to the aforementioned embodiments, those skilled in the art should understand that they can still modify the technical solutions described in the aforementioned embodiments, or make equivalent replacements for some of the technical features therein. However, these modifications or replacements do not deviate the essence of the corresponding technical solutions from the scope of the technical solutions of the embodiments of the present application.

Claims

1. A message push method based on IOT technology, characterized in that: The method is executed by a server, the server is used to receive a message sent by a sender, a buffer queue is set in the server, and the buffer queue is used to cache the message, including: Acquire configuration information of a target client, the configuration information including a first configuration result for a maximum receiving rate and a second configuration result for a number of push batches; Based on the first configuration result and the second configuration result, determining a first push parameter of the target client, wherein the first push parameter includes a first push rate and a first batch quantity of a first batch of messages, and the buffer queue includes the first batch of messages; Sending the first batch of messages to the target client according to the first push parameter; Acquire feedback information, where the feedback information is used to indicate a situation in which the target client receives the first batch of messages; Based on the feedback information and the configuration information, second push parameters are determined, where the second push parameters include a second push rate and a second batch quantity for a second batch of messages, where the second batch of messages refers to messages sent to the target client in a next batch.

2. The method according to claim 1, characterized in that The configuration information includes a status code and an error code, the status code is used to indicate a first adjustment strategy, and the error code is used to indicate a second adjustment strategy; The determining the second push parameter based on the feedback information and the configuration information includes: If the feedback information contains a feedback code, and the feedback code is a status code, determining a second push parameter based on the first adjustment strategy; If the feedback information contains a feedback code, and the feedback code is a status code and an error code, the second push parameter is determined based on the second adjustment strategy.

3. The method according to claim 2, characterized in that The determining the second push parameter based on the first adjustment strategy includes: Determining a rate adjustment result of the first push rate; Based on the rate adjustment result, the first adjustment strategy, and the first push parameter, respectively determine a second push rate and a second batch quantity; Push parameters including a second push rate and a second batch number are determined as second push parameters.

4. The method according to claim 3, characterized in that The determining, based on the rate adjustment result, the first adjustment strategy, and the first push parameter, respectively, a second push rate and a second batch quantity includes: If the rate adjustment result indicates that the first push rate is the initial push rate, determining a second push rate based on the first configuration result and the first adjustment strategy, and determining the first batch quantity as the second batch quantity; If the rate adjustment result indicates that the first push rate is an adjusted push rate, the first push rate is determined as the second push rate, and the second batch quantity is determined based on the client feedback parameters and the first adjustment strategy; the client feedback parameters include the performance parameters and network parameters fed back by the target client.

5. The method according to claim 4, characterized in that The determining the second push rate based on the first configuration result and the first adjustment strategy includes: When the first configuration result indicates that the target client has configured a maximum receiving rate, based on the first adjustment strategy, determining the maximum receiving rate as a second push rate; When the first configuration result indicates that the target client is not configured with a maximum receiving rate, a second push rate is determined based on the first adjustment strategy and client feedback parameters.

6. The method according to any one of claims 2 to 5, characterized in that: The determining the second push parameter based on the second adjustment strategy includes: Determining the target push parameter indicated by the second adjustment strategy; If the target push parameter is a target push rate or a target batch quantity, determining a second push parameter based on the target push parameter and the first push parameter; If the target push parameters include a target push rate and a target batch quantity, the target push parameters are determined as second push parameters.

7. The method according to any one of claims 1 to 6, characterized in that: The buffer queue includes N queues with different push priorities, where N is a positive integer; The determining, based on the first configuration result and the second configuration result, a first push parameter of the target client includes: Determine a queue with the highest push priority in the buffer queue as a target queue, and determine a target client based on the client corresponding to the target queue; Determining a first push rate of the target client based on the first configuration result; Based on the second configuration result, determining a first batch quantity of the target clients; Push parameters including the first push rate and the first batch quantity are determined as first push parameters.

8. The method according to claim 7, characterized in that The determining, based on the first configuration result, a first push rate of the target client includes: If the first configuration result indicates that the target client has configured a maximum receiving rate, determining the maximum receiving rate as a first push rate of the target client; If the first configuration result indicates that the target client is not configured with a maximum receiving rate, a first push rate of the target client is determined based on the client type of the target client.

9. The method according to claim 8, characterized in that The determining, based on the client type of the target client, a first push rate of the target client includes: When the client type of the target client is a first type, determining the default push rate as a first push rate of the target client, wherein the first type is used to indicate that the target client is a client that sends service data for the first time; When the client type of the target client is the second type, the first push rate of the target client is determined based on the historical push rate of the target client, and the second type is used to indicate that the target client is a client that has sent service data.

10. The method according to any one of claims 1 to 9, characterized in that: The configuration information includes a third configuration result for batch callback addresses; The sending the first batch of messages to the target client according to the first push parameter includes: If the third configuration result indicates that the target client has configured a unified batch callback address, sending the first batch of messages to the target client based on the unified batch callback address and the first push parameter; If the third configuration result indicates that the target client has configured batch callback addresses corresponding to M business types, then from the M batch callback addresses, find the target batch callback address that matches the business type corresponding to the first batch of messages, and send the first batch of messages to the target client based on the target batch callback address and the first push parameter, where M is a positive integer.

11. The method according to any one of claims 1 to 10, characterized in that: The method further comprises: receiving a data transmission request from the target client, the data transmission request including business data associated with the target client and an object identifier of a business object to be transmitted; Based on the object identifier, sending the business data to the business object; receiving a message describing the business data; The received messages are stored.

12. The method according to claim 11, characterized in that The method further comprises: When the time difference between the current timestamp and the last division timestamp reaches the division time threshold, the message stored in the server is determined as the initial queue; Based on the division factors, the initial queue is divided and sorted to obtain a message queue, and the message queue is used to determine the buffer queue.

13. The method according to claim 12, characterized in that The division factors include a first division factor, the first division factor is related to A business types, and A is a positive integer; The step of dividing and sorting the initial queue based on the division factor to obtain the buffer queue includes: Based on the service type corresponding to each message in the initial queue, the initial queue is divided to obtain A first queues; Sorting the A first queues according to the push priorities corresponding to the A service types to obtain a first sorted queue; Based on the first sorting queue, a message queue is determined.

14. The method according to claim 13, characterized in that The classification factor further includes a second classification factor, the classification priority of the second classification factor is lower than the classification priority of the first classification factor, and the second classification factor is related to B customer levels, where B is a positive integer; The determining of the message queue based on the first sorting queue includes: Based on the customer level corresponding to each message in the first sorting queue, the A first queues in the first sorting queue are divided into (A*B) second queues; Sorting the (A*B) second queues according to the push priorities corresponding to the B customer levels to obtain a second sorted queue; Based on the second sorted queue, a message queue is determined.

15. The method according to claim 14, characterized in that The division factors further include a third division factor, the division priority of the third division factor is lower than the division priority of the second division factor, and the third division factor is related to C push rates, where C is a positive integer; The determining of the message queue based on the second sorting queue includes: Based on the clients corresponding to each message in the second sorting queue, at the push rate determined by the current timestamp, the (A*B) second queues in the second sorting queue are divided and processed to obtain (A*B*C) third queues; The (A*B*C) third queues are sorted according to the push priorities corresponding to the C push rates to obtain a message queue.

16. The method according to any one of claims 1 to 15, characterized in that: The method further comprises: Determine respectively the message batches corresponding to the first batch of messages and the number of remaining messages, wherein the remaining messages are messages in the buffer queue other than the first batch of messages and associated with the target client; If the message batch reaches the batch threshold and the message quantity reaches the quantity threshold, generating prompt information for instructing the target client to upgrade; The prompt information is sent to the target client.

17. The method according to any one of claims 1 to 16, characterized in that: The method further comprises: Receiving a storage purchase request from the target client; Based on the storage purchase request, additional storage resources are allocated to the target client, and the additional storage resources are used to store messages associated with the target client to be sent when the receiving capacity of the target client is insufficient.

18. The method according to claim 17, characterized in that The method further comprises: Receiving a message pull request from the target client; The message in the additional storage resource is sent to the target client.

19. A message push method based on IOT technology, characterized in that: The method is performed by a target client, and the target client is used to send configuration information associated with the receiving capability of the target client to a server, wherein the configuration information includes a first configuration result for a maximum receiving rate and a second configuration result for a batch number, including: receiving a first batch of messages sent by the server; Determine feedback information, where the feedback information is used to indicate a situation in which the target client receives the first batch of messages; Sending the feedback information to the server; receiving a second batch of messages from the server, wherein a second push parameter corresponding to the second batch of messages is based on the feedback information and Determined by the configuration information.

20. The method according to claim 19, characterized in that The configuration information includes H configuration parameters, where H is a positive integer, and the H configuration parameters include at least one of a maximum receiving rate, a push batch quantity, a batch callback address, a status code, an error code, or additional storage resources.

21. The method according to claim 19 or 20, characterized in that The method further comprises: Displaying the prompt information sent by the server, wherein the prompt information is used to instruct the target client to upgrade; In response to the client upgrade operation for the prompt information, the receiving capability of the target client is adjusted.

22. The method according to claim 19 or 20, characterized in that The method further comprises: Displaying the prompt information sent by the server, wherein the prompt information is used to instruct the target client to upgrade; In response to the storage purchase operation for the prompt information, generating a storage purchase request, wherein the storage purchase request is used to request the server to allocate additional storage resources to the target client, and the additional storage resources are also used to store messages associated with the target client to be sent when the receiving capacity of the target client is insufficient; A storage purchase request is sent to the server.

23. The method according to claim 22, characterized in that The method further comprises: Sending a message pull request to the server; A message returned by the server from the additional storage resource is received.

24. A message push device based on IOT technology, characterized in that: The message push device is applied to a server, the server is used to receive a message sent by a sender, a buffer queue is provided in the server, and the buffer queue is used to cache the message, including: A processing unit, configured to obtain configuration information of a target client, wherein the configuration information includes a first configuration result for a maximum receiving rate and a second configuration result for a number of push batches; The processing unit is further used to determine a first push parameter of the target client based on the first configuration result and the second configuration result, wherein the first push parameter includes a first push rate and a first batch quantity of a first batch of messages, and the buffer queue includes the first batch of messages; A transceiver unit, configured to send the first batch of messages to the target client according to the first push parameter; The processing unit is further used to obtain feedback information, where the feedback information is used to indicate the situation in which the target client receives the first batch of messages; The processing unit is also used to determine second push parameters based on the feedback information and the configuration information, wherein the second push parameters include a second push rate and a second batch quantity for a second batch of messages, and the second batch of messages refers to messages sent to the target client in the next batch.

25. The message push device according to claim 24, characterized in that: The configuration information includes a status code and an error code, the status code is used to indicate a first adjustment strategy, and the error code is used to indicate a second adjustment strategy; The processing unit is further configured to determine a second push parameter based on the feedback information and the configuration information, including: The processing unit is specifically configured to determine a second push parameter based on the first adjustment strategy if the feedback information contains a feedback code and the feedback code is a status code; The processing unit is specifically configured to determine, if the feedback information contains a feedback code, and the feedback code is a status code and an error code, as a second push parameter based on the second adjustment strategy.

26. The message push device according to claim 25, characterized in that: The processing unit is specifically configured to determine a second push parameter based on the first adjustment strategy, including: The processing unit is specifically configured to determine a rate adjustment result of the first push rate; The processing unit is specifically configured to determine a second push rate and a second batch quantity based on the rate adjustment result, the first adjustment strategy, and the first push parameter; The processing unit is specifically configured to determine the push parameters including the second push rate and the second batch quantity as the second push parameters.

27. The message push device according to claim 26, characterized in that: The processing unit is specifically configured to determine a second push rate and a second batch quantity based on the rate adjustment result, the first adjustment strategy, and the first push parameter, respectively, including: The processing unit is specifically configured to determine a second push rate based on the first configuration result and the first adjustment strategy, and determine the first batch quantity as a second batch quantity if the rate adjustment result indicates that the first push rate is the initial push rate; The processing unit is specifically used to determine the first push rate as the second push rate if the rate adjustment result indicates that the first push rate is an adjusted push rate, and determine the second batch quantity based on the client feedback parameters and the first adjustment strategy; the client feedback parameters include the performance parameters and network parameters fed back by the target client.

28. The message push device according to claim 27, characterized in that: The processing unit is specifically configured to determine a second push rate based on the first configuration result and the first adjustment strategy, including: The processing unit is specifically configured to determine the maximum receiving rate as the second push rate based on the first adjustment strategy when the first configuration result indicates that the target client has configured a maximum receiving rate; The processing unit is specifically configured to determine a second push rate based on the first adjustment strategy and client feedback parameters when the first configuration result indicates that the target client is not configured with a maximum receiving rate.

29. The message push device according to any one of claims 25 to 28, characterized in that: The processing unit is specifically configured to determine a second push parameter based on the second adjustment strategy, including: The processing unit is specifically configured to determine the target push parameter indicated by the second adjustment strategy; The processing unit is specifically configured to determine a second push parameter based on the target push parameter and the first push parameter if the target push parameter is a target push rate or a target batch quantity; The processing unit is specifically configured to determine the target push parameter as the second push parameter if the target push parameter includes a target push rate and a target batch quantity.

30. The message push device according to any one of claims 24 to 29, characterized in that: The buffer queue includes N queues with different push priorities, where N is a positive integer; The processing unit is further configured to determine a first push parameter of the target client based on the first configuration result and the second configuration result, including: The processing unit is specifically configured to determine a queue with the highest push priority in the buffer queue as a target queue, and determine a target client based on a client corresponding to the target queue; The processing unit is specifically configured to determine a first push rate of the target client based on the first configuration result; The processing unit is specifically configured to determine a first batch quantity of the target clients based on the second configuration result; The processing unit is specifically configured to determine the push parameters including the first push rate and the first batch quantity as the first push parameters.

31. The message push device according to claim 30, characterized in that: The processing unit is specifically configured to determine a first push rate of the target client based on the first configuration result, including: The processing unit is specifically configured to determine the maximum receiving rate as the first push rate of the target client if the first configuration result indicates that the target client has configured a maximum receiving rate; The processing unit is specifically configured to determine a first push rate of the target client based on a client type of the target client if the first configuration result indicates that the target client is not configured with a maximum receiving rate.

32. The message push device according to claim 31, characterized in that: The processing unit is specifically configured to determine a first push rate of the target client based on the client type of the target client, including: The processing unit is specifically configured to determine the default push rate as the first push rate of the target client when the client type of the target client is a first type, wherein the first type is used to indicate that the target client is a client that sends service data for the first time; The processing unit is specifically configured to, when the client type of the target client is the second type, based on the history of the target client The historical push rate is determined as the first push rate of the target client, and the second type is used to indicate that the target client is a client that has sent business data.

33. The message push device according to any one of claims 24 to 32, characterized in that: The configuration information includes a third configuration result for batch callback addresses; The processing unit is specifically configured to send the first batch of messages to the target client according to the first push parameter, including: The processing unit is specifically configured to send the first batch of messages to the target client based on the unified batch callback address and the first push parameter if the third configuration result indicates that the target client has configured a unified batch callback address; The processing unit is specifically used to search for a target batch callback address that matches the business type corresponding to the first batch of messages from the M batch callback addresses if the third configuration result indicates that the target client has configured batch callback addresses corresponding to M business types respectively, and send the first batch of messages to the target client based on the target batch callback address and the first push parameter, where M is a positive integer.

34. The message push device according to any one of claims 24 to 33, characterized in that: The message push device also includes: The transceiver unit is further configured to receive a data transmission request from the target client, wherein the data transmission request includes the service data associated with the target client and an object identifier of the service object to be transmitted; The transceiver unit is further configured to send the service data to the service object based on the object identifier; The transceiver unit is further used to receive a message describing the service data; The processing unit is also used to store the received message.

35. The message push device according to claim 34, characterized in that: The message push device also includes: The processing unit is further configured to determine the message stored in the server as the initial queue when the time difference between the current timestamp and the last division timestamp reaches the division time threshold; The processing unit is further used to divide and sort the initial queue based on the division factors to obtain a message queue, and the message queue is used to determine the buffer queue.

36. The message push device according to claim 35, characterized in that: The division factors include a first division factor, the first division factor is related to A business types, and A is a positive integer; The processing unit is further used to perform partitioning and sorting processing on the initial queue based on the partitioning factor to obtain the buffer queue, including: The processing unit is specifically configured to divide the initial queue based on the service type corresponding to each message in the initial queue to obtain A first queues; The processing unit is specifically configured to sort the A first queues according to the push priorities respectively corresponding to the A service types to obtain a first sorted queue; The processing unit is specifically configured to determine a message queue based on the first sorting queue.

37. The message push device according to claim 36, characterized in that: The classification factor further includes a second classification factor, the classification priority of the second classification factor is lower than the classification priority of the first classification factor, and the second classification factor is related to B customer levels, where B is a positive integer; The processing unit is specifically configured to determine a message queue based on the first sorting queue, including: The processing unit is specifically configured to divide the A first queues in the first sorting queue into (A*B) second queues based on the customer level corresponding to each message in the first sorting queue; The processing unit is specifically configured to sort the (A*B) second queues according to the push priorities corresponding to the B customer levels, to obtain a second sorted queue; The processing unit is specifically configured to determine a message queue based on the second sorting queue.

38. The message push device according to claim 37, characterized in that: The division factors further include a third division factor, the division priority of the third division factor is lower than the division priority of the second division factor, and the third division factor is related to C push rates, where C is a positive integer; The processing unit is specifically configured to determine a message queue based on the second sorting queue, including: The processing unit is specifically configured to divide (A*B) second queues in the second sorting queue into (A*B*C) third queues based on the client corresponding to each message in the second sorting queue and at the push rate determined by the current timestamp; The processing unit is specifically used to sort the (A*B*C) third queues according to the push priorities corresponding to the C push rates respectively, to obtain a message queue.

39. The message push device according to any one of claims 24 to 38, characterized in that: The message push device also includes: The processing unit is further used to respectively determine the message batches corresponding to the first batch of messages and the number of remaining messages, wherein the remaining messages are messages in the buffer queue other than the first batch of messages and associated with the target client; The processing unit is further configured to generate prompt information for instructing the target client to upgrade if the message batch reaches a batch threshold and the number of messages reaches a number threshold; The transceiver unit is further used to send the prompt information to the target client.

40. The message push device according to any one of claims 24 to 39, characterized in that: The message push device also includes: The transceiver unit is further used to receive a storage purchase request from the target client; The processing unit is further used to allocate additional storage resources to the target client based on the storage purchase request, and the additional storage resources are used to store messages associated with the target client to be sent when the receiving capacity of the target client is insufficient.

41. The message push device according to claim 40, characterized in that: The message push device also includes: The transceiver unit is further used to receive a message pull request from the target client; The transceiver unit is further used to send the message in the additional storage resource to the target client.

42. A message push device based on IOT technology, characterized in that: The message push device is applied to a target client, and the target client is used to send configuration information associated with the receiving capability of the target client to a server, wherein the configuration information includes a first configuration result for a maximum receiving rate and a second configuration result for a batch number, including: A transceiver unit, used for receiving the first batch of messages sent by the server; A processing unit, used to determine feedback information, where the feedback information is used to indicate a situation in which the target client receives the first batch of messages; The transceiver unit is further used to send the feedback information to the server; The transceiver unit is further configured to receive a second batch of messages from the server, wherein a second push parameter corresponding to the second batch of messages is determined based on the feedback information and the configuration information.

43. The message push device according to claim 42, characterized in that: The configuration information includes H configuration parameters, where H is a positive integer, and the H configuration parameters include at least one of a maximum receiving rate, a push batch quantity, a batch callback address, a status code, an error code, or additional storage resources.

44. The message push device according to claim 42 or 43, characterized in that: The message push device also includes: The processing unit is further used to display the prompt information sent by the server, where the prompt information is used to instruct the target client to upgrade; The processing unit is further configured to respond to a client upgrade operation for the prompt information and adjust the receiving capability of the target client.

45. The message push device according to claim 42 or 43, characterized in that: The message push device also includes: The processing unit is further used to display the prompt information sent by the server, where the prompt information is used to instruct the target client to upgrade; The processing unit is further configured to generate a storage purchase request in response to a storage purchase operation for the prompt information, wherein the storage purchase request is used to request the server to allocate additional storage resources to the target client, and the additional storage resources are also used to allocate additional storage resources to the target client. When the receiving capacity of the client is insufficient, storing the message associated with the target client to be sent; The transceiver unit is also used to send a storage purchase request to the server.

46. ​​The message push device according to claim 45, characterized in that: The message push device also includes: The transceiver unit is further used to send a message pull request to the server; The transceiver unit is further configured to receive a message returned by the server from the additional storage resource.

47. A message push system based on IOT technology, characterized in that: include: A server and a target client, wherein the server is used to receive a message sent by a sender, and a buffer queue is provided in the server, and the buffer queue is used to cache the message; The server obtains configuration information of the target client, where the configuration information includes a first configuration result for a maximum receiving rate and a second configuration result for a push batch number; The server determines, based on the first configuration result and the second configuration result, a first push parameter of the target client, wherein the first push parameter includes a first push rate and a first batch quantity of the first batch of messages; the buffer queue includes the first batch of messages; The server sends the first batch of messages to the target client according to the first push parameter; The target client determines feedback information; the feedback information is used to indicate the situation that the target client receives the first batch of messages; The target client sends the feedback information to the server; The server determines a second push parameter based on the feedback information and the configuration information; the second push parameter includes a second push rate and a second batch quantity for a second batch of messages; the second batch of messages refers to messages sent to the target client in a next batch.

48. A message push device based on IOT technology, characterized in that: It comprises a memory and a processor, wherein the memory is used to store computer instructions, and the processor is used to call and execute the computer instructions from the memory to implement the method as described in any one of claims 1-18, or to implement the method as described in any one of claims 19-23.

49. A computer-readable storage medium based on IOT technology, characterized in that: The computer-readable storage medium stores instructions, and when the instructions are executed on a processor, the method according to any one of claims 1 to 18 is implemented, or the method according to any one of claims 19 to 23 is implemented.

50. A computer program product based on IOT technology, characterized in that: The computer program product comprises instructions, which, when executed on a processor, are used to implement the method according to any one of claims 1 to 18, or to implement the method according to any one of claims 19 to 23.

Images