CN113810266B

CN113810266B - Retry operation method, device, equipment and storage medium for message object

Info

Publication number: CN113810266B
Application number: CN202110931936.6A
Authority: CN
Inventors: 时彬强
Original assignee: Beijing Dajia Internet Information Technology Co Ltd
Current assignee: Beijing Dajia Internet Information Technology Co Ltd
Priority date: 2021-08-13
Filing date: 2021-08-13
Publication date: 2023-05-12
Anticipated expiration: 2041-08-13
Also published as: CN113810266A

Abstract

The disclosure relates to a retry operation method, a retry operation device and a retry operation storage medium for a message object, wherein the retry operation method comprises the following steps: responding to the received communication signaling, and determining a designated message object and operation information corresponding to the communication signaling; wherein the operation information indicates an operation for the specified message object; creating a corresponding retry object based on the specified message object and the operation information; when the operation for the specified message object fails and the failure cause is not in accordance with a preset network condition, performing retry operation based on the retry object when the preset network condition is in accordance. The present disclosure defaults to operations for specified message objects, which may have failed, creates a retry object before the operation, enables efficient storage of the retry object, and performs a retry operation based on the retry object when retry conditions are met. The probability of successful retry is improved, and the situation that the user needs inconvenient manual retry is reduced.

Description

Retry operation method, device, equipment and storage medium for message object

Technical Field

The present disclosure relates to computer technology, and in particular, to a retry operation method, apparatus, device, and storage medium for a message object.

Background

With the development of internet technology, instant messaging (InstantMessaging, IM) products are layered endlessly, and instant messaging products provide users with a service experience of sending and receiving internet messages and the like in real time. In the related art, when the operation of the user on the related message object fails because the current network environment is weak or even no network, the retry operation on the related message object is started when the network environment is recovered to have a network or even to have a strong network, so that the related message object is cached (for example, a cache in the form of a key value pair is maintained in a memory), and thus, the retry is automatically performed based on the cache after the network environment is recovered. However, before the network environment is restored, the instant messaging product may have a restart condition, and the buffered data is lost and is not retried. Thereby returning an operation failure notification to the user, guiding the user to retry manually. The above-mentioned related art scheme has the problems of low success probability of automatic retry and poor experience of requiring manual retry by a user.

Disclosure of Invention

The disclosure provides a retry operation method, device, equipment and storage medium for a message object, so as to at least solve the problems of low success probability of automatic retry and poor experience of manual retry required by a user in the related technology. The technical scheme of the present disclosure is as follows:

According to a first aspect of embodiments of the present disclosure, there is provided a retry operation method for a message object, the method including:

responding to the received communication signaling, and determining a designated message object and operation information corresponding to the communication signaling; wherein the operation information indicates an operation for the specified message object;

creating a corresponding retry object based on the specified message object and the operation information;

when the operation for the specified message object fails and the failure cause is not in accordance with a preset network condition, performing retry operation based on the retry object when the preset network condition is in accordance.

In an exemplary embodiment, the creating a corresponding retry object based on the specified message object and the operation information includes:

obtaining an operation type based on the operation information, and determining a first field for recording the operation type;

determining a key message object from the specified message object, and determining a second field for recording the key message object;

determining a third field for recording creation time and a fourth field for recording the number of retries;

The retry object is created based on the first field, the second field, and the third field, the fourth field.

In an exemplary embodiment, before the retry operation based on the retry subject, the method further includes:

determining a current time and a creation time recorded in the retry object;

calculating a difference between the current time and the creation time;

and when the difference value is larger than a first preset value, marking the retry subject to fail, and not triggering the step of performing retry operation based on the retry subject.

In an exemplary embodiment, the performing a retry operation based on the retry subject includes:

if the current retry times are smaller than or equal to a second preset value, continuing to perform retry operation based on the retry object; when the retry operation fails continuously, updating the number of retries recorded in the retry object and repeating the step of continuing the retry operation based on the retry object;

and if the current retry number is greater than the second preset value, not triggering the step of continuing to retry the operation based on the retry object.

determining a matched message database based on the operational information;

inquiring whether a message object matched with the retry object exists in the matched message database;

marking the retry subject as invalid when not present, and not triggering the step of performing a retry operation based on the retry subject;

and when the retry operation exists, triggering the step of performing the retry operation based on the retry object.

In an exemplary embodiment, before the step of triggering the retry operation based on the retry subject, the method further includes:

when the communication signaling is the first type of communication signaling indicating transmission, determining the transmission state of the matched message object;

when the sending state is in sending, determining whether the matched message object has resources to be uploaded or not;

when present, marking the retry as invalid, and not triggering the step of performing a retry operation based on the retry.

In an exemplary embodiment, after said determining the sending status of the matched message object, the method further comprises:

And when the transmission state is successful, marking that the retry object is invalid, and not triggering the retry operation based on the retry object.

when the communication signaling is the first type communication signaling which indicates transmission, a request for inquiring whether a message object matched with the retry object exists or not is transmitted to a server side;

and when the received query result indicates that the retry object is invalid, and the step of performing retry operation based on the retry object is not triggered.

determining the session identifier of the specified message object;

the retry object is created based on the specified message object, the belonging session identification, and the operation information.

when the communication signaling is the first type communication signaling which indicates to be sent, determining a retry object which points to the same session with the retry object;

Constructing a retry object group based on the retry object and a retry object pointing to the same session as the retry object;

and performing retry operation based on the retry subject group.

In an exemplary embodiment, when the communication signaling is a first type of communication signaling indicating transmission, after the creating of the corresponding retry object based on the specified message object and the operation information, the method further includes:

when preprocessing information aiming at the appointed message object is received, processing the appointed message object based on the preprocessing information to obtain a target message object;

and sending the target message object.

In an exemplary embodiment, before the creating of the corresponding retry object based on the specified message object and the operation information, the method further includes:

and when the communication signaling is the second type communication signaling, generating feedback information indicating that the operation is successful, and displaying the feedback information on a user interaction interface, wherein the second type communication signaling comprises communication signaling indicating that the deletion and the indication mark are read.

In an exemplary embodiment, after the retry operation based on the retry subject, the method further includes:

Determining a matched message database based on the operation information when the retry operation is successful;

determining a message object matching the retry object in the matching message database, and updating the message status of the matching message object.

According to a second aspect of embodiments of the present disclosure, there is provided a retry operation apparatus for a message object, the apparatus including:

a response unit configured to perform determination of a specified message object and operation information corresponding to a received communication signaling in response to the communication signaling; wherein the operation information indicates an operation for the specified message object;

a creation unit configured to execute creation of a corresponding retry object based on the specification message object and the operation information;

and a retry unit configured to perform a retry operation based on the retry object when a predetermined network condition is satisfied when the operation for the specified message object fails and the failure cause is not satisfied.

In an exemplary embodiment, the creation unit includes:

a first field determination unit configured to perform obtaining an operation type based on the operation information, and determine a first field for recording the operation type;

A second field determining unit configured to perform determination of a key message object from the specified message object, and determination of a second field for recording the key message object;

a third field determining unit configured to perform determination of a third field for recording creation time and a fourth field for recording the number of retries;

a first creation subunit configured to perform creation of the retry object based on the first field, the second field, and the third field, the fourth field.

