CN111479334B - Network request retry method and device and terminal equipment - Google Patents
Network request retry method and device and terminal equipment Download PDFInfo
- Publication number
- CN111479334B CN111479334B CN202010199740.8A CN202010199740A CN111479334B CN 111479334 B CN111479334 B CN 111479334B CN 202010199740 A CN202010199740 A CN 202010199740A CN 111479334 B CN111479334 B CN 111479334B
- Authority
- CN
- China
- Prior art keywords
- request
- network
- retry
- response
- queue
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Active
Links
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W76/00—Connection management
- H04W76/10—Connection setup
- H04W76/18—Management of setup rejection or failure
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/50—Network services
- H04L67/60—Scheduling or organising the servicing of application requests, e.g. requests for application data transmissions using the analysis and optimisation of the required network resources
- H04L67/61—Scheduling or organising the servicing of application requests, e.g. requests for application data transmissions using the analysis and optimisation of the required network resources taking into account QoS or priority requirements
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W76/00—Connection management
- H04W76/10—Connection setup
- H04W76/19—Connection re-establishment
Abstract
The application provides a network request retry method, a device and a terminal device, which are applicable to the technical field of data processing, wherein the method comprises the following steps: detecting a response state of a network request initiated by an application program; if the response fails, acquiring the field parameters corresponding to the network request with the failed response, and adding the network request with the failed response and the corresponding field parameters to a retry request queue; if the request response is successful, the network requests in the repeated request queue are prioritized; taking out the network request with the highest priority and the corresponding field parameter from the retry request queue, and initiating the network request with the highest priority based on the extracted field parameter; and if the network request with the highest priority is successfully responded, returning to execute the operation of taking out the network request with the highest priority and the corresponding field parameter from the retry request queue until the retry request queue is emptied. The embodiment of the application can greatly improve the success probability of network request retry.
Description
Technical Field
The application belongs to the technical field of data interaction, and particularly relates to a network request retry method and terminal equipment.
Background
Network requests are a common front-end and back-end interaction mode of application programs, and when the network is abnormal, the network requests often respond to failures. In order to improve the probability of success of the network request when the network is abnormal, a network retry mechanism, i.e. a scheme for performing network request retry after the network request response fails, needs to be formulated in advance.
The existing network request mechanism directly retries to initiate the network request when the response of the network request fails, and the retry is stopped until the response of the network request is successful or the number of retries reaches a certain threshold, but statistics show that the success rate of the retry of the network request is extremely low and the normal use of the application program by a user can be seriously influenced.
Disclosure of Invention
In view of this, the embodiment of the application provides a network request retry method and terminal equipment, which can solve the problem of low success rate of network request retry.
A first aspect of an embodiment of the present application provides a network request retry method, including:
detecting a response state of a network request initiated by an application program;
if the network request response failure is detected, acquiring a field parameter corresponding to the network request with the response failure, and adding the network request with the response failure and the corresponding field parameter into a retry request queue, wherein the field parameter comprises a request mode, a request address and a request parameter of the network request;
If the network request response is detected to be successful, the network requests in the retry request queue are subjected to priority ordering, wherein the retry request queue is a queue formed by network requests with response failure;
extracting a network request with the highest priority and a corresponding field parameter from the retry request queue, and initiating the network request with the highest priority based on the extracted field parameter;
and if the network request with the highest priority is successfully responded, returning to execute the operation of taking out the network request with the highest priority and the corresponding field parameter from the retry request queue until the retry request queue is emptied.
In a first possible implementation manner of the first aspect, the first aspect further includes:
if the response of the network request with the highest priority fails, adding the network request with the highest priority and the corresponding field parameter to the retry request queue, and returning to execute the operation of detecting the response state of the network request in the application program.
In a second possible implementation manner of the first aspect, the first aspect further includes:
if an interface switching instruction or an interface exit instruction for the current display interface of the application program is detected, searching all application program functions contained in the current display interface;
And screening all network requests corresponding to the application program function from the retry request queue based on the function identification, and removing the screened network requests from the retry request queue.
In a third possible implementation manner of the first aspect, the prioritizing the network requests in the retry request queue includes:
acquiring first history request data of the application program and field parameters of network requests with successful history response in the first history request data, wherein the first history request data comprises network requests initiated by the history of the application program and initiation times of each network request;
based on the initiation times of the network requests in the first historical request data, carrying out priority ordering on the network requests in the retry request queue to obtain a first priority sequence corresponding to the network requests in the retry request queue;
based on the on-site parameters of the network requests with successful historical response, the network requests in the retry request queue are subjected to priority ordering to obtain a second priority sequence corresponding to the network requests in the retry request queue;
And fusing the priorities in the first priority sequence and the second priority sequence to obtain the priority of each network request in the retry request queue.
In a fourth possible implementation manner of the first aspect, the first history request data includes second history request data of the application program after the application program is started up for the time, and third history request data of the application program before the application program is started up for the time, and the prioritizing the network requests in the retry request queue based on the number of times of network requests in the first history request data is started up to obtain a first priority sequence includes:
screening out the first initiation times of each network request in the retry request queue from the second historical request data, and screening out the second initiation times of each network request in the retry request queue from the third historical request data;
performing weight calculation on the first initiation times and the second initiation times of each network request in the retry request queue to obtain weight scores corresponding to each network request in the retry request queue, wherein the weight coefficient corresponding to the first initiation times is larger than the weight coefficient corresponding to the second initiation times;
And sequencing the priority of each network request in the retry request queue according to the order of the weight scores from high to low to obtain a first priority sequence.
In a fifth possible implementation manner of the first aspect, on the basis of the third possible implementation manner, the prioritizing the network requests in the retry request queue based on the field parameters of the network requests that have succeeded in the historical response to obtain a second priority sequence includes:
performing field parameter matching on the network requests in the retry request queue and the network requests with successful historical responses, screening out the network requests with highest field parameter matching degree with each network request in the retry request queue from the network requests with successful historical responses, and taking the screened network requests as target requests;
and screening response success times and third initiation times of each target request from the first historical request data, and sequencing the priority of each network request in the retry request queue according to the order that the ratio of the response success times to the third initiation times is from high to low to obtain a second priority sequence.
A second aspect of an embodiment of the present application provides a network request retry apparatus, including:
the response detection module is used for detecting the response state of the network request initiated by the application program;
the request caching module is used for acquiring field parameters corresponding to the network request with failed response if the network request is detected to be failed in response, and adding the network request with failed response and the corresponding field parameters into the retry request queue, wherein the field parameters comprise a request mode, a request address and a request parameter of the network request;
the request ordering module is used for ordering the priority of the network requests in the retry request queue if the network request response is detected to be successful, wherein the retry request queue is a queue formed by the network requests with failed responses;
the request retry module is used for taking out the network request with the highest priority and the corresponding field parameter from the retry request queue, and initiating the network request with the highest priority based on the extracted field parameter;
and the return execution module is used for returning to execute the operation of taking out the network request with the highest priority and the corresponding field parameter from the retry request queue until the retry request queue is emptied if the response of the network request with the highest priority is successful.
A third aspect of an embodiment of the present application provides a terminal device, the terminal device comprising a memory, a processor, the memory having stored thereon a computer program executable on the processor, the processor implementing the steps of the network request retry method according to any of the first aspects described above when the computer program is executed.
A fourth aspect of embodiments of the present application provides a computer-readable storage medium comprising: a computer program is stored, characterized in that it when executed by a processor implements the steps of the network request retry method according to any of the above first aspects.
A fifth aspect of an embodiment of the present application provides a computer program product, which when run on a terminal device, causes the terminal device to perform the network request retry method according to any one of the first aspects above.
Compared with the prior art, the embodiment of the application has the beneficial effects that: when detecting that the response of the network request fails, the network request with failed response is buffered to a retry request queue, and each network request with failed response in the retry request queue is sequenced and retried only when the response of the network request is successful, because the success of the response means that the current network is available, the probability of success of the retry can be greatly improved, and meanwhile, the priority sequencing retry of the network request can be carried out, so that the probability of success of each retry can be improved as much as possible, and finally, the retry request queue is continuously processed only when the response of the network request with highest extracted real-time priority is successful, thereby ensuring that the embodiment of the application continuously retries the network request under the normal condition of the network, avoiding invalid repeated attempts and guaranteeing the success rate of each retry.
Drawings
In order to more clearly illustrate the technical solutions of the embodiments of the present application, the drawings that are needed in the embodiments or the description of the prior art will be briefly described below, it being obvious that the drawings in the following description are only some embodiments of the present application, and that other drawings may be obtained according to these drawings without inventive effort for a person skilled in the art.
Fig. 1 is a schematic flow chart of an implementation of a network request retry method according to an embodiment of the present application;
fig. 2 is a schematic implementation flow chart of a network request retry method according to a second embodiment of the present application;
fig. 3 is a schematic implementation flow chart of a network request retry method according to a third embodiment of the present application;
fig. 4 is a schematic implementation flow chart of a network request retry method according to a fourth embodiment of the present application;
fig. 5 is a schematic flow chart of an implementation of a network request retry method according to a fifth embodiment of the present application;
fig. 6 is a schematic structural diagram of a network request retry apparatus according to a sixth embodiment of the present application;
fig. 7 is a schematic diagram of a terminal device according to a seventh embodiment of the present application.
Detailed Description
In the following description, for purposes of explanation and not limitation, specific details are set forth such as the particular system architecture, techniques, etc., in order to provide a thorough understanding of the embodiments of the present application. It will be apparent, however, to one skilled in the art that the present application may be practiced in other embodiments that depart from these specific details. In other instances, detailed descriptions of well-known systems, devices, circuits, and methods are omitted so as not to obscure the description of the present application with unnecessary detail.
In order to illustrate the technical scheme of the application, the following description is made by specific examples.
In order to facilitate an understanding of the present application, embodiments of the present application will be briefly described herein. Because the network connection is generally abnormal when the network request fails, if the retry success rate is extremely low when the network request fails, the network request is not managed and controlled only by the retry, thereby wasting valuable network resources and not achieving the aim of truly retrying the network request.
In order to improve the success rate of network request retry, the embodiment of the application does not directly retry the network request when detecting that the response of the network request fails, but caches the network request with failed response to a retry request queue, and only when the response of the network request is successful, sequences and retries the network request with failed response in the retry request queue, because the success of the response means that the current network is available, the probability of success of retry can be greatly improved, and meanwhile, the priority sequence retry is performed on the network request, the probability of success of each retry can be improved as much as possible, and finally, the processing of the retry request queue is continued only when the response of the network request with highest extracted real-time priority is successful, thereby ensuring that the embodiment of the application continuously retries the network request under the normal condition of the network, avoiding invalid repeated attempts, and guaranteeing the success rate of each retry.
Meanwhile, in the embodiment of the present application, the execution body of the network request retry may be any terminal device capable of running an application program and sending the network request, where the specific device type is not limited herein, and may be selected or set by a technician according to the requirements of an actual scenario, including, but not limited to, a mobile terminal, a computer, a server, and the like.
The embodiment of the application is described in detail as follows:
fig. 1 shows a flowchart of an implementation of a network request retry method according to an embodiment of the present application, which is described in detail below:
s101, detecting a response state of a network request initiated by an application program.
In the embodiment of the application, the response state of each network request initiated by the application program is monitored in real time, namely whether each network request is successful or failed in response, and the subsequent processing strategy is selected according to different response states.
S102, if the network request response failure is detected, acquiring the field parameters corresponding to the network request with the response failure, and adding the network request with the response failure and the corresponding field parameters into a retry request queue, wherein the field parameters comprise a request mode, a request address and a request parameter of the network request.
In the embodiment of the application, a retry request queue is preset for caching network requests for which the response of the application program fails. Therefore, when the response of the network request fails, the embodiment of the application does not directly retry, but adds the network request with failed response and the corresponding field parameters to the retry request queue for later retry call. The on-site parameters are mainly used for truly restoring the network request when the network request retries.
And S103, if the network request response is detected to be successful, the network requests in the retry request queue are prioritized, wherein the retry request queue is a queue formed by the network requests with failed responses.
When the success of the response of the network request is detected, the network connection is normal, namely the success rate of the retry of the network request is extremely high, so that the embodiment of the application can trigger a retry mechanism of the network request with failed response when the success of the response of the network request is detected. Meanwhile, the importance degree of different network requests to users is not necessarily the same, and meanwhile, the success rate of the network requests can be different due to the differences of request objects, request contents and the like of the network requests, so that in order to meet the actual conditions of the different network requests as much as possible and the requirements of the actual users, the network requests in the retry request queue are sequenced firstly, and then the subsequent retry operation is performed. The retry request queues in S102 and S103 are the same queue, and the method for ordering the network requests in the queue is not limited herein, and may be set by a technician according to actual requirements, including but not limited to, for example, simply ordering according to the addition time, or ordering according to the importance level of the application program function corresponding to the network request, and may refer to the third to fifth embodiments of the present application.
And S104, taking out the network request with the highest priority and the corresponding field parameter from the retry request queue, and initiating the network request with the highest priority based on the extracted field parameter.
After finishing ordering the network requests in S103, the embodiment of the present application removes the network request with the highest priority and the field parameter corresponding to the network request, determines a specific request address and a request mode based on the field parameter, and reinitiates the network request with the highest priority, thereby implementing retry on the network request with the highest priority.
And S105, if the network request response with the highest priority is successful, returning to execute the operation of taking out the network request with the highest priority and the corresponding field parameter from the retry request queue until the retry request queue is emptied.
After retrying the highest priority network request, the embodiment of the application also detects whether the retry response is successful.
When the response of the network request with the highest priority is successful, it indicates that the network connection is still normal at this time, that is, the success rate of retrying the network request is still higher, so the embodiment of the application returns to the operation of step S104, continues to fetch the network request with the highest priority from the network requests remained in the retry request queue, and continues to retry the fetched network request. If the retry of each network request is successful, the network requests in the retry request queue can be retried one by circularly taking out the network request with the highest real-time priority and retrying, and the effective retry of all network requests with failed responses can be completed.
According to the embodiment of the application, when the response failure of the network request is detected, the network request with the response failure is not directly retried, but is buffered to the retry request queue, and each network request with the response failure in the retry request queue is sequenced and retried only when the response success of the network request is detected, and the response success means that the current network is available, so that the probability of success of the retry can be greatly improved, and meanwhile, the priority sequencing retry is carried out on the network request, the probability of success of each retry can be improved as much as possible, and finally, the retry request queue is continuously processed only when the response of the network request with the highest extracted real-time priority is successful, thereby ensuring that the network request retry is continuously carried out under the normal condition of the network, avoiding invalid repeated attempts, and ensuring the success rate of each retry.
As an embodiment of the present application, on the basis of retrying a network request with the highest priority in the embodiment of the present application, considering that in practical application, each retry may not be successful, so in order to ensure the success rate of each retry in the case of failure of the retry, in the embodiment of the present application, after retrying the network request with the highest priority, the method further includes:
If the response of the network request with the highest priority fails, adding the network request with the highest priority and the corresponding field parameters to a retry request queue, and returning to execute the operation of detecting the response state of the network request in the application program.
In the embodiment of the application, when the response of the network request with the highest priority fails, the network condition at that time is abnormal, and the success rate of the network request retry is extremely low, so that the embodiment of the application stops the retry of the network request in the retry request queue at that time to avoid excessive useless retry to reduce the success rate of the retry, and simultaneously, the network request with the highest priority of the retry failure and the corresponding field parameter are added to the retry request queue again, and the monitoring step of S101 for the response state of the network request of the application program is returned.
In consideration of the fact that in an optional embodiment of the present application, a large functional interface may include a plurality of functions, for example, in a bank application financial interface, may include a plurality of different financial function modules, and a user may perform operations such as buying and selling of a plurality of different financial products therein, and a news interface may include a plurality of different news selecting and browsing functions.
Therefore, in order to ensure the normal use of the application program by the user, in the second embodiment of the present application, the field parameter further includes a function identifier, where the function identifier is used to identify the function of the application program corresponding to the network request, and monitor the operation condition of the user on the function interface, and timely clear the network request with a failure response, so as to ensure the normal use of the user, as shown in fig. 2, in the second embodiment of the present application, the first embodiment of the present application further includes, while performing the operations of S101-S105:
s201, if an interface switching instruction or an interface exit instruction of a current display interface of the application program is detected, searching all application program functions contained in the current display interface.
The current display interface refers to a functional interface of the current browsing operation of the user, a financial interface, a news interface and the like in the bank application program. When the user performs the interface switching or the exiting operation, it is indicated that the user does not need to use the current display interface, so that the embodiment of the present application searches all functions included in the current display interface at this time to perform the subsequent network request removal.
S202, based on the function identification, screening all network requests corresponding to the application program function from a retry request queue, and removing the screened network requests from the retry request queue.
After obtaining all application program functions contained in the current display interface, the embodiment of the application judges whether the application program function corresponding to the network request belongs to the application program function or not based on the function identification in each network request field parameter, if so, the application program function is removed from the retry request queue, so that all the network requests corresponding to the current display interface in the retry request queue can be cleared in time, and the normal use of the application program by a user is ensured.
As a specific implementation manner of ordering network requests in a retry request queue in the first embodiment of the present application, considering that in practical application, functions corresponding to network requests in the retry request queue are different, interface conditions corresponding to the requests are different, when retry is performed on the request, if retry is performed directly according to an added time sequence, the success rate of retry cannot be maximized (for example, interfaces of servers corresponding to different requests are different, and when the requests are successful, the success rate of requests of the same or similar interfaces is definitely greater), and the practical requirements of users cannot be met (although the users trigger network requests of different functions, the degree of requirement of each function is different to some extent, most likely because some functions are tried randomly after finding that the network is abnormal), so the effectiveness of retry is extremely low.
In order to improve the success rate and effectiveness of retry, the embodiment of the present application performs the network request priority ordering based on two dimensions of the user's requirement level for each network request and the success rate of each network request retry, as shown in fig. 3, and based on each embodiment of the present application, the third pair of network request ordering operations of the embodiment of the present application specifically includes:
s301, acquiring first historical request data of an application program and field parameters of network requests with successful historical response in the first historical request data, wherein the first historical request data comprises network requests initiated by the application program history and initiation times of each network request.
The first history request data is network requests initiated by the application program history and the initiation times of each network request, and the first history request data is response data to the user history requirements, so that the degree of the user requirements on each network request can be reflected to a certain extent by analyzing the first history request data. It should be noted that, in the embodiment of the present application, the sampling time range of the first historical request data is not limited, and may be set by a technician according to the actual requirement, for example, all the historical data since the application program is installed, or the historical data within a specific period of time, such as the historical request data in the last year, because the user's requirement has a certain real-time property, and thus, the reference value of the historical request data for some historical request data with too long an interval may be relatively low.
On the one hand, because there may be a certain difference between addresses, modes and the like of the requests corresponding to different network requests, when a certain network request is successful in response, the probability of successful response is definitely larger than that of dissimilar network requests for network requests with similar field parameters, on the other hand, because of the difference of objects of the network requests, there may be a certain difference between success rates among the network requests, for example, for servers with crowded network states for a long time, if the objects of the application program network requests are the servers, the probability of failure of the network requests is greatly increased in recognition. Therefore, in the embodiment of the present application, all the network requests and the field parameters that are successfully responded in the first historical request data are acquired for subsequent analysis, where, because the same network request may have a situation that the historical multiple responses are successfully responded, in order to avoid interference caused by multiple analyses, only one of the field parameters is reserved, and as an optional implementation, only the sequential field parameters closest to the current time may be reserved.
S302, based on the initiation times of the network requests in the first historical request data, the network requests in the retry request queue are prioritized, and a first priority sequence corresponding to the network requests in the retry request queue is obtained.
Based on the first historical request data, the embodiment of the application ranks the network requests in the retry request queue based on the initiation times of the network requests, so as to obtain the priority of the network requests in the retry request queue, thereby realizing the effective analysis of the user on the demand of the network requests.
S303, based on the field parameters of the network request with successful historical response, the network requests in the retry request queue are prioritized, and a second priority sequence corresponding to the network requests in the retry request queue is obtained.
After acquiring the network request field parameters with successful historical response, the embodiment of the application sorts the network requests in the retry request queue according to the actual response conditions of the network requests with successful historical response and the similarity conditions of the retry request queue and the network requests with successful historical response, so as to obtain a corresponding second priority sequence, and the specific sorting method is not limited herein, including but not limited to sorting according to the response success times corresponding to the network requests with successful historical response, then matching the network requests with successful historical response corresponding to each network request in the retry request queue through the field parameters, and sorting according to the response success times corresponding to each network request in the retry request queue, or referring to the fifth embodiment of the application.
S304, fusing the priorities in the first priority sequence and the second priority sequence to obtain the priorities of all network requests in the retry request queue.
After the two priority sequences are acquired, the embodiment of the application also fuses the specific priorities of each network request in the two priority sequences, so as to obtain the final priority condition. The specific fusion method is not limited herein, and may be set by a technician at his own discretion, for example, it may be to directly calculate the average value and perform the sorting, for example, it is assumed that for the network request a, the priorities in the first priority sequence and the second priority sequence are 1 and 5, respectively, and the average value is 3 at this time, and then the sorting is performed again according to the average value of all the network requests.
As an optional embodiment of the present application, considering that in actual situations, there may be a certain difference between requirements for user demand and response success rate under different scene requirements, for example, in some possible scenes, the user demand needs to be preferentially ensured, and in other possible scenes, the response success rate needs to be preferentially ensured, so when two priority sequences are fused, the embodiment of the present application may set a weight coefficient for each sequence, and perform weight calculation on the priority based on the weight coefficient, where a value of a specific weight coefficient may be set by a technician according to actual scene requirements, so as to implement effective response to different scene requirements, and implement different side consideration for user demand or response success rate.
As a specific implementation manner of calculating the first priority sequence in the third embodiment of the present application, considering that in the actual situation, the user's requirement has very strong real-time performance, and the time interval of each application used by the user cannot be predicted, that is, whether the interval time of the last application used is too long or not cannot be predicted, and for the history request data with too long interval time, the reference value of the analysis on the user requirement is relatively low, so in order to improve the accuracy of the analysis on the user requirement as much as possible, in the fourth embodiment of the present application, the first history request data is further disassembled, divided into the second history request data of the application after the application is started, and the third history request data of the application before the application is started, and the second history request data and the third history request data are analyzed in a distinguishing manner, as shown in fig. 4, the calculation process of the first priority sequence in the fourth embodiment of the present application specifically includes:
s401, screening out first initiation times of each network request in the retry request queue from the second historical request data, and screening out second initiation times of each network request in the retry request queue from the third historical request data.
According to the embodiment of the application, firstly, based on the second historical request data and the third historical request data, the network requests in the retry request queue are counted respectively, so that the corresponding first and second initiation times are obtained.
S402, carrying out weight calculation on the first initiation times and the second initiation times of each network request in the retry request queue to obtain weight scores corresponding to each network request in the retry request queue, wherein the weight coefficient corresponding to the first initiation times is larger than the weight coefficient corresponding to the second initiation times.
In consideration of the fact that the interval duration of the last application program use cannot be predicted, the second historical request data generated by the application program use at the time is the latest data, and the current user demand situation can be represented most, the embodiment of the application can perform weight calculation on the first initiation times and the second initiation times, and the weight coefficient corresponding to the first initiation times is set to be larger than the weight coefficient corresponding to the second initiation times, so that the influence degree of the latest data on user demand calculation is increased. The specific value of the weight coefficient corresponding to the first initiation times and the second initiation times is not limited herein, and can be set by a technician according to the requirement.
And S403, sequencing the priority of each network request in the repeated request queue according to the order of the weight scores from high to low, and obtaining a first priority sequence.
After the weight score of each network request is obtained, the priority of each network request is ordered from high to low in weight minutes, so that the priority of the network requests can be ordered based on the user demand, and a required first priority sequence is obtained.
As a specific implementation manner of calculating the second priority sequence in the third embodiment of the present application, in consideration of the actual situation, the network requests in the retry request queue do not have to respond to the actual situation, that is, there are no network requests in the retry request queue in the network requests with successful history response, so if the network requests are directly searched for in a matching manner, the searching effect may be extremely poor, and the effectiveness of the sequencing is further reduced.
In order to ensure the validity of the sorting result and ensure the accuracy and reliability of the analysis of the success rate of the re-ranking, as shown in fig. 5, in the fifth embodiment of the present application, the search of the network request is not directly performed, but the matching of the similar requests is performed, and the analysis sorting is performed based on the network request with the most similar historical response success, and the step of calculating the second priority sequence in the fifth embodiment of the present application includes:
S501, performing field parameter matching on the network requests in the retry request queue and the network requests with successful historical response, screening out the network requests with highest field parameter matching degree with each network request in the retry request queue from the network requests with successful historical response, and taking the screened network requests as target requests.
In order to realize matching search of similar network requests, specifically, network requests in a retry request queue and network requests with successful historical responses are subjected to field parameter matching, and one network request with the highest similarity and successful historical response is searched, so that target requests corresponding to the network requests in the retry request queue one by one are obtained. Wherein, for a single network request in the retry request queue, if it ever responds to the request, the search process is itself. The embodiment of the application does not limit a specific matching method, can be selected or set by a technician according to actual requirements, for example, can be set to match each data in the field parameters one by one so as to ensure the matching reliability.
In order to improve the matching reliability, in the embodiment of the application, the field parameters further comprise function identifiers, and the function identifiers are used for identifying the functions of the application programs corresponding to the network requests, so that when the field parameters are matched, the functions corresponding to the network requests are further matched, and the matching result is more accurate and reliable.
As an optional embodiment of the application, when matching on-site parameters, different matching rules can be set for each item of data in the matching rules respectively so as to meet the requirements of different data characteristics, and the reliability of data matching is improved, for example, for a request mode, the request modes can be combined in advance, corresponding similarity is set according to the similarity condition of the request modes in each pair of combinations, for example, the similarity of the same request mode is the maximum value, the similarity is reduced in a similar sequence, for a request address, the server type or company to which the address corresponds can be set with the highest similarity for the same server, the similarity of the servers of the same type or company is the lowest, and after similarity calculation is carried out on each item of data respectively, the weight summation is carried out, so that the corresponding matching degree can be obtained.
S502, the response success times and the third initiation times of all target requests are screened out from the first historical request data, and the network requests in the request queue are prioritized according to the order that the response success times are higher than the third initiation times, so as to obtain a second priority sequence.
After matching target requests corresponding to each network request in the retry request queue, the embodiment of the application searches corresponding response success times and third sending times from the first historical request data, calculates the proportion of the response success times to the third sending times, thereby obtaining corresponding response success rates, and finally sequences each network request in the retry request queue according to the order of the response success rates from high to low, thereby obtaining an accurate and reliable second priority sequence.
Corresponding to the method of the above embodiment, fig. 6 shows a block diagram of a network request retry apparatus according to an embodiment of the present application, and for convenience of explanation, only a portion related to the embodiment of the present application is shown. The network request retry apparatus illustrated in fig. 6 may be an execution subject of the network request retry method provided in the first embodiment.
Referring to fig. 6, the network request retry apparatus includes:
the response detection module 61 is configured to detect a response state of a network request initiated by an application program.
The request cache module 62 is configured to, if a network request response failure is detected, obtain a field parameter corresponding to the network request with the response failure, and add the network request with the response failure and the corresponding field parameter to the retry request queue, where the field parameter includes a request mode, a request address, and a request parameter of the network request.
The request ordering module 63 is configured to, if it is detected that the network request response is successful, prioritize the network requests in a retry request queue, where the retry request queue is a queue formed by network requests that fail to respond.
The request retry module 64 is configured to take out the network request with the highest priority and the corresponding field parameter from the retry request queue, and initiate the network request with the highest priority based on the extracted field parameter.
And the return execution module 65 is configured to return to execute the operation of taking out the network request with the highest priority and the corresponding field parameter from the retry request queue until the retry request queue is emptied, if the response of the network request with the highest priority is successful.
Further, the network request retry apparatus further includes:
and the buffer adding module is used for adding the network request with the highest priority and the corresponding field parameter to the retry request queue if the response of the network request with the highest priority fails, and returning to execute the operation of detecting the response state of the network request in the application program.
Further, the network request retry apparatus further includes:
And the instruction detection module is used for searching all application program functions contained in the current display interface if an interface switching instruction or an interface exit instruction of the current display interface of the application program is detected.
And the request removing module is used for screening all network requests corresponding to the application program function from the retry request queue based on the function identification, and removing the screened network requests from the retry request queue.
Further, the request ordering module 63 includes:
the data acquisition module is used for acquiring first historical request data of the application program and on-site parameters of network requests with successful historical responses in the first historical request data, wherein the first historical request data comprises the network requests initiated by the application program history and the initiation times of each network request.
And the first sequencing module is used for sequencing the priority of the network requests in the retry request queue based on the initiation times of the network requests in the first historical request data to obtain a first priority sequence corresponding to the network requests in the retry request queue.
And the second sequencing module is used for sequencing the network requests in the retry request queue in priority based on the field parameters of the network requests with successful historical responses to obtain a second priority sequence corresponding to the network requests in the retry request queue.
And the sequencing fusion module is used for fusing the priorities in the first priority sequence and the second priority sequence to obtain the priority of each network request in the retry request queue.
Further, the first history request data includes second history request data of the application program after the application program is started up for the time and third history request data of the application program before the time of starting up, and the first ordering module includes:
and screening out the first initiation times of each network request in the retry request queue from the second historical request data, and screening out the second initiation times of each network request in the retry request queue from the third historical request data.
And carrying out weight calculation on the first initiation times and the second initiation times of each network request in the retry request queue to obtain weight scores corresponding to each network request in the retry request queue, wherein the weight coefficient corresponding to the first initiation times is larger than the weight coefficient corresponding to the second initiation times.
And sequencing the priority of each network request in the retry request queue according to the order of the weight scores from high to low to obtain a first priority sequence.
Further, the second sorting module includes:
and performing field parameter matching on the network requests in the retry request queue and the network requests with successful historical responses, screening out the network requests with highest field parameter matching degree with each network request in the retry request queue from the network requests with successful historical responses, and taking the screened network requests as target requests.
And screening response success times and third initiation times of each target request from the first historical request data, and sequencing the priority of each network request in the retry request queue according to the order that the ratio of the response success times to the third initiation times is from high to low to obtain a second priority sequence.
The process of implementing the respective functions of each module in the network request retry apparatus according to the embodiment of the present application may refer to the description of the first embodiment shown in fig. 1, and will not be repeated here.
It should be understood that the sequence number of each step in the foregoing embodiment does not mean that the execution sequence of each process should be determined by the function and the internal logic, and should not limit the implementation process of the embodiment of the present application.
It should be understood that the terms "comprises" and/or "comprising," when used in this specification and the appended claims, specify the presence of stated features, integers, steps, operations, elements, and/or components, but do not preclude the presence or addition of one or more other features, integers, steps, operations, elements, components, and/or groups thereof.
It should also be understood that the term "and/or" as used in the present specification and the appended claims refers to any and all possible combinations of one or more of the associated listed items, and includes such combinations.
As used in the present description and the appended claims, the term "if" may be interpreted as "when..once" or "in response to a determination" or "in response to detection" depending on the context. Similarly, the phrase "if a determination" or "if a [ described condition or event ] is detected" may be interpreted in the context of meaning "upon determination" or "in response to determination" or "upon detection of a [ described condition or event ]" or "in response to detection of a [ described condition or event ]".
Furthermore, the terms "first," "second," "third," and the like in the description of the present specification and in the appended claims, are used for distinguishing between descriptions and not necessarily for indicating or implying a relative importance. It will also be understood that, although the terms "first," "second," etc. may be used herein in some embodiments of the application to describe various elements, these elements should not be limited by these terms. These terms are only used to distinguish one element from another element. For example, a first table may be named a second table, and similarly, a second table may be named a first table without departing from the scope of the various described embodiments. The first table and the second table are both tables, but they are not the same table.
Reference in the specification to "one embodiment" or "some embodiments" or the like means that a particular feature, structure, or characteristic described in connection with the embodiment is included in one or more embodiments of the application. Thus, appearances of the phrases "in one embodiment," "in some embodiments," "in other embodiments," and the like in the specification are not necessarily all referring to the same embodiment, but mean "one or more but not all embodiments" unless expressly specified otherwise. The terms "comprising," "including," "having," and variations thereof mean "including but not limited to," unless expressly specified otherwise.
The network request retry method provided by the embodiment of the application can be applied to terminal equipment such as mobile phones, tablet computers, wearable equipment, vehicle-mounted equipment, augmented reality (augmented reality, AR)/Virtual Reality (VR) equipment, notebook computers, ultra-mobile personal computer (UMPC), netbooks, personal digital assistants (personal digital assistant, PDA) and the like, and the embodiment of the application does not limit the specific types of the terminal equipment.
By way of example, but not limitation, when the terminal device is a wearable device, the wearable device may also be a generic name for applying wearable technology to intelligently design daily wear, developing wearable devices, such as glasses, gloves, watches, apparel, shoes, and the like. The wearable device is a portable device that is worn directly on the body or integrated into the clothing or accessories of the user. The wearable device is not only a hardware device, but also can realize a powerful function through software support, data interaction and cloud interaction. The generalized wearable intelligent device comprises full functions, large size, and complete or partial functions which can be realized independent of a smart phone, such as a smart watch or a smart glasses, and is only focused on certain application functions, and needs to be matched with other devices such as the smart phone for use, such as various smart bracelets, smart jewelry and the like for physical sign monitoring.
Fig. 7 is a schematic structural diagram of a terminal device according to an embodiment of the present application. As shown in fig. 7, the terminal device 7 of this embodiment includes: at least one processor 70 (only one shown in fig. 7), a memory 71, said memory 71 having stored therein a computer program 72 executable on said processor 70. The processor 70, when executing the computer program 72, implements the steps of the various network request retry method embodiments described above, such as steps 101 through 105 shown in fig. 1. Alternatively, the processor 70, when executing the computer program 72, performs the functions of the modules/units of the apparatus embodiments described above, such as the functions of the modules 61 to 65 shown in fig. 6.
The terminal device 7 may be a computing device such as a desktop computer, a notebook computer, a palm computer, a cloud server, etc. The terminal device may include, but is not limited to, a processor 70, a memory 71. It will be appreciated by those skilled in the art that fig. 7 is merely an example of the terminal device 7 and does not constitute a limitation of the terminal device 7, and may include more or less components than illustrated, or may combine certain components, or different components, e.g., the terminal device may further include an input transmitting device, a network access device, a bus, etc.
The processor 70 may be a central processing unit (Central Processing Unit, CPU), or may be another general purpose processor, a digital signal processor (Digital Signal Processor, DSP), an application specific integrated circuit (Application Specific Integrated Circuit, ASIC), an off-the-shelf programmable gate array (Field-Programmable Gate Array, FPGA) or other programmable logic device, discrete gate or transistor logic device, discrete hardware components, or the like. A general purpose processor may be a microprocessor or the processor may be any conventional processor or the like.
The memory 71 may in some embodiments be an internal storage unit of the terminal device 7, such as a hard disk or a memory of the terminal device 7. The memory 71 may be an external storage device of the terminal device 7, such as a plug-in hard disk, a Smart Media Card (SMC), a Secure Digital (SD) Card, a Flash memory Card (Flash Card) or the like, which are provided on the terminal device 7. Further, the memory 71 may also include both an internal storage unit and an external storage device of the terminal device 7. The memory 71 is used for storing an operating system, application programs, boot loader (BootLoader), data, other programs, etc., such as program codes of the computer program. The memory 71 may also be used for temporarily storing data that has been transmitted or is to be transmitted.
In addition, each functional unit in the embodiments of the present application may be integrated in one processing unit, or each unit may exist alone physically, or two or more units may be integrated in one unit. The integrated units may be implemented in hardware or in software functional units.
Embodiments of the present application also provide a computer readable storage medium storing a computer program which, when executed by a processor, implements steps for implementing the various method embodiments described above.
Embodiments of the present application provide a computer program product which, when run on a mobile terminal, causes the mobile terminal to perform steps that enable the implementation of the method embodiments described above.
The integrated modules/units, if implemented in the form of software functional units and sold or used as stand-alone products, may be stored in a computer readable storage medium. Based on such understanding, the present application may implement all or part of the flow of the method of the above embodiment, or may be implemented by a computer program to instruct related hardware, where the computer program may be stored in a computer readable storage medium, and when the computer program is executed by a processor, the computer program may implement the steps of each of the method embodiments described above. Wherein the computer program comprises computer program code which may be in source code form, object code form, executable file or some intermediate form etc. The computer readable medium may include: any entity or device capable of carrying the computer program code, a recording medium, a U disk, a removable hard disk, a magnetic disk, an optical disk, a computer Memory, a Read-Only Memory (ROM), a random access Memory (Random Access Memory, RAM), an electrical carrier signal, a telecommunications signal, a software distribution medium, and so forth.
In the foregoing embodiments, the descriptions of the embodiments are emphasized, and in part, not described or illustrated in any particular embodiment, reference is made to the related descriptions of other embodiments.
Those of ordinary skill in the art will appreciate that the various illustrative elements and algorithm steps described in connection with the embodiments disclosed herein may be implemented as electronic hardware, or combinations of computer software and electronic hardware. Whether such functionality is implemented as hardware or software depends upon the particular application and design constraints imposed on the solution. Skilled artisans may implement the described functionality in varying ways for each particular application, but such implementation decisions should not be interpreted as causing a departure from the scope of the present application.
The units described as separate units may or may not be physically separate, and units shown as units may or may not be physical units, may be located in one place, or may be distributed on a plurality of network units. Some or all of the units may be selected according to actual needs to achieve the purpose of the solution of this embodiment.
The above embodiments are only for illustrating the technical solution of the present application, and not for limiting the same; although the application has been described in detail with reference to the foregoing embodiments, it will be understood by those of ordinary skill in the art that: the technical scheme described in the foregoing embodiments can be modified or some technical features thereof can be replaced by equivalents; such modifications and substitutions do not depart from the spirit and scope of the technical solutions of the embodiments of the present application, and are intended to be included in the scope of the present application.
Claims (8)
1. A method for retrying a network request, comprising:
detecting a response state of a network request initiated by an application program;
if the network request response failure is detected, acquiring a field parameter corresponding to the network request with the response failure, and adding the network request with the response failure and the corresponding field parameter into a retry request queue, wherein the field parameter comprises a request mode, a request address and a request parameter of the network request;
if the network request response is detected to be successful, the network requests in the retry request queue are subjected to priority ordering, wherein the retry request queue is a queue formed by network requests with response failure;
extracting a network request with the highest priority and a corresponding field parameter from the retry request queue, and initiating the network request with the highest priority based on the extracted field parameter;
if the network request with the highest priority is successfully responded, the operation of taking out the network request with the highest priority and the corresponding field parameters from the retry request queue is returned to be executed until the retry request queue is emptied;
prioritizing network requests in the retry request queue, comprising:
Acquiring first history request data of the application program and field parameters of network requests with successful history response in the first history request data, wherein the first history request data comprises network requests initiated by the history of the application program and initiation times of each network request;
based on the initiation times of the network requests in the first historical request data, carrying out priority ordering on the network requests in the retry request queue to obtain a first priority sequence corresponding to the network requests in the retry request queue;
based on the on-site parameters of the network requests with successful historical response, the network requests in the retry request queue are subjected to priority ordering to obtain a second priority sequence corresponding to the network requests in the retry request queue;
and fusing the priorities in the first priority sequence and the second priority sequence to obtain the priority of each network request in the retry request queue.
2. The network request retry method of claim 1, further comprising:
if the response of the network request with the highest priority fails, adding the network request with the highest priority and the corresponding field parameter to the retry request queue, and returning to execute the operation of detecting the response state of the network request in the application program.
3. The network request retry method of claim 1, wherein the field parameters further comprise a function identifier, the function identifier is used to identify an application function corresponding to the network request, and the network request retry method further comprises:
if an interface switching instruction or an interface exit instruction for the current display interface of the application program is detected, searching all application program functions contained in the current display interface;
and screening all network requests corresponding to the application program function from the retry request queue based on the function identification, and removing the screened network requests from the retry request queue.
4. The network request retry method of claim 1, wherein the first history request data includes second history request data of the application after the application is started up at a time, and third history request data of the application before the application is started up at a time, and the prioritizing the network requests in the retry request queue based on the number of network requests in the first history request data, to obtain a first priority sequence, includes:
Screening out the first initiation times of each network request in the retry request queue from the second historical request data, and screening out the second initiation times of each network request in the retry request queue from the third historical request data;
performing weight calculation on the first initiation times and the second initiation times of each network request in the retry request queue to obtain weight scores corresponding to each network request in the retry request queue, wherein the weight coefficient corresponding to the first initiation times is larger than the weight coefficient corresponding to the second initiation times;
and sequencing the priority of each network request in the retry request queue according to the order of the weight scores from high to low to obtain a first priority sequence.
5. The network request retry method of claim 1, wherein prioritizing network requests in the retry request queue based on field parameters of network requests for which the historical response was successful, to obtain a second priority sequence, comprises:
performing field parameter matching on the network requests in the retry request queue and the network requests with successful historical responses, screening out the network requests with highest field parameter matching degree with each network request in the retry request queue from the network requests with successful historical responses, and taking the screened network requests as target requests;
And screening response success times and third initiation times of each target request from the first historical request data, and sequencing the priority of each network request in the retry request queue according to the order that the ratio of the response success times to the third initiation times is from high to low to obtain a second priority sequence.
6. A network request retry apparatus, comprising:
the response detection module is used for detecting the response state of the network request initiated by the application program;
the request caching module is used for acquiring field parameters corresponding to the network request with failed response if the network request is detected to be failed in response, and adding the network request with failed response and the corresponding field parameters into the retry request queue, wherein the field parameters comprise a request mode, a request address and a request parameter of the network request;
the request ordering module is used for ordering the priority of the network requests in the retry request queue if the network request response is detected to be successful, wherein the retry request queue is a queue formed by the network requests with failed responses;
the request retry module is used for taking out the network request with the highest priority and the corresponding field parameter from the retry request queue, and initiating the network request with the highest priority based on the extracted field parameter;
The return execution module is used for returning to execute the operation of taking out the network request with the highest priority and the corresponding field parameter from the retry request queue until the retry request queue is emptied if the response of the network request with the highest priority is successful;
the request ordering module comprises:
the data acquisition module is used for acquiring first historical request data of the application program and on-site parameters of network requests with successful historical response in the first historical request data, wherein the first historical request data comprises network requests initiated by the application program history and initiation times of each network request;
the first ordering module is used for ordering the priority of the network requests in the retry request queue based on the initiation times of the network requests in the first historical request data to obtain a first priority sequence corresponding to the network requests in the retry request queue;
the second sequencing module is used for sequencing the network requests in the retry request queue in priority based on the field parameters of the network requests with successful historical response to obtain a second priority sequence corresponding to the network requests in the retry request queue;
And the sequencing fusion module is used for fusing the priorities in the first priority sequence and the second priority sequence to obtain the priority of each network request in the retry request queue.
7. A terminal device, characterized in that it comprises a memory, a processor, on which a computer program is stored which is executable on the processor, the processor executing the computer program to carry out the steps of the method according to any one of claims 1 to 5.
8. A computer readable storage medium storing a computer program, characterized in that the computer program when executed by a processor implements the steps of the method according to any one of claims 1 to 5.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202010199740.8A CN111479334B (en) | 2020-03-20 | 2020-03-20 | Network request retry method and device and terminal equipment |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202010199740.8A CN111479334B (en) | 2020-03-20 | 2020-03-20 | Network request retry method and device and terminal equipment |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN111479334A CN111479334A (en) | 2020-07-31 |
| CN111479334B true CN111479334B (en) | 2023-08-11 |
Family
ID=71748392
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202010199740.8A Active CN111479334B (en) | 2020-03-20 | 2020-03-20 | Network request retry method and device and terminal equipment |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN111479334B (en) |
Families Citing this family (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN112099998A (en) * | 2020-09-24 | 2020-12-18 | 百度在线网络技术（北京）有限公司 | Processing method and device for applet loading failure, electronic equipment and storage medium |
| CN114915659B (en) * | 2021-02-09 | 2024-03-26 | 腾讯科技（深圳）有限公司 | Network request processing method and device, electronic equipment and storage medium |
| CN113823025B (en) * | 2021-08-24 | 2023-04-21 | 广州市瑞立德信息系统有限公司 | Command retry method, system, device and storage medium |
| CN115842865A (en) * | 2022-11-23 | 2023-03-24 | 紫光云技术有限公司 | Method for mobile terminal to dynamically control network request |
Citations (12)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN1491394A (en) * | 2001-08-14 | 2004-04-21 | ���ܿ���ϵͳ����˾ | Timing-insensitive glitch-free logic system and method |
| CN1822556A (en) * | 2005-02-15 | 2006-08-23 | 微软公司 | System and method for applying flexible attributes to execute asynchronous network requests |
| CN101242608A (en) * | 2008-01-29 | 2008-08-13 | 中兴通讯股份有限公司 | Method and system for mobile terminal to search high-priority public land mobile network |
| CN101600240A (en) * | 2009-05-31 | 2009-12-09 | 腾讯科技（北京）有限公司 | Method, instant communication client, management server and system that a kind of many networks switch |
| CN101835234A (en) * | 2010-03-23 | 2010-09-15 | 重庆邮电大学 | Industrial wireless sensor network communication method based on relay nodes |
| CN102752133A (en) * | 2012-06-18 | 2012-10-24 | 东南大学 | Mechanism and method for constructing consistency view in autonomous domain in credible controllable network |
| CN103051539A (en) * | 2012-12-14 | 2013-04-17 | 中兴通讯股份有限公司 | DHT-based (distributed hash table-based) control network implementation method, system and network controller |
| CN108243229A (en) * | 2016-12-26 | 2018-07-03 | 北京国双科技有限公司 | Request processing method and device |
| WO2018217512A1 (en) * | 2017-05-24 | 2018-11-29 | Motorola Mobility Llc | Performing an action based on a number of transmissions reaching a threshold |
| WO2019048932A2 (en) * | 2017-09-11 | 2019-03-14 | Lenovo (Singapore) Pte. Ltd. | Methods and devices for transmitting device capability information |
| CN109474688A (en) * | 2018-11-27 | 2019-03-15 | 北京微播视界科技有限公司 | Sending method, device, equipment and the medium of instant messaging network request message |
| CN109617988A (en) * | 2018-12-28 | 2019-04-12 | 平安科技（深圳）有限公司 | Request retries method and Related product |
Family Cites Families (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US9843557B2 (en) * | 2004-12-09 | 2017-12-12 | Level 3 Communications, Llc | Systems and methods for dynamically registering endpoints in a network |
| US7843809B2 (en) * | 2008-11-14 | 2010-11-30 | At&T Intellectual Property I, L.P. | Preserving stable calls during failover |
-
2020
- 2020-03-20 CN CN202010199740.8A patent/CN111479334B/en active Active
Patent Citations (12)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN1491394A (en) * | 2001-08-14 | 2004-04-21 | ���ܿ���ϵͳ����˾ | Timing-insensitive glitch-free logic system and method |
| CN1822556A (en) * | 2005-02-15 | 2006-08-23 | 微软公司 | System and method for applying flexible attributes to execute asynchronous network requests |
| CN101242608A (en) * | 2008-01-29 | 2008-08-13 | 中兴通讯股份有限公司 | Method and system for mobile terminal to search high-priority public land mobile network |
| CN101600240A (en) * | 2009-05-31 | 2009-12-09 | 腾讯科技（北京）有限公司 | Method, instant communication client, management server and system that a kind of many networks switch |
| CN101835234A (en) * | 2010-03-23 | 2010-09-15 | 重庆邮电大学 | Industrial wireless sensor network communication method based on relay nodes |
| CN102752133A (en) * | 2012-06-18 | 2012-10-24 | 东南大学 | Mechanism and method for constructing consistency view in autonomous domain in credible controllable network |
| CN103051539A (en) * | 2012-12-14 | 2013-04-17 | 中兴通讯股份有限公司 | DHT-based (distributed hash table-based) control network implementation method, system and network controller |
| CN108243229A (en) * | 2016-12-26 | 2018-07-03 | 北京国双科技有限公司 | Request processing method and device |
| WO2018217512A1 (en) * | 2017-05-24 | 2018-11-29 | Motorola Mobility Llc | Performing an action based on a number of transmissions reaching a threshold |
| WO2019048932A2 (en) * | 2017-09-11 | 2019-03-14 | Lenovo (Singapore) Pte. Ltd. | Methods and devices for transmitting device capability information |
| CN109474688A (en) * | 2018-11-27 | 2019-03-15 | 北京微播视界科技有限公司 | Sending method, device, equipment and the medium of instant messaging network request message |
| CN109617988A (en) * | 2018-12-28 | 2019-04-12 | 平安科技（深圳）有限公司 | Request retries method and Related product |
Non-Patent Citations (1)
| Title |
|---|
| 王小龙、侯刚."软件动态执行网络建模及其级联故障分析".《计算机科学》.2014,全文. * |
Also Published As
| Publication number | Publication date |
|---|---|
| CN111479334A (en) | 2020-07-31 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN111479334B (en) | Network request retry method and device and terminal equipment | |
| EP3008592B1 (en) | Pre-fetching content for service-connected applications | |
| US10049154B2 (en) | Method for matching queries with answer items in a knowledge base | |
| CN107798108B (en) | Asynchronous task query method and device | |
| US9110978B2 (en) | Method for matching queries with answer items in a knowledge base | |
| CN106980533B (en) | Task scheduling method and device based on heterogeneous processor and electronic equipment | |
| CN110704677A (en) | Program recommendation method and device, readable storage medium and terminal equipment | |
| CN111026853A (en) | Target problem determination method and device, server and customer service robot | |
| CN112749028A (en) | Network traffic processing method, related device and readable storage medium | |
| CN113923529A (en) | Live broadcast wheat connecting method, device, equipment and storage medium | |
| CN110750498A (en) | Object access method, device and storage medium | |
| CN116627771B (en) | Log acquisition method, device, electronic equipment and readable storage medium | |
| CN112612901A (en) | Medical knowledge map intelligent management retrieval platform | |
| CN114531340B (en) | Log acquisition method and device, electronic equipment, chip and storage medium | |
| CN110990701B (en) | Book searching method, computing device and computer storage medium | |
| CN114237981A (en) | Data recovery method, device, equipment and storage medium | |
| CN112732542A (en) | Information processing method, information processing device and terminal equipment | |
| CN111143351B (en) | IMSI data management method and equipment | |
| CN114090037A (en) | Service degradation method, device, computer equipment and storage medium | |
| CN108632366B (en) | File downloading method and device and terminal equipment | |
| CN111611077A (en) | Task parameter processing method, terminal and storage medium | |
| CN110245146B (en) | User identification method and related device | |
| CN111259126A (en) | Similarity calculation method, device and equipment based on word characteristics and storage medium | |
| CN113486071B (en) | Searching method, server, client and system based on electronic book | |
| CN115396280B (en) | Alarm data processing method, device, equipment and storage medium |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| TA01 | Transfer of patent application right |
Effective date of registration: 20210128 Address after: 518000 Room 201, building A, No. 1, Qian Wan Road, Qianhai Shenzhen Hong Kong cooperation zone, Shenzhen, Guangdong (Shenzhen Qianhai business secretary Co., Ltd.) Applicant after: Shenzhen saiante Technology Service Co.,Ltd. Address before: 1-34 / F, Qianhai free trade building, 3048 Xinghai Avenue, Mawan, Qianhai Shenzhen Hong Kong cooperation zone, Shenzhen, Guangdong 518000 Applicant before: Ping An International Smart City Technology Co.,Ltd. |
|
| TA01 | Transfer of patent application right | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| GR01 | Patent grant | ||
| GR01 | Patent grant |