In an exemplary embodiment, the apparatus further comprises:

a time determination unit configured to perform determination of a current time and a creation time recorded in the retry object;

a difference value calculation unit configured to perform calculation of a difference value between the current time and the creation time;

a first cancel retry unit configured to perform the steps of marking the retry subject as invalid when the difference is greater than a first preset value, and not triggering the retry operation based on the retry subject.

In an exemplary embodiment, the retry unit includes:

a retry continuing unit configured to execute a retry operation based on the retry subject if the number of times of the current retry is equal to or smaller than a second preset value; when the retry operation fails continuously, updating the number of retries recorded in the retry object and repeating the step of continuing the retry operation based on the retry object;

And the cancel continuing retry unit is configured to execute the step of not triggering the continuing of the retry operation based on the retry subject if the current number of retries is greater than the second preset value.

In an exemplary embodiment, the apparatus further comprises:

a first database determining unit configured to perform determining a matched message database based on the operation information;

a first querying unit configured to perform querying in the matched message database whether there is a message object matched with the retry object;

a second cancel retry unit configured to perform the steps of marking the retry subject as invalid when not present, and not triggering the retry operation based on the retry subject;

and a triggering unit configured to perform the step of triggering the retry operation based on the retry subject when present.

In an exemplary embodiment, the apparatus further comprises:

a transmission state determining unit configured to perform determination of a transmission state of the matched message object when the communication signaling is a first type of communication signaling indicating transmission;

the to-be-uploaded resource determining unit is configured to determine whether the matched data object has to-be-uploaded resources or not when the transmission state is in transmission;

A third cancel retry unit configured to perform the steps of marking the retry subject as invalid when present, and not triggering the retry operation based on the retry subject.

In an exemplary embodiment, the apparatus further comprises:

and a fourth cancel retry unit configured to perform the steps of marking the retry subject as invalid when the transmission status is transmission success, and not triggering the retry operation based on the retry subject.

In an exemplary embodiment, the apparatus further comprises:

a second query unit configured to perform, when the communication signaling is a first type communication signaling indicating transmission, a request for querying whether a message object matching the retry object exists to a server;

and a fifth cancel retry unit configured to perform the steps of marking the retry subject as invalid when the received query result indicates presence, and not triggering the retry operation based on the retry subject.

In an exemplary embodiment, the creation unit includes:

a session identification determination unit configured to perform determination of a session identification to which the specified message object belongs;

A second creation subunit configured to perform creation of the retry object based on the specified message object, the belonging session identification, and the operation information.

In an exemplary embodiment, the retry unit includes:

a retry object determination unit configured to perform determination of a retry object directed to the same session as the retry object when the communication signaling is a first type of communication signaling indicating transmission;

a retry object group construction unit configured to perform construction of a retry object group based on the retry object and a retry object that points to the same session as the retry object;

a retry sub-unit configured to perform a retry operation based on the retry subject group.

In an exemplary embodiment, when the communication signaling is a first type of communication signaling indicating transmission, the apparatus further includes:

a data processing unit configured to perform processing of the specified message object based on the preprocessing information to obtain a target message object when the preprocessing information for the specified message object is received;

and the sending unit is configured to perform sending operation on the target message object.

In an exemplary embodiment, the apparatus further comprises:

and the feedback information display unit is configured to generate feedback information indicating successful operation when the communication signaling is a second type of communication signaling, and display the feedback information on a user interaction interface, wherein the second type of communication signaling comprises communication signaling indicating deletion and reading of an indication mark.

In an exemplary embodiment, the apparatus further comprises:

a first database determining unit configured to perform determining a matched message database based on the operation information when a retry operation is successful;

an updating unit configured to perform determining a message object matching the retry object in the matching message database, and updating a message status of the matching message object.

According to a third aspect of embodiments of the present disclosure, there is provided an electronic device, comprising: a processor; a memory for storing the processor-executable instructions; wherein the processor is configured to execute the instructions to implement the retry operation method for a message object as described in the first aspect.

According to a fourth aspect of embodiments of the present disclosure, there is provided a computer readable storage medium, which when executed by a processor of an electronic device, causes the electronic device to perform the retry operation method for a message object as described in the first aspect.

According to a fifth aspect of embodiments of the present disclosure, there is provided a computer program product comprising a computer program/instruction, characterized in that the computer program/instruction, when executed by a processor, implements the retry operation method for a message object according to the first aspect.

The technical scheme provided by the embodiment of the disclosure at least brings the following beneficial effects:

by determining the designated message object and the operation information corresponding to the communication signaling, and then creating a corresponding retry object based on the designated message object and the operation information, when the operation for the designated message object fails and the failure cause is not in accordance with the preset network condition, the retry operation is performed based on the retry object when the preset network condition is in accordance. The technical scheme defaults that the operation aiming at the appointed message object can fail, creates the retry object before the operation, realizes the effective storage of the retry object, and accordingly, performs the retry operation based on the retry object when the retry condition is met. The probability of successful retry is improved, and the situation that the user needs inconvenient manual retry is reduced.

It is to be understood that both the foregoing general description and the following detailed description are exemplary and explanatory only and are not restrictive of the disclosure.

Drawings

The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate embodiments consistent with the disclosure and together with the description, serve to explain the principles of the disclosure and do not constitute an undue limitation on the disclosure.

Fig. 1 is an architecture diagram of a system for applying a retry operation method for a message object, according to an exemplary embodiment.

Fig. 2 is a flow chart illustrating a method of retry operations for a message object according to an exemplary embodiment.

FIG. 3 is a flowchart illustrating the creation of a retry object according to an exemplary embodiment.

FIG. 4 is a flowchart illustrating a determination of whether to perform a retry operation based on a retry subject in accordance with an exemplary embodiment.

Fig. 5 is a flowchart illustrating a retry operation based on a retry subject in accordance with an exemplary embodiment.

Fig. 6 is a timing diagram illustrating operation when communication signaling is a first type of communication signaling indicating transmission, according to an example embodiment.

Fig. 7 is a timing diagram illustrating operation when the communication signaling is of the second type of communication signaling, according to an example embodiment.

FIG. 8 is a failed retry flow chart illustrated in accordance with an exemplary embodiment.

Fig. 9 is a block diagram illustrating a retry operation apparatus for a message object according to an exemplary embodiment.

Fig. 10 is a block diagram of an electronic device, according to an example embodiment.

Detailed Description

In order to enable those skilled in the art to better understand the technical solutions of the present disclosure, the technical solutions of the embodiments of the present disclosure will be clearly and completely described below with reference to the accompanying drawings.

It should be noted that the terms "first," "second," and the like in the description and claims of the present disclosure and in the foregoing figures are used for distinguishing between similar objects and not necessarily for describing a particular sequential or chronological order. It is to be understood that the data so used may be interchanged where appropriate such that the embodiments of the disclosure described herein may be capable of operation in sequences other than those illustrated or described herein. The implementations described in the following exemplary examples are not representative of all implementations consistent with the present disclosure. Rather, they are merely examples of apparatus and methods consistent with some aspects of the present disclosure as detailed in the accompanying claims.

Before the embodiments of the present specification are described in further detail, terms and terminology referred to in the embodiments of the present specification are explained, and are applicable to the following explanation.

Instant messaging (Instant Messaging, IM): a real-time communication system allows two or more people to communicate text messages, documents, voice and video in real time using a network.

Software development kit (Software Development Kit, SDK): typically, a collection of development tools are created by some software engineers for a particular software package, software framework, hardware platform, operating system, etc. when the application software is built. The IMSDK (instant messaging SDK) is a combination of the SDK and the abbreviation "IM" described above.

Application (App), mainly refers to Application software installed on a smart phone.

A DataBase (DB) may be used to persist some data.

Fig. 1 is an architecture diagram of a system for applying a retry operation method for a message object, which may include a client 10 and a server 20, see fig. 1, according to an exemplary embodiment.

The client 10 may be, but is not limited to, one or more of a smart phone, a tablet computer, a notebook computer, a desktop computer, a smart speaker, a smart wearable device, a digital assistant, an augmented reality device, a virtual reality device, or an application running in a physical device. A user can implement a service experience of instant transmission and reception of internet messages, etc. through the client 10. The client 10 receives the communication signaling sent by the user, then determines the corresponding specified message object and operation information, and creates the corresponding retry object based on the specified message object and the operation information, so that when the operation for the specified message object fails and the failure cause is not in accordance with the preset network condition, the retry operation is performed based on the retry object when the preset network condition is in accordance.

Server 20 may provide background services to clients 10. By way of example only, the server 20 may be, but is not limited to being, a stand-alone server, a server cluster or a distributed system formed by a plurality of physical servers, or one or more of cloud servers providing cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communications, middleware services, domain name services, security services, and basic cloud computing services such as big data and artificial intelligence platforms. The client 10 and the server 20 may be directly or indirectly connected through wired or wireless communication, and embodiments of the present disclosure are not limited herein.

Fig. 2 is a flowchart of a retry operation method for a message object according to an exemplary embodiment, and as shown in fig. 2, the retry operation method for a message object may be applied to an electronic device, and the electronic device is taken as an example of a client in the above-mentioned implementation environment schematic diagram, and the method includes the following steps.

In step S201, in response to the received communication signaling, determining a specified message object and operation information corresponding to the communication signaling; wherein the operation information indicates an operation for the specified message object.

In the embodiment of the present specification, the client receives the communication signaling, and the client determines, based on the communication signaling, the corresponding specified message object and the operation information indicating the operation for the specified message object, such as "send operation", "delete operation", "mark read operation", and the like. The communication signaling may be an operation of a target object (such as a user or a simulator) received by the client, or may be a communication signaling body parsed from the operation. In practical applications, the communication signaling may be delivered to the client by a target object (e.g., user, simulator) via a user interaction interface provided by the client. At least one candidate message object and an interactive operation control indicating a specific operation can be presented on the user interactive interface. The specific operations indicated by the interactive operation control may include, but are not limited to, a send operation, a delete operation, a mark read operation. The target object may determine a specified message object from the at least one candidate message object and trigger an interactive operation control associated with the specified message object. An external management class (Manager) of the client converts the specific operation information indicated by the specified message object and the triggered interactive operation control into an inward communication signaling. A session management class (convertionmanager) or a message management class (MessageCenter) of the client determines a corresponding specified message object and operation information for the specified message object (corresponding to the specific operation information indicated by the triggered interactive operation control) in response to the communication signaling.

In step S202, a corresponding retry object is created based on the specified message object and the operation information.

In the embodiment of the present specification, the client creates a corresponding retry object based on the specified message object and the operation information. Considering that there may be a failure of an operation for a specified message object, a retry object is created before the operation. Compared with the method for caching the message object needing to be subjected to retry operation after the operation failure, the method can better store the message object needing to be subjected to retry operation, and avoid the condition that the message object is lost and is not retried.

In an exemplary embodiment, as shown in FIG. 3, a retry object may be created by:

in step S301, an operation type is obtained based on the operation information, and a first field for recording the operation type is determined.

In step S302, a key message object is determined from the specified message object, and a second field for recording the key message object is determined.

In step S303, a third field for recording creation time and a fourth field for recording the number of retries are determined.

In step S304, the retry object is created based on the first field, the second field, and the third field, the fourth field.

See table 1 below, which shows the data composition of the retry subject:

TABLE 1

The field extraction is performed based on the specified message object and the operation information to create the retry object, so that the efficiency of information recording by using the retry object can be improved, the accuracy and the rate of subsequent searching in the database storing the retry object can be improved, and the efficiency of retry operation based on the retry object can be improved. At least one of the first field, the second field, the third field, and the fourth field may be selected to create a retry object. In practical applications, a retry object may be created based on the first field, the second field, the third field, and the fourth field. It should be noted that, a retry object data may be uniquely identified by using retryType (corresponding to the first field) and retryJSONString (corresponding to the second field) as joint primary keys, so as to prevent repetition.

For example, designate a message object as indicating "is weather good today? "a message, the operation information indicates a transmission operation. The client may obtain a first operation type indicating a transmission operation based on the operation information, and determine a first field (see "retryType" in table 1) for recording the first operation type. The client may determine a key message object from the specified message object and determine a second field for recording the key message object (see "retryJSONString" in table 1). The key message object may indicate "weather". The client may determine a third field (see "createTime" in table 1) for recording creation time, and a fourth field (see "retryCount" in table 1) for recording the number of retries, the contents recorded in the third field being formally determined based on the actual creation time of the retry object, and the contents recorded in the fourth field may vary with the course of the retry operation.

In an exemplary embodiment, a retry object may be created by: firstly, determining the session identifier of the appointed message object; then, the retry object is created based on the specified message object, the belonging session identification, and the operation information. Considering the application of session messages in a session scene, the session identifier is introduced when creating the retry object, and the valid specification can be performed on the retry object corresponding to at least two messages belonging to the same session. Specific applications may refer to the related record of "retry operation based on the retry object" in step S203, and the retry object group is constructed based on the session dimension, so as to prevent the problem of disorder when the retry objects corresponding to the plurality of messages retry together.

In an exemplary embodiment, when the communication signaling is a first type of communication signaling indicating transmission, after the creating of the corresponding retry object based on the specified message object and the operation information, the method further includes the steps of: when preprocessing information aiming at the appointed message object is received, processing the appointed message object based on the preprocessing information to obtain a target message object; and sending the target message object.

When the communication signaling is the first type of communication signaling indicating transmission, the transmission operation of the designated message object is required. After the client side acquires the instruction of 'sending operation to the specified message object', if the client side receives the preprocessing information aiming at the specified message object, the client side indicates that the specified message object needs to be compressed, custom data needs to be added, resources need to be uploaded and the like. For example, the first preprocessing information indicates that the specified message object is compressed according to a preset compression rule, and then the client compresses the specified message object according to the preset compression rule to obtain the target message object, and then performs a sending operation on the target message object. The second preprocessing information indicates that the specified image is added, then the client merges the specified message object and the specified image to obtain the target message object, and then performs a sending operation on the target message object.

In consideration of the application scene of the instant messaging product, the specified message object is processed based on the pre-processing information which is sent in a complementary mode by the user under the given sending operation option to send the processed specified message object. Therefore, the expandability of the appointed message object can be improved, the information content of the appointed message object used for sending is improved, and the use experience of the instant messaging product of the user is further improved.

In practical application, referring to fig. 6, the client includes an external management class (Manager), a message management class (MessageCenter), and a retry management class (RetryManager). In connection with sequence numbers 1-14 indicating the timing sequence in FIG. 6, it can be seen that: 1. the call to send the message is triggered inward by the external management class. 2. The message management class initializes the message state and stores the message in a message database (MessageDB) which can be understood as storing the above specified message objects. 3. The message management class informs the outside that the message is about to start sending. 4. The message management class informs the retry management class that the message is about to start to be sent by the proxy method. 5. The retry management class creates a retry object in the callback method and temporarily stores the retry object in a retry database (retry db), and at this time, the purpose of storing the retry object is to prevent the user from actively exiting the App in the message sending process, which results in interruption of the current operation process, and the message failed to be sent cannot be retransmitted. 6. The retry management class returns the result of whether the retry object was successfully stored in the RetryDB to the message management class. 7. The message management class updates the MessageDB based on the result of whether the retry object was successfully stored in the RetryDB. An identification bit may be set in the extended attribute of the message that records whether the retry object was successfully stored. The flag bit is set to prevent the retry object from being stored until the RetryDB fails, and when the message fails to be sent, the state of the message should be Failed, but changed to set, and the retry object cannot be found later, so that the state is set all the time, and the true Failed state cannot be changed. 8. The message management class seeks to the external management class whether there is a first class of preprocessing (e.g., compressing, adding custom data) operation through proxy methods. 9. The external management class returns the result of the first class pretreatment with the specification to the message management class. 10. The message management class updates the related messages and the related message states in the message db based on the returned results. 11. The message management class seeks to the external management class whether there is a second class of pre-processing (e.g., uploading resources) operation by proxy methods. 12. And returning the result of the second type pretreatment with the designation to the message management class by the external management class. The external management class assigns the resource URL address obtained after the uploading is completed to a message, and then returns the message with the resource URL address to the message management class. 13. The message management class updates the related message and the related message state in the message db based on the returned result, for example, the updated message state is that the uploading is completed. 14. The message management class asynchronously invokes the long connection (Link) interface to send the message. It should be noted that the MessageDB and the RetryDB may synchronize with respect to the message state of the related message object.

In an exemplary embodiment, before the creating of the corresponding retry object based on the specified message object and the operation information, the method further includes the steps of: and when the communication signaling is the second type communication signaling, generating feedback information indicating that the operation is successful, and displaying the feedback information on a user interaction interface, wherein the second type communication signaling comprises communication signaling indicating that the deletion and the indication mark are read.

The second type of communication signaling may be other operations indicating deletion, indicating that the tag has been read, etc., as opposed to the first type of communication signaling indicating transmission. In consideration of the application scene of the instant messaging product, feedback information indicating successful operation is displayed on the user interaction interface under the options of established deleting operation, marked read operation and the like, so that the timeliness of response can be improved on the user level. Therefore, the situation that the subsequent operation on the operation link is blocked and cannot be executed due to the fact that the corresponding operation is waited for to be successfully executed can be avoided, the operation habit of the user can be matched, and the use experience of the instant messaging product of the user is improved. It should be noted that, although feedback information indicating that the operation was successful is displayed earlier than the operation was performed, the operation is performed asynchronously and retried after failure.

Other operations such as deleting, marking reading and the like indicated by the second type of communication signaling can be operations with response time-lapse requirements, and accordingly, the result of the operation on the designated message object needs to be fed back in time. Operations with responsive aging requirements may include, but are not limited to, delete operations, flag read operations. In instant messaging products. An operation with response age requirements may be a management class operation that is more biased towards a message object for which the target object (e.g., user, simulator) has higher control authority, while the management class operation does not affect other objects (e.g., other users). For example, the deletion operation performed by the user on the message a received by the user deletes the message a having the higher control authority, and does not affect the viewing of the message a having the higher control authority by the sender of the message a or other recipients of the message a.

In practical application, referring to fig. 7, the client includes an external management class (Manager), a message management class (MessageCenter), a session management class (convertionmanager), and a retry management class (RetryManager). In connection with sequence numbers 1-6 indicating the timing in FIG. 7, it can be seen that: 1. the invocation of the external management class triggers the marking of a message that a session has been read or deleted, or some other operation, inwards. 2. Determining an object to be operated (such as a transmitted/received message, a created session) in a logical process of a session/message management class according to the condition of the input, updating a message database based on the object to be operated and the operation to be performed thereon; 3. the session/message management class returns the results of the processing directly to the caller: an external management class; indicating externally that the operation is complete. 4. If there is no problem with the operation of the message database, the session/message management class directly first asynchronously informs the retry management class that the message is about to begin marking the session as read or delete the message by proxy methods. 5. The retry management class creates a retry object in the callback method and temporarily stores the retry object in a retry database (RetryDB). 6. The session/message management class asynchronously invokes the long connection (Link) interface to mark the session as read or delete the message. It should be noted that "marking that a session has been read" may be regarded as marking that a session message has been read. The message database and the RetryDB may be synchronized with respect to the message status of the associated message object.

In step S203, when the operation for the specified message object fails and the failure cause is not in accordance with a preset network condition, a retry operation is performed based on the retry object when the preset network condition is satisfied.

In the embodiment of the present disclosure, after creating the corresponding retry object, the client performs an operation on the specified message object, and if the operation fails because the operation does not meet the preset network condition, performs a retry operation based on the retry object when the operation meets the preset network condition. The preset network conditions may indicate a network environment with a network or even a strong network. If the operation fails because the network environment is not network or even strong, then when the network environment is restored to be network or even strong, the retry operation is performed based on the retry object.

In practical applications, instant messaging is highly dependent on the network, and many situations exist in which users use instant messaging products: the operation interface is blocked and then the operation fails when other operations are executed. Thus, not only the message touch rate can be affected, but also very bad operation experience can be brought to the user. In order to improve the touch rate of the message and bring better experience, the retry operation method of the message object provided by the disclosure can realize the logic of automatically retrying the failed operation. For example, when the network environment is weak or even no network, if the message transmission fails after the preset timeout period is continued, the retry operation is performed based on the retry object when the network environment is restored to have or even to be strong. Therefore, even if the instant messaging product is restarted before the network environment is restored, the created retry object is still available, the probability of successful retry can be improved, the problem that the message cannot be reached due to weak network or even no network is solved, and the situation that a user needs to perform inconvenient manual retry is reduced.

In an exemplary embodiment, as shown in fig. 4, the method may further include the following steps before the retry operation based on the retry subject.

In step S401, a current time and a creation time recorded in the retry object are determined.

In step S402, a difference between the current time and the creation time is calculated.

In step S403, when the difference is greater than a first preset value, the retry subject is marked as invalid, and the step of performing a retry operation based on the retry subject is not triggered.

For example, the creation time of the record in the retry object is 12:00, the first preset value is 2 (units: minutes). If the current time is 12:01, the difference between the current time and the creation time is 1, the difference is smaller than a first preset value, the difference meets the timeliness requirement, and therefore retry operation is performed based on the retry object. If the current time is 12:05, the difference between the current time and the creation time is 5, the difference is greater than a first preset value, the difference does not meet the timeliness requirement, and therefore the retry subject is marked as invalid, and the step of performing the retry operation based on the retry subject is not triggered. When the current time is 12:02, the difference between the current time and the creation time is 2, and the difference is equal to the first preset value, and the difference can be considered to meet the timeliness requirement, so that the retry operation is performed based on the retry object. The first preset value can be flexibly set in combination with the operation type and the specific application scene of the instant messaging product.

The difference between the current time and the creation time is calculated by recording the creation time in the retry subject and introducing the calculation parameter as a reference. A first preset value indicating a maximum time interval is introduced to determine whether the difference satisfies the timeliness requirement. When the difference exceeds the first preset value, the retry is not performed due to the lost timeliness. Therefore, the retry operation lacking timeliness can be effectively filtered, and the occupation of excessive retry operation to the computing resource is avoided, so that the data processing efficiency and the user experience of the instant messaging product are ensured.

In an exemplary embodiment, as shown in fig. 5, the retry operation based on the retry subject may include the following steps.

In step S501, if the number of retries is less than or equal to a second preset value, continuing to perform retry operation based on the retry object; and when the retry operation fails continuously, updating the number of retries recorded in the retry object, and repeating the step of continuously performing the retry operation based on the retry object.

In step S502, if the number of retries is greater than the second preset value, the step of continuing to retry the operation based on the retry subject is not triggered.

When the Nth retry operation fails, the number of retries recorded in the retry object is updated from N-1 to N, where N is an integer greater than 0. For example, when the first retry operation fails, the number of retries recorded in the retry subject is updated from 0 to 1. When the second retry operation fails, the number of retries recorded in the retry subject is updated from 1 to 2.

For example, the number of retries is 3, the second preset value is 4, and since 3 is smaller than 4, the fourth retry operation is continued. The situations that may occur after this are:

1) If the fourth retry operation is successful, no more retries are required.

2) If the fourth retry operation fails, the number of retries recorded in the retry subject is updated from 3 to 4, and 4 as the current number of retries is equal to the second preset value, and then the fifth retry operation is continued. If the fifth retry operation is successful, no more retries are required.

3) If the fourth retry operation fails, the number of retries recorded in the retry subject is updated from 3 to 4, and 4 as the current number of retries is equal to the second preset value, and then the fifth retry operation is continued. If the fifth retry operation fails, the number of retries recorded in the retry subject is updated from 4 to 5, and 5, which is the current number of retries, is greater than the second preset value, then the retry cannot be performed based on the throttling principle (which is used to prevent an endless retry).

Recording the retry times which change along with the process of the retry operation in the retry subject, and introducing a second preset value indicating the maximum retry times as a reference to judge whether the current retry times exceed the limit. When the current retry times exceeds the second preset value, the retry is not performed, so that the endless retry is prevented, the occupation of computing resources by the endless retry is avoided, and the normal use of the instant messaging product by a user is prevented from being influenced by the endless retry without returning an operation failure notice.

In an exemplary embodiment, before the retry operation based on the retry subject, the method may further include the steps of: first, determining a matched message database based on the operation information; then, inquiring whether a message object matched with the retry object exists in the matched message database; further, when not present, the step of marking the retry as invalid and not triggering the retry operation based on the retry. And when present, triggering the step of performing a retry operation based on the retry subject.

Depending on the operation information, the designated message object associated with the operation information is stored by a different message database, although the message database may also store the message status of the message object. For example, operation information 1 (indicating a transmission operation) corresponding to communication signaling 1 and a specified message object 1, operation information 2 (indicating a deletion operation) corresponding to communication signaling 2 and a specified message object 2 are stored by the message database 1, and the specified message object 2 is stored by the message database 2. The message database stores the message objects which need to be correspondingly operated. At the same time, the message database is more dynamically real-time to maintain the message object than the retry object creation logic. When the message database is not searched for the message object matched with the retry object, the related message object is deleted, the message database is shifted out of the message object, and the operation on the message object is not needed. Accordingly, the step of marking the retry object as invalid and not triggering the retry operation based on the retry object can be avoided, and the adaptability of the retry logic is improved.

Illustratively, the message object is specified as indicating "is weather good today? "a message, the operation information indicates a send operation, the matching message database may be a message database indicating a send operation. If the target object (e.g. user, simulator) does not want to send a message after creating the retry object, the message database moves out of the specified message object or the target message object that was originally matched with the retry object (which may be described in the related step S202, and will not be repeated), then the message object that is matched with the retry object cannot be queried in the matched message database, thereby marking that the retry object is invalid, and the step of performing the retry operation based on the retry object is not triggered to effectively avoid the occurrence of an error retransmission.

Further, before the step of triggering the retry operation based on the retry subject when present, the method further includes the steps of: firstly, when the communication signaling is a first type communication signaling indicating transmission, determining the transmission state of the matched message object; then, when the sending state is sending, determining whether the matched message object has resources to be uploaded or not; finally, when present, marking the retry as invalid, and not triggering the step of performing a retry operation based on the retry.

When a message object matching the retry object is queried in the message database, it is indicated that the message object has a possibility of requiring an operation. Whether it needs to operate or not can be determined by sending a status:

1) The sending status of the matched message objects is determined.

2) And when the transmission state is that the transmission is successful, marking that the retry object is invalid, and not triggering the step of performing retry operation based on the retry object. The transmission status of "transmission success" indicates that no operation is required for the message object, and that the retry object fails to delete after the message is directly transmitted successfully or the message is retransmitted successfully.

3) When the transmission state is in transmission, determining whether the matched message object has resources to be uploaded. The transmission status of "in transmission" indicates that there is still a possibility that an operation is required, and then it is determined based on "whether there is a resource to be uploaded". 3.1 When present, marking the retry subject as invalid, and not triggering a retry operation based on the retry subject. If there is a data error that indicates that the resource is not uploaded, the resource is interrupted or is too large to be completely uploaded, and the retry is not performed to avoid the possible data error caused by the resource to be uploaded. 3.2 When not present, triggering a retry operation based on the retry subject. If there is a risk that the above-mentioned data errors are not present, retransmission may be performed.

In an exemplary embodiment, before the retry operation based on the retry subject, the method further includes the steps of: firstly, when the communication signaling is a first type communication signaling indicating transmission, transmitting a request for inquiring whether a message object matched with the retry object exists or not to a server side; and then, marking the retry object to fail when the received query result indicates the presence, and not triggering the step of performing a retry operation based on the retry object.

The server side provides background service for the client side. For example, if the user a sends a message to the user B, the client a (corresponding to the user a) sends the message to the server, and then the server sends the message to the client B (corresponding to the user B), and the server provides the instant messaging background service for the client a and the client B. If the message is not queried at the server, it indicates that the message has not been sent from the client a to the server, and thus needs to be retransmitted. If the server side has inquired the message, it indicates that the message has been sent from the client side a to the server side, possibly because the client side a does not delete the retry object if it does not receive the packet due to the network difference, thereby marking that the retry object is invalid, and not triggering the step of performing the retry operation based on the retry object. Considering the application scene of the instant messaging product, under the given sending operation option, the server side is used for inquiring related message objects, so that the error retransmission caused by network difference is avoided.

In an exemplary embodiment, in combination with the description of "creating the retry object based on the specified message object, the session identifier, and the operation information" in the foregoing step S202, the performing a retry operation based on the retry object may include the following steps: firstly, when the communication signaling is a first type communication signaling indicating transmission, determining a retry object pointing to the same session with the retry object; then, constructing a retry object group based on the retry object and a retry object pointing to the same session as the retry object; and finally, performing retry operation based on the retry subject group.

Messages in the same session often have timing when retransmissions are performed, such as user C sequentially sending messages a-D to user D, messages a-D being directed to the sessions of user C and user D. Since message a has a corresponding retry object a, message b has a corresponding retry object b, message c has a corresponding retry object c, and message d has a corresponding retry object d, then a retry object set a is constructed, which includes retry objects a-d. A retry operation is then performed based on the retry subject group a, where retransmission may be achieved via a batch operated interface. The retry object group is constructed based on the session dimension, so that the problem of disorder during retry of the retry objects corresponding to the plurality of messages can be prevented.

In an exemplary embodiment, after the retry operation based on the retry subject, the method further includes the steps of: firstly, when the retry operation is successful, determining a matched message database based on the operation information; then, a message object matching the retry object is determined in the matching message database, and the message status of the matching message object is updated.

After the retry operation is successful, a matching message database may be determined based on the operation information and the message status of the corresponding message object in the matching message database may be updated. For example, the operation information indicates a sending operation, and after the retry operation is successful, the message status of the corresponding message object in the matched message database may be updated from "sending" to "sending successful". Therefore, the message database can maintain the message object and the corresponding message state with timeliness. In practice, the message database and retry database (RetryDB) may be synchronized with respect to the message status of the associated message object.

In addition, whether the message is resent or retransmitted is automatically judged during resending, and if the message is resent, the operations such as authentication, URL change and the like are executed.

The retry logic application in practice will be described with reference to fig. 6-8.

First, when the communication signaling is the first type of communication signaling indicating transmission, it can be seen that, in conjunction with sequence numbers 15-21 indicating the sequence in fig. 6: 15. the message management class receives a notification returned by a callback mode and indicating a sending result. 16. The message management class updates the message db based on the notification, such as the updated relevant message status is successful or failed. 17. Because the retry management class needs to perform related processing (reservation/deletion) on the stored retry operations according to the result of the network request, the message management class needs to notify the retry management class by proxy of notification indicating the transmission result. 18. The retry management class, after receiving the notification indicating the transmission result, processes according to whether or not Error is a network Error: if the network error exists, reserving a retry object and updating the corresponding message state as the sending state; and if the network error is not generated or the network error is not generated, removing the temporarily stored retry object in the RetryDB, and generating return information indicating that the flag bit is removed. 19. The retry management class returns the processing result to the message management class through a Callback (Callback mode). 20. The message management class updates the MessageDB based on the result. 21. The message management class informs the external management class of the completion of the transmission, and the external management class informs the external management class of the end of the transmission flow.

The message is complicated to send, and if the network is wrong, the message is changed from the sending failure state to the sending state, the message is displayed as the sending state, and the next networking can be automatically retried. The present disclosure uses DB to persist the retry object, whether the operation is interrupted due to restart or the transmission fails due to network cause, the incomplete operation can be found again, and the retry operation is performed after the next re-networking or restart. Meanwhile, the reasons for message transmission failure are filtered, and only transmission failure operations caused by network reasons are stored, so that meaningless (authority problems, parameter errors and the like) failed retry operations can be avoided.

Then, when the communication signaling is the second type of communication signaling indicating deletion, reading of the flag, etc., it can be seen that, in combination with sequence numbers 7-9 indicating the sequence in fig. 7: 7. the session/message management class receives a notification indicating the result of the operation returned by way of a callback. 8. After the session/message management class takes the result, the retry management class is notified of the data and Error by proxy. 9. Judging whether the retry management class is a network Error after the retry management class takes Error, and if the retry management class is the network Error, not performing any other processing on the retry object temporarily stored in the retry DB; if Error is empty or is not a network Error, the buffered retry object is removed from the RetryDB.

The present disclosure uses the RetryDB to persist the operation object of the stored signaling, and even if App is restarted during the request process, or the operation fails, the operation is not lost. The retry operation can be performed after the next re-networking or restarting, and the completion of the operation is ensured to the greatest extent. The updating of the operation result is not completely finished depending on the signaling request, but update data is directly returned and signaling is sent asynchronously, and the experience of a service end is improved in a two-step mode; even if the signaling fails to be sent due to network problems, retry can be performed, so that the correctness of the result can be ensured.

Further, referring to fig. 8, a failed retry procedure is described in detail below, and includes a retry of a message transmission failure, a retry of a marked session read, and a retry of a delete message. It is also possible to add other conditional decisions after "whether it is to delete message data" to extend the handling of other operations by the failed retry management class. The concrete explanation is as follows: 1. after the network is restored, the long connection is reconnected to restore the connection establishment state, and the IMSDK searches the RetryDB for whether a retry object to be executed exists. 2. If a retry object to be executed exists, judging corresponding operation information, wherein different retry flows are needed for different corresponding operation information. If no retry object is queried, the next flow is directly ended. 3. If the corresponding operation information is the indication sending operation, executing a retry flow of the sending message: it is first determined whether the message is still present (e.g., deleted) in the local MessageDB, if so, the subsequent "4" is continued, and if not, the message is marked as a status of failed transmission and the corresponding retry object is removed from the retry list in the retry database, and the next other retry objects are executed. 4. Then, it is determined whether the message is in the transmission state (e.g., the transmission is successful, but the retry list fails to remove the data), if so, the subsequent "5" is continued, and if not, the message is also marked as the transmission failure state and the corresponding retry object is removed from the retry list, and the next other retry objects are executed. 5. Then, it is further determined whether the message is an attachment type message (picture message, file message … …) and whether they need to be re-uploaded (the resource is interrupted without starting the uploading or is too large to be completely uploaded), if not, the subsequent "5" is continued, otherwise, the message is marked as a status of failed transmission and the corresponding retry object is removed from the retry list, and the next other retry objects are executed. 6. Then judging whether the time difference between the current time and the creation time recorded in the retry object exceeds the maximum retry time interval, if the time difference is too long, considering that the message has lost timeliness, and not retransmitting, removing the related retry object in the retry table at the moment, and executing other subsequent retry objects; otherwise, the subsequent "7" is continued. 7. Then the server side inquires whether the message is present or not (because the message may be sent successfully, but because the network difference does not receive the packet, the message is considered as not being sent successfully), if not, the subsequent '8' is continued, otherwise, the local message db is updated by taking the data returned by the server side, and meanwhile, the related retry object in the retry list is removed, and the next other retry objects are executed. 8. If the above conditions are met, then a message retransmission operation is started, which automatically determines whether the message is resent or retransmitted to perform a different operation. The interface of batch operation can be used in the retransmission process, so that the problem of disorder in the process of retransmitting a plurality of messages together can be prevented; and if the retransmission is successful, changing the corresponding message to be in a successful state, removing the related retry object in the retry list, and continuing the next flow. Otherwise, detecting whether the retry reaches the maximum retry number, if so, removing the related retry object in the retry list, and executing other subsequent retry objects; if the number of retries is not reached, the number of retries is increased, the next continuous retry is waited until the retry is successful or the maximum number of retries is reached, and thus the flow of retries for sending the message is ended. 9. If the corresponding operation information is the indication mark read operation, the corresponding session in the local convertiondb (session database) is judged whether to exist (if so, the corresponding session is deleted), if so, the subsequent '10' is continued, otherwise, the related retry object in the retry list is directly removed, and the next other retry objects are executed. 10. Then, the retry operation of marking that the session is read is started, if the retry is successful, the convertionDB is updated and the related retry object in the retry list is removed, and the next flow is continued. Otherwise, detecting whether the retry reaches the maximum retry number, if so, removing the related retry object in the retry list, and executing other subsequent retry objects; if the number of retries is not reached, the number of retries is increased, and the next continuous retry is waited until the retry is successful or the maximum number of retries is reached, so that the read flow of the retry marking session is ended. 11. If the corresponding operation information is the instruction of deleting operation, the operation information is the same as the retry flow of the read operation: firstly, inquiring whether the message exists in the local MessageDB or not, if so, continuing, otherwise, directly removing the related retry object in the retry list, and executing other subsequent retry objects; then, the retry operation of deleting the message is started, if the retry is successful, the message db is updated and the related retry object in the retry list is removed, and the next flow is continued. Otherwise, detecting whether the retry reaches the maximum retry number, if so, removing the related retry object in the retry list, and executing other subsequent retry objects; if the number of retries is not reached, the number of retries is increased, the next continuous retry is waited until the retry is successful or the maximum number of retries is reached, and thus the retry deleting message flow is ended.

The method and the device have the advantages that all retry operations are uniformly scheduled, so that the expansion of the current retry operation and the addition of other retry operations are more convenient. The flow of other operations except for sending the message is almost the same, so that the logic high multiplexing is achieved, and the unified adjustment can be realized. The process of retrying the sending information is highly refined, and the problems of error retransmission (deleting the information), repeated information (existing at the server), data errors (uploading needed by resources) and the like are effectively avoided. Meanwhile, the limit on the interval time is increased, and the message losing timeliness is prevented from being retransmitted; the limit of the retry number is increased, and the problem that the message cannot be successfully retried all the time and is retried without limit due to some reasons is prevented. The retransmission of the messages also uses the function of batch transmission/batch retransmission, thereby effectively avoiding the problem of disordered sequence when retransmitting a plurality of messages in the same session; the problem of whether to send or forward is also adapted, so that the problem of resource authorization caused by forwarding when the message carries a resource file can be avoided. According to the retry operation scheme for the message object, the retry logics which are scattered before are concentrated into the retry management class, so that an independent retry module is formed for unified processing, and the maintenance is convenient. And associated with the associated processing logic by way of a proxy. These processing logic are scattered throughout the SDK and the associated retry logic is strongly correlated. On one hand, high cohesive low coupling of logic is realized, and on the other hand, the expandability of the logic is greatly enhanced. All signaling processing logic requiring failed retries is archived to the same place. After the related instant messaging product applies the retry operation scheme for the message object provided by the disclosure, the overall (including the new and old versions, the old version not supporting retransmission capability) message transmission failure rate is reduced by about 30% (from 2.3% to 1.6%), and only the new version message transmission failure rate is seen to be 1.1%. And the ratio of the number of message transmission failures to the total number of transmission failures is reduced from 43% to 10% because of the network.

In the retry operation method for the message object provided in the above embodiment, default operation for the specified message object may have failure, and a retry object is created before operation, so that effective storage of the retry object is realized, and when the retry condition is met, the retry operation is performed based on the retry object. The probability of successful retry is improved, and the situation that the user needs inconvenient manual retry is reduced. The method and the device can improve the touch rate of the message in the weak network environment, and ensure that some operations can be completed necessarily under the condition of improving user experience. In addition, the conditions for retrying the message with failed transmission are subdivided, so that the problems of error retransmission (deleted message), repeated message (existing at the server), data error (uploading of resources is needed), disordered message (multiple failed messages in the same session), staleness (overlong time interval/excessive retrying times) and the like can be effectively avoided. The retry operation is uniformly managed, the expansibility of the retry operation is improved, and the retry logic of other operations is convenient to increase.

Fig. 9 is a block diagram illustrating a retry operation apparatus 900 for a message object according to an exemplary embodiment. Referring to fig. 9, the apparatus includes a response unit 901, a creation unit 902, and a retry unit 903.

The response unit 901 is configured to perform determination of a specified message object and operation information corresponding to a received communication signaling in response to the communication signaling; wherein the operation information indicates an operation for the specified message object;

the creating unit 902 is configured to execute creating a corresponding retry object based on the specified message object and the operation information;

the retry unit 903 is configured to perform a retry operation based on the retry object when a predetermined network condition is satisfied when the operation for the specified message object fails and the failure cause is not satisfied.

The specific manner in which the various modules perform the operations in the apparatus of the above embodiments have been described in detail in connection with the embodiments of the method, and will not be described in detail herein.

In an exemplary embodiment, there is also provided an electronic device including a processor; a memory for storing processor-executable instructions; wherein the processor is configured to implement the steps of any of the retry operation methods for a message object described in the above embodiments when executing instructions stored on the memory.

The electronic device may be a terminal, a server, or a similar computing device, which is exemplified by a server, fig. 10 is a block diagram of an electronic device for implementing a retry operation method for a message object according to an exemplary embodiment, the electronic device 1000 may be relatively different due to configuration or performance, and may include one or more central processing units (Central Processing Units, CPU) 1010 (the processor 1010 may include, but is not limited to, a microprocessor MCU, a display device such as a programmable logic device FPGA, etc.), a memory 1030 for storing data, one or more storage media 1020 (such as one or more mass storage devices) for storing application 1023 or data 1022. Wherein the memory 1030 and storage medium 1020 can be transitory or persistent storage. The program stored on the storage medium 1020 may include one or more modules, each of which may include a series of instruction operations in the electronic device. Still further, the central processor 1010 may be configured to communicate with a storage medium 1020 and execute a series of instruction operations in the storage medium 1020 on the electronic device 1000. The electronic device 1000 can also include one or more power supplies 1060, one or more wired or wireless network interfaces 1050, one or more input/output interfaces 1040, and/or one or more operating systems 1021, such as Windows ServerTM, mac OS XTM, unixTM, linuxTM, freeBSDTM, and the like.

Input-output interface 1040 may be used to receive or transmit data via a network. Specific examples of the network described above may include a wireless network provided by a communication provider of the electronic device 1000. In one example, input-output interface 1040 includes a network adapter (Network Interface Controller, NIC) that may be connected to other network devices via base stations to communicate with the internet. In an exemplary embodiment, the input/output interface 100 may be a Radio Frequency (RF) module for communicating with the internet in a wireless manner.

It will be appreciated by those of ordinary skill in the art that the configuration shown in fig. 10 is merely illustrative and is not intended to limit the configuration of the electronic device described above. For example, electronic device 1000 may also include more or fewer components than shown in FIG. 10 or have a different configuration than shown in FIG. 10.

In an exemplary embodiment, a computer readable storage medium is also provided, such as a memory, comprising instructions executable by the processor 1010 of the electronic device 1000 to perform the above-described retry operation method for a message object. Alternatively, the computer readable storage medium may be ROM, random Access Memory (RAM), CD-ROM, magnetic tape, floppy disk, optical data storage device, etc.

In an exemplary embodiment, a computer program product is also provided, the computer program product comprising computer instructions, the computer program/instructions being stored in a computer readable storage medium. The processor of the electronic device reads the computer program/instructions from the computer-readable storage medium, and the processor executes the computer program/instructions so that the electronic device performs the retry operation method for a message object provided in any one of the above embodiments.

Those skilled in the art will appreciate that implementing all or part of the above described methods may be accomplished by way of a computer program stored on a non-transitory computer readable storage medium, which when executed, may comprise the steps of the embodiments of the methods described above. Any reference to memory, storage, database, or other medium used in the various embodiments provided herein may include non-volatile and/or volatile memory. The nonvolatile memory can include Read Only Memory (ROM), programmable ROM (PROM), electrically Programmable ROM (EPROM), electrically Erasable Programmable ROM (EEPROM), or flash memory. Volatile memory can include Random Access Memory (RAM) or external cache memory. By way of illustration and not limitation, RAM is available in a variety of forms such as Static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), double Data Rate SDRAM (DDRSDRAM), enhanced SDRAM (ESDRAM), synchronous Link DRAM (SLDRAM), memory bus direct RAM (RDRAM), direct memory bus dynamic RAM (DRDRAM), and memory bus dynamic RAM (RDRAM), among others.

Other embodiments of the disclosure will be apparent to those skilled in the art from consideration of the specification and practice of the disclosure disclosed herein. This application is intended to cover any adaptations, uses, or adaptations of the disclosure following, in general, the principles of the disclosure and including such departures from the present disclosure as come within known or customary practice within the art to which the disclosure pertains. It is intended that the specification and examples be considered as exemplary only, with a true scope and spirit of the disclosure being indicated by the following claims.

It is to be understood that the present disclosure is not limited to the precise arrangements and instrumentalities shown in the drawings, and that various modifications and changes may be effected without departing from the scope thereof. The scope of the present disclosure is limited only by the appended claims.

Claims

1. A method of retry operations for a message object, the method comprising:

responding to the received communication signaling, and determining a designated message object and operation information corresponding to the communication signaling; wherein the operation information indicates an operation for the specified message object, the operation belonging to any one of a plurality of preset operations;

Creating a corresponding retry object based on the specified message object and the operation information, and storing the retry object and the specified message object locally, wherein the retry object characterizes a corresponding relation between the specified message object and the operation information;

operating the specified message object based on the operation information;

when the operation for the specified message object fails and the failure cause does not meet the preset network condition, performing retry operation based on the retry object when the preset network condition is met;

wherein, before the retry operation based on the retry subject, the method further comprises:

determining a matched message database based on the operational information; inquiring whether a message object matched with the retry object exists in the matched message database; marking the retry subject as invalid when not present, and not triggering the step of performing a retry operation based on the retry subject; and when the operation information exists, triggering the step of retrying operation based on the retrying object, wherein the matched message database is locally positioned, and the matched message database maintains the message object indicating the operation information in real time.

2. The method of claim 1, wherein the creating a corresponding retry object based on the specified message object and the operation information comprises:

3. The method of claim 2, wherein prior to the retry operation based on the retry subject, the method further comprises:

determining a current time and a creation time recorded in the retry object;

calculating a difference between the current time and the creation time;

4. A method according to any one of claims 2 or 3, wherein said performing a retry operation based on said retry subject comprises:

If the current retry times are smaller than or equal to a second preset value, continuing to perform retry operation based on the retry object;

when the retry operation fails continuously, updating the number of retries recorded in the retry object and repeating the step of continuing the retry operation based on the retry object;

5. The method of claim 1, wherein prior to the step of triggering the retry operation based on the retry subject, the method further comprises:

when present, marking the retry as invalid and not triggering the retry operation based on the retry

Is carried out by a method comprising the steps of.

6. The method of claim 5, wherein after said determining the transmission status of the matched message object, the method further comprises:

7. The method of claim 1, wherein prior to the retry operation based on the retry subject, the method further comprises:

8. The method of claim 1, wherein the creating a corresponding retry object based on the specified message object and the operation information comprises:

determining the session identifier of the specified message object;

9. The method of claim 8, wherein when the operation information indicates a transmission operation, the retry operation based on the retry subject comprises:

Determining a retry object pointing to the same session with the retry object according to the session identifier carried by the retry object;

and performing retry operation based on the retry subject group.

10. The method of claim 1, wherein when the communication signaling is a first type of communication signaling indicating transmission, after the creating of the corresponding retry object based on the specified message object and the operation information, the method further comprises:

and sending the target message object.

11. The method of claim 1, wherein prior to the creating the corresponding retry object based on the specified message object and the operation information, the method further comprises:

12. The method of claim 1, wherein after the retry operation based on the retry subject, the method further comprises:

13. A retry operation apparatus for a message object, the apparatus comprising:

a response unit configured to perform determination of a specified message object and operation information corresponding to a received communication signaling in response to the communication signaling; wherein the operation information indicates an operation for the specified message object, the operation belonging to any one of a plurality of preset operations;

a creation unit configured to execute creation of a corresponding retry object based on the specified message object and the operation information, and to store the retry object and the specified message object locally, the retry object characterizing a correspondence between the specified message object and the operation information;

An operation unit configured to perform an operation on the specified message object based on the operation information;

a retry unit configured to perform a retry operation based on the retry object when a predetermined network condition is satisfied when an operation for the specified message object fails and the failure cause is not satisfied;

wherein the apparatus further comprises: a first database determining unit configured to perform determining a matched message database based on the operation information; a first querying unit configured to perform querying in the matched message database whether there is a message object matched with the retry object; a second cancel retry unit configured to perform the steps of marking the retry subject as invalid when not present, and not triggering the retry operation based on the retry subject; and the triggering unit is configured to trigger the retry operation based on the retry object when the operation information exists, the matched message database is locally positioned, and the matched message database maintains the message object indicating the operation information in real time.

14. The apparatus of claim 13, wherein the creating unit comprises:

15. The apparatus of claim 14, wherein the apparatus further comprises:

16. The apparatus according to any one of claims 14 or 15, wherein the retry unit comprises:

17. The apparatus of claim 13, wherein the apparatus further comprises:

the resource to be uploaded determining unit is configured to determine whether the matched message object has a resource to be uploaded or not when the transmission state is in transmission;

a third cancel retry unit configured to perform marking the retry object as invalid when present, and not triggering the retry object

And performing retry operation based on the retry subject.

18. The apparatus of claim 17, wherein the apparatus further comprises:

19. The apparatus of claim 13, wherein the apparatus further comprises:

20. The apparatus of claim 13, wherein the creating unit comprises:

21. The apparatus of claim 20, wherein the retry unit comprises:

22. The apparatus of claim 13, wherein when the communication signaling is a first type of communication signaling indicating transmission, the apparatus further comprises:

23. The apparatus of claim 13, wherein the apparatus further comprises:

24. The apparatus of claim 13, wherein the apparatus further comprises:

25. An electronic device, comprising:

a processor;

a memory for storing the processor-executable instructions;

wherein the processor is configured to execute the instructions to implement the retry method of operation for a message object as claimed in any one of claims 1 to 12.

26. A non-transitory computer readable storage medium, which when executed by a processor of an electronic device, causes the electronic device to perform the retry operation method for a message object as claimed in any one of claims 1 to 12